Malwarebytes High CPU, Memory or Disk Usage: Find the Real Cause

Start with the resource that's actually constrained

“Malwarebytes is slowing my computer” isn't yet a diagnosis. Open the operating system's process view and identify whether the immediate constraint is processor time, physical memory, disk active time or a thermal response such as sustained fan noise and reduced clock speed. Write down the process at the top of the relevant column before changing a setting.

If Malwarebytes won't open, update or begin a scan, use our Malwarebytes not-working guide. This page assumes the product runs and focuses on resource behavior. Keeping that boundary stops a performance complaint from turning into an unnecessary reinstall.

Don't begin by quitting every security process. A lower graph after protection is disabled proves only that the disabled program was doing work. The useful question is why, whether the work is expected, and which documented adjustment preserves coverage.

CPU, memory, disk and temperature describe different bottlenecks

CPU percentage estimates how much processor capacity a process is receiving during the sample. Memory figures describe several different concepts, including a process working set, committed memory and total physical pressure. Disk active time describes how continuously a drive is servicing requests, not how many megabytes per second it transfers. Treating the four values as one score leads to the wrong fix.

An older hard disk can remain at 100% active time while transferring a modest stream of tiny files because the heads seek constantly. A modern multicore processor can show a small total percentage while one logical processor is saturated. A system can also use most installed RAM efficiently without Malwarebytes being the largest process.

Thermal symptoms add another layer. A fan reacts to heat, power and firmware policy; it doesn't identify the process. Confirm Malwarebytes in Task Manager or Activity Monitor, then connect the temperature change to a scan or idle event rather than treating sound alone as proof.

Build a five-minute baseline before touching settings

On Windows, open Task Manager, sort Processes by CPU, then Memory and Disk. If the top entry changes too quickly, observe it for a few minutes and open Resource Monitor for the affected resource. Microsoft's current high-CPU troubleshooting guidance uses Resource Monitor to sort processes by consumption; the same attribution principle is useful on a personal PC.

Record one sample while the computer is idle and one during the action that triggers the complaint. Use the same applications, power mode and network state. Don't compare a scan running beside a game with an idle desktop captured after reboot and call the difference a Malwarebytes regression.

A short baseline is more valuable than a single screenshot of 100%. Note minimum, typical and peak behavior, but avoid turning five minutes into a universal benchmark. The purpose is to prove a repeatable relationship between a Malwarebytes process and the slowdown on this device.

Record the process, version, scan state and recent event

Write down the exact process name, the Malwarebytes application version, whether a scan is visible, its type and current stage, and the first time the behavior appeared. Add any nearby event: application update, threat-intelligence update, Windows or macOS update, wake from sleep, new storage drive, new antivirus, or a newly scheduled scan.

Save screenshots that show the relevant time and process, but redact usernames, client paths, license details and private filenames. If the problem repeats after wake or on one external drive, state that explicitly. A precise two-line timeline is more actionable than “it has always been slow.”

Separate productive scan load from sustained idle load

When a scan is active and its item count or current object advances, resource use is producing security work. The question becomes whether that work is scheduled at the right time and scoped appropriately. When no scan appears and the same process remains busy after startup, update and post-scan activity should have settled, the question becomes what event or component is looping.

Don't label a process “idle” while Windows is starting, the device just woke, definitions are updating or a scheduled scan is beginning. Give the state a defined observation window and note what the interface reports. Conversely, don't excuse hours of repeated disk access merely because antivirus software sometimes scans files.

The current Malwarebytes scheduling guide recommends a Threat Scan and offers Smart Scan at idle time. That's the first scheduling lever when legitimate work collides with active use; it isn't a fix for unexplained idle activity.

There's no universal “normal Malwarebytes CPU percentage”

A search result may tell you that a scan should use a fixed band of processor time. That number can't travel reliably between a two-core laptop, an eight-core desktop and an ARM system. Windows percentages also summarize available logical processors, while scan scope, drive speed, archive density and concurrent applications change the work waiting for the CPU.

Microsoft's current Task Manager instructions show where Windows lists cores and logical processors. Use that context to understand your graph, not to calculate a pass/fail threshold. The better boundary is behavioral: progress during a scan, settling afterward, and responsiveness during normal use.

For the same reason, we don't publish invented “tested” RAM or scan-time numbers for an unknown reader's machine. Our Malwarebytes review covers the product decision; this guide stays with measurements a reader can reproduce on the affected device.

Deep, Custom, rootkit and archive scans intentionally do more work

Malwarebytes' current scan-types documentation says Custom Scans can take a long time and recommends Threat Scan unless a specific location needs inspection. It also describes Deep Scan as more resource-intensive and likely to affect device performance for longer than other scans.

Deep Scan isn't a better weekly default merely because its name sounds thorough. Malwarebytes recommends it after malware has been blocked or detected. Rootkit scanning and archive inspection add more objects and different access patterns, which can raise CPU and disk activity or hold a stage on a large container.

Our Malwarebytes scan-types guide explains the current controls in depth. Use it to choose the smallest scan that answers the security question rather than treating maximum scope as a performance troubleshooting step.

Move routine scans to idle time with Smart Scan

For a paid subscription, open the Scanner area and review the Scan Scheduler. The current vendor instructions recommend leaving “At idle time (Smart scan)” selected when scheduling a Windows scan. This avoids pinning a rigid start time to the middle of a meeting, game or rendering task, although “idle” still means the computer must be available to do the work.

Review duplicate schedules and old custom jobs before adding another. One weekly Threat Scan may be the intended baseline, while an inherited daily Custom Scan across several drives can create the impression that Malwarebytes is always busy. Name schedules clearly and keep only the jobs that answer a real security need.

The current scheduled-scan editing guide documents changing existing jobs. Scheduling is a product-management question too; our Malwarebytes Free versus Premium comparison explains why automatic scheduling isn't available in the same way on the free tier.

Reduce unnecessary scan scope without weakening detection policy

On Windows, current scan settings let a Custom Scan include memory objects, registry and startup items, rootkits, and archives. Each choice serves a purpose. If you're reproducing a performance problem, compare an ordinary Threat Scan with the specific heavy option rather than switching off quarantine or changing PUP/PUM treatment.

The vendor notes that rootkit scanning slows the scan and that archive scanning can inspect two levels inside supported containers. A directory containing large nested archives, virtual-machine disks or build artifacts can therefore behave very differently from common system locations.

Choose a Custom Scan only for the drive or folder you need to investigate. Don't exclude a broad location merely to make the graph prettier. If Malwarebytes detects something and you need to review or restore it safely, use our quarantine and false-positive guide instead of mixing detection policy into performance tuning.

If CPU is high during a scan, check progress before intervening

Watch the item count, current object and elapsed time, then check whether the interface remains responsive. A processor-heavy scan that advances and finishes is different from a process that loops on one object or stays busy long after the report appears. Capture the stage before canceling so a second run can reveal whether the same object repeats.

If the job is legitimate but badly timed, pause or cancel through the application when the interface provides that control, then schedule it for idle time. Don't end the protected service from Task Manager. Finishing the scan or moving it's a controlled action; killing a service can leave state incomplete and protection unclear.

Reduce only the scope that isn't needed for the security question. A routine Threat Scan is usually more appropriate than a Deep Scan across every drive. If a scan won't progress or the app stops responding, cross over to the scan-failure troubleshooting path and preserve logs.

If CPU stays high while idle, correlate startup, update, wake and protection events

Define the idle state first: no visible scan, startup settled, updates completed and ordinary foreground apps unchanged. Record whether the CPU rise begins immediately after sign-in, after sleep, at a scheduled time, after a definition update or only when another application opens many files. Those patterns point to different components.

Restart once after saving work, then reproduce the same idle interval. If the process settles, note the temporary result rather than declaring a permanent fix. If it returns after every wake or update, the recurrence is useful evidence for Support and far stronger than repeated service restarts.

Don't disable real-time modules one after another without a protection plan. If a Malwarebytes protection feature appears to trigger a repeatable event, collect the version and logs and test under Support guidance. Our installation and setup guide covers initial protection state without presenting permanent module shutdown as optimization.

High total memory doesn't prove Malwarebytes is the memory hog

Task Manager's total Memory percentage includes Windows, applications, caches and other consumers. Sort by process and record the Malwarebytes working set, but also note whether the system is actually under pressure: applications paging, tabs reloading, sustained disk paging or an out-of-memory warning. Used RAM can be useful RAM.

The current Malwarebytes system requirements list 4 GB as the Windows minimum and 8 GB as preferred. A supported minimum doesn't promise comfortable multitasking with a browser, game, video call and security scan running together.

Close an unnecessary foreground application for the test, not the protection service. Compare the same workload before and after the scan ends. If Malwarebytes remains stable while total pressure follows another app, fix the actual consumer instead of reinstalling the antivirus.

Distinguish a stable working set from memory that keeps growing

A process may reserve or cache memory and then stabilize. Capture its working set at regular intervals under the same conditions. Growth during an active scan that falls afterward isn't the same pattern as steady growth while idle across an hour, especially when the device begins paging or becomes unresponsive.

Record whether closing the Malwarebytes window changes the number without choosing Quit. The interface and protection service are different layers, and an open dashboard can contribute to visible memory without explaining a system-wide leak. Preserve the process names rather than summing every entry that contains a similar word.

If the working set grows repeatably on a current supported system, collect Support Tool logs before Repair. Don't install a “RAM cleaner” or change page-file settings as a first response. Those actions alter the environment and can obscure the product behavior you need to report.

100% disk active time can mean many small requests, not high throughput

Open Resource Monitor, select Disk and sort activity by total bytes per second, then inspect the processes and files. Pair that with Task Manager's active-time graph. A drive can be fully occupied by random reads at low throughput, particularly an HDD, while an SSD transfers much more data without staying saturated.

Determine whether Malwarebytes is scanning the same drive and whether the file path changes. Repeated access to one archive, mail store, virtual-machine image or external disk suggests a scope or storage investigation. Activity spread across many small files during an active scan may simply be the workload you requested.

Don't stop at “Disk 100%.” Record the process, drive letter, file path, transfer direction and scan state. That evidence separates a scan, telemetry/helper behavior, paging pressure, storage failure and another program that happens to run at the same time.

A narrow 2026 DDSHelper.exe pattern has a reversible community workaround

In January 2026, an official Malwarebytes forum thread described `DDSHelper.exe` holding one storage drive at 100% I/O while no scan appeared in the app. Several participants reported that turning off General → Usage and threat statistics stopped the activity, and a forum expert closed the thread after the workaround was reproduced.

The parallel r/Malwarebytes discussion contains independent reports through June, often involving a noisy HDD. A Malwarebytes representative asked for complete Support Tool logs and said an unexpected DDS/IG condition could be hung. That's useful current community evidence, not an official statement that every installation has the defect.

Use this test only when the signature matches: `DDSHelper.exe`, sustained drive activity at idle, no visible scan and a confirmed Malwarebytes process. Capture before-and-after activity, toggle Usage and threat statistics once, and leave self-protection enabled. If the activity returns, restore your preferred privacy setting if appropriate, collect logs and open a Support case instead of disabling the service.

External HDDs and folders with many small files amplify scan cost

A mechanical external drive pays a seek penalty as the scanner moves between small files. USB power management, bridge firmware and a sleeping drive can add pauses. If only one external disk becomes busy, record its connection, file system and whether it was included in a Custom Scan rather than assuming the system drive is failing.

Source trees, mail archives, photo catalogs, backup snapshots and dependency folders can contain enormous object counts. A low byte rate can still represent continuous useful reads. Watch whether file paths advance; a repeating identical path is more suspicious than a changing sequence across the selected target.

Don't create a permanent allow-list entry for an entire backup or project tree merely because scanning it's expensive. Decide whether that drive belongs in the scheduled scope, run a targeted scan when risk warrants it, and keep untrusted downloads or executable backups inside the security model.

Check free space and drive health when storage behavior is abnormal

Malwarebytes currently requires 1 GB of free installation space on Windows, but the operating system, updates, logs and page file need additional headroom. A nearly full system drive can make normal operations slow and turn memory pressure into extra disk work. Record free space before blaming the scanner.

If the affected drive reports I/O errors, disconnects, unusually long queues or mechanical warnings outside Malwarebytes activity, back up important data and use the drive manufacturer's or operating system's supported diagnostics. A security scan can expose a weak drive by reading widely, but it doesn't create every underlying hardware fault.

Don't run repeated Deep Scans as a stress test on a failing disk. Protect data first, then diagnose hardware. Malwarebytes' professional Toolset documentation mentions SMART and issue-scanner capabilities for technicians, but ordinary users shouldn't purchase or improvise with technician tooling just to identify a basic drive warning.

Fan noise and temperature are consequences, not process attribution

A scan can raise package power and temperature, so fans may ramp and a thin laptop may reduce clock speed. Record the responsible process and active scan before connecting the sound to Malwarebytes. Dust, blocked vents, charging, a high-performance power profile and another application can produce the same symptom.

Place the laptop on a hard ventilated surface and avoid blocking intake or exhaust. If a routine scan is the cause, schedule it for idle time while the device remains awake and ventilated. Don't use fan noise as a reason to disable protection permanently or edit firmware voltage settings.

If temperatures remain unsafe outside the scan or the system shuts down, treat that as a hardware and cooling problem. Antivirus scheduling can reduce collision with active use, but it isn't a substitute for repairing a failed fan, dried thermal interface or blocked heatsink.

Schedule scans away from games, video calls and creative work

Games and real-time calls are sensitive to short scheduling delays even when average CPU looks reasonable. Video editing and software builds also generate many file operations that real-time protection may inspect. Reproduce the slowdown with and without an active scheduled scan before blaming the always-on layer.

Move routine scans to Smart Scan or another quiet period and avoid launching Deep Scan immediately before latency-sensitive work. Keep the scan report and check whether the slowdown ends when the legitimate job completes. That proves scheduling contention without requiring a permanent protection change.

If you're deciding whether Malwarebytes fits a gaming system rather than diagnosing one event, compare its role with another current provider. Our Malwarebytes versus Microsoft Defender comparison and Malwarebytes versus Norton comparison keep that product decision separate from this troubleshooting session.

Use one controlled restart, then verify the running version

Save work, note the current measurements and restart Windows or macOS once after an application update or persistent post-wake condition. After sign-in, wait for startup and updates to settle, then repeat the same observation window. Record whether the behavior disappears, returns immediately or returns only after the next scan or sleep cycle.

On Windows, keep automatic application updates enabled or use the current check-for-updates control. The current Windows update guide documents that path, while the General settings documentation recommends leaving application updates and self-protection on. Don't turn off both to make a clean baseline.

A restart that helps once isn't proof of root cause. Repeating it every hour destroys productivity and can postpone a useful log capture. If the same process and event return, preserve that sequence and move to diagnostics.

Current Windows 5.6.3.277 notes don't publish a resource-usage fix

Malwarebytes released Windows version 5.6.3.277 on July 23, 2026. Its public notes mention notification changes, dashboard cleanup and a quarantine-progress correction. They don't identify a current high-CPU, high-memory or high-disk fix.

That absence doesn't prove no individual device can have a performance problem. It does mean we shouldn't call every resource complaint a known 5.6.3 bug or promise that an update contains an undocumented correction. Record the version and use the observed signature.

Historical Malwarebytes updates have caused resource incidents, but a 2018 event can't diagnose a July 2026 machine. Current release notes, current forum evidence and the device's own logs outrank an old headline copied into a generic fix list.

Test another antivirus relationship narrowly and keep protection active

Malwarebytes' current coexistence documentation says another antivirus can block the app or produce functional issues. Two real-time products can also inspect overlapping file activity. Record which providers are registered, which modules are active and whether the slowdown began after the second product changed.

Don't uninstall both products or browse unprotected to run a comparison. Use Windows Security to verify the active provider, pause only a documented test under controlled conditions if appropriate, and restore coverage immediately. On a managed device, involve the administrator because policy may re-enable components or control exclusions.

Malwarebytes documents mutual allow-listing as one coexistence option, but that doesn't justify copying an old list of program folders and drivers into every product. Use the current vendor instructions for the exact pair. Our Bitdefender versus Malwarebytes and Avast comparison explain product overlap without treating mutual exclusions as a universal cure.

Don't exclude entire Malwarebytes folders or drivers blindly

Older competitor guides recommend excluding `C:\Program Files\Malwarebytes`, `C:\ProgramData\Malwarebytes` and a list of drivers from another antivirus. That's broad, version-sensitive advice. It can reduce inspection around security software and survive long after the original conflict disappears.

If logs prove that a specific pair of security products is inspecting one another, follow both current vendors' compatibility instructions and document each rule. Change one side at a time, verify protection and performance, and remove the test rule when it doesn't change the result.

An allow list isn't a performance switch. Our Malwarebytes allow-list guide requires a verified file or application and a narrow scope. A broad exclusion used to suppress disk activity can hide a different process, a damaged installation or a legitimate heavy scan.

macOS has a documented High, Medium and Low scan CPU control

Malwarebytes for Mac exposes a current scan-performance selector. Open Settings, choose Advanced settings, then Open advanced settings. The vendor's Mac CPU-settings guide lists High, Medium and Low and explains that a higher setting can finish faster while affecting system performance, especially on an older device.

Choose Medium or Low when a system scan collides with active work, then expect the scan to take longer. Compare the same scan type and target so the result is meaningful. Don't call Low more secure or High more thorough; the setting controls processing allocation, not the detection policy described by the scan.

Our Malwarebytes for Mac review covers the platform's permissions and product scope. If the Mac app fails to open or update rather than merely using CPU, switch to the not-working guide and preserve the macOS error.

Don't copy the Mac CPU selector into Windows instructions

The current Windows scan-settings article we verified doesn't document the same High, Medium and Low selector. Windows guidance instead exposes scan type, Smart Scan scheduling and Custom Scan scope. A screenshot from an older Malwarebytes version or another platform isn't proof that a control exists in the current Windows app.

Likewise, Windows service, registry and .NET instructions don't apply to macOS. Use Activity Monitor and the documented Mac control there. On Windows, use Task Manager or Resource Monitor and the Support Tool. Keep the platform in every heading and support note when the paths diverge.

Mobile products are another architecture entirely. The Malwarebytes Android and iOS review explains why a desktop scan-performance tweak can't be transplanted to a phone. Platform separation is part of accurate troubleshooting, not an editorial detail.

Use Process Explorer or Process Monitor only when basic attribution is insufficient

Task Manager and Resource Monitor are enough for most readers. If Support needs deeper evidence, Microsoft's current Process Explorer 17.12 can show process ownership, handles, DLLs and memory-mapped files. Download it only from Microsoft Sysinternals and record the process path and signer.

For a repeating disk signature, Process Monitor 4.04 can capture real-time file-system, Registry and process/thread activity with filters. Its trace can grow very quickly and contain private filenames, so use a short filtered capture and share it only through an authorized support route.

Don't install Sysmon, debuggers or random “process hacker” tools because a generic article listed them. Advanced utilities are evidence tools, not fixes. If you can't interpret a trace confidently, preserve it and let Malwarebytes Support compare it with product logs.

Collect Support Tool logs before Repair changes the evidence

Malwarebytes' current Windows log-collection guide directs users to Advanced → Gather Logs. The tool creates `Mbst-grab-results.zip`, which the current workflow uploads through a private SharePoint link supplied by a support agent.

Collect while the problem is present when possible. Include the exact observation window, scan state, process and affected drive in the ticket so logs can be aligned with the visible event. Enable enhanced event-log data only when Support directs it, as the current General settings documentation says.

Treat the archive as private. It may contain device, application, path and account context that doesn't belong in a public forum, Reddit post or open file-sharing link. Keep one untouched copy until the case is resolved.

Use Support Tool Repair before Clean or a full reinstall

If persistent idle load survives a version check, one restart, scan-schedule review and narrow evidence-based tests, use the documented Windows repair path. Malwarebytes says Support Tool Repair removes and reinstalls the app while preserving configuration and activation information.

Save work because Repair restarts Windows, and confirm .NET Framework 4.8 is available as the vendor requires. Keep Microsoft Defender or another trusted provider active during the handoff. After restart, let installation and updates settle before recreating the same measurement window.

Clean is a later full-removal route, not a stronger first answer. If Repair fails or Support directs a cleanup, follow our complete Malwarebytes uninstall guide and reinstall from the official source. Don't use a third-party uninstaller or delete protected drivers manually.

Validate the original resource, protection and scan state after every change

Change one variable, then repeat the same workload and observation window. Record the Malwarebytes version, process, CPU, working set, disk activity and scan state. A result measured under different applications, power mode or target drive can't tell you which change mattered.

Confirm protection remains active and updates complete. Run the smallest appropriate scan and save its report. If you changed a schedule, verify the old job no longer runs and the new job starts at the intended idle condition rather than assuming the calendar entry took effect.

For the DDSHelper signature, compare the same idle drive before and after the statistics toggle and watch for recurrence after wake. For Repair, compare the exact pre-repair scenario. A lower number without the original workload isn't validation.

Give Support a compact, reproducible performance incident

Include operating system and build, Malwarebytes version, exact process, constrained resource, time window, scan state, recent change and shortest reproduction sequence. State whether activity occurs at startup, after wake, during a named scan or while no scan is visible. Name the affected drive when disk use is involved.

Attach `Mbst-grab-results.zip` privately and mention any short Process Monitor capture only if requested. List the one-variable tests and their measured results, including whether Usage and threat statistics affected a confirmed DDSHelper pattern. Don't describe a community workaround as an official product fix.

Use the current Malwarebytes support route. If the larger issue is licensing or tier entitlement rather than performance, our plans and renewal guide keeps billing evidence out of the technical incident.

Match the next action to the observed pattern

The matrix preserves cause and coverage. A legitimate scan gets scheduling and scope; unexplained idle behavior gets correlation and logs; installation damage gets Repair. Each lane has a different success criterion.

If the resource issue accompanies suspicious detections, use the quarantine guide and our Malwarebytes AdwCleaner review for the defined adware-cleanup role. Performance alone isn't proof of infection, and a miner isn't the only reason a fan runs.

Avoid fixes that make the metric smaller by removing protection or evidence

Don't set the Malwarebytes process to Low priority in Task Manager as routine tuning. The setting can reset, can mask responsiveness without explaining the workload and isn't part of the current Windows documentation we verified. Use documented scheduling, scope and Repair controls.

Don't disable the Malwarebytes service, automatic quarantine or self-protection to chase a graph. Don't paste broad driver and folder exclusions from a 2023 article into a 2026 installation. Don't use third-party uninstallers, registry cleaners or “PC repair” downloads promoted beside troubleshooting content.

Don't claim that 5.6.3.277 has a confirmed resource defect because one current helper-process pattern exists. Keep the DDSHelper workaround narrow, preserve logs and date every current-issue statement. That restraint makes the guide more useful when the next release changes.

Final order: measure, classify, adjust, log, Repair and validate

Identify the process and constrained resource, then record scan state, version, time and recent event. Decide whether the load belongs to an active scan or persists while genuinely idle. For legitimate scan work, move the schedule and select only the scope the security question needs.

For unexplained idle activity, change one reversible variable. Use the DDSHelper statistics-toggle test only for the matching process-and-drive signature, and test another antivirus relationship only with protection coverage intact. Collect private logs before Repair changes the installation.

Use Support Tool Repair before Clean, then reproduce the original condition and verify protection, update and scan state. The goal isn't the smallest number in Task Manager; it's a supported, protected system whose resource use you can explain.