Windows Problem Reporting (WerFault.exe) High CPU and Disk Usage: Fixes

Windows Problem Reporting can become conspicuous just when your PC is already struggling: an application freezes, the desktop briefly disappears, or the disk stays busy after a crash. In Task Manager, the activity commonly appears as Windows Problem Reporting or WerFault.exe. The reporting process may be handling the consequences of a failure elsewhere rather than causing the original failure.

The useful question is what keeps triggering the report. A one-off crash, a repeatedly restarting application, and a disk bottleneck need different responses. This guide shows how to separate them, identify the failing program, and reduce persistent CPU or disk usage without deleting Windows components or hiding the evidence.

Try These First

1. Press Ctrl + Shift + Esc. Sort Task Manager by CPU, then by Disk, and note which process is actually busy.
2. If an application just crashed, allow the report a few minutes to finish. A larger diagnostic operation can take longer; there is no universal completion time.
3. Save work in other applications. Stop repeatedly reopening the application that crashes.
4. Note the time, the affected app, and whether the problem returns at sign-in or during a particular action.
5. Restart once if the system remains sluggish, then check whether the same trigger brings the problem back.

Do not delete WerFault.exe, clear all event logs, or permanently disable error reporting as the first fix. Those actions can remove diagnostic information while leaving the original crash unresolved.

What Is Windows Problem Reporting?

Windows Error Reporting, or WER, is Windows' infrastructure for collecting information about application faults, hangs, and other failures. WerFault.exe is part of that reporting workflow; related activity may also involve wermgr.exe. The Windows Error Reporting Service is a separate service, commonly identified as WerSvc.

Reporting behavior depends on Windows settings, application behavior, and organization policies. Seeing the process after a failure is not proof of malware, and it does not mean every report is immediately uploaded. Microsoft's Windows Error Reporting overview describes its diagnostic role.

This is different from Windows servicing. If Task Manager actually points to TiWorker.exe or TrustedInstaller.exe, use the Windows Modules Installer Worker guide. Resetting Windows Update components is not a general remedy for WerFault.exe activity.

Why It Can Use CPU or Keep the Disk Busy

Preparing diagnostic information requires work. Depending on the failure and configuration, Windows may inspect a failed process, collect data, and write report files. Repeated failures can cause that work to recur. Extra local crash-dump collection configured by an administrator or developer can add substantial disk writes; Microsoft's LocalDumps documentation explains that this feature requires configuration and is not enabled by default.

These mechanisms suggest several leads to investigate, rather than a single guaranteed cause:

100% disk activity is not the same as a full drive. Active time describes how busy the device is; free space describes how much storage remains. Low transfer speeds do not rule out an I/O bottleneck. Microsoft recommends correlating disk latency with process activity in its Windows performance troubleshooting guide.

Step 1: Confirm the Process and Its Location

In Task Manager, right-click the busy Windows Problem Reporting entry and choose Go to details, where available. Note the executable name and PID, then use Open file location on that entry.

Typical Windows locations include:

C:\Windows\System32\WerFault.exe
C:\Windows\SysWOW64\WerFault.exe

The second path can be legitimate on a 64-bit installation. Windows may be installed on another drive, and additional servicing copies can exist. Check the file used by the running process rather than an unrelated file found through Search.

Open Properties → Digital Signatures, if available. Alternatively, check the actual path in PowerShell:

Get-AuthenticodeSignature -LiteralPath 'C:\Windows\System32\WerFault.exe' |
    Format-List Status, Path, SignerCertificate

Replace the example path with the path you found. Look for a valid Microsoft signature. PowerShell also supports catalog-based signatures, so an absent Digital Signatures tab is not conclusive. See Microsoft's signature-checking documentation.

A valid signature does not explain why reporting is active. If the running file instead comes from an unfamiliar download or temporary folder and its origin is unclear, follow the malware checks in Step 7.

Step 2: Find the Repeated Failure in Reliability Monitor

The reporting process's name is often less useful than the name of the application that failed. Reliability Monitor is a convenient place to start:

1. Open Start and search for View reliability history.
2. Select the day when the slowdown occurred.
3. Select a relevant critical event and choose View technical details, or double-click the event.
4. Record the application name, time, faulting module, and exception code when shown.
5. Check whether the same failure repeats at the times Windows Problem Reporting becomes busy.

A module name is a lead, not automatic proof that the named DLL is defective. A crash involving ntdll.dll or KERNELBASE.dll does not justify downloading replacement DLLs. Record the full event and investigate the application or component associated with the recurring failure.

Step 3: Match the Time in Event Viewer

Open Event Viewer → Windows Logs → Application. Review events around the slowdown, paying attention to the source as well as the event number. Useful entries include Application Error, Windows Error Reporting, and Application Hang.

Microsoft's application-crash troubleshooting guidance identifies Application Error event 1000 as an application-crash event and describes accompanying WER event 1001 records. Not every machine or failure produces the same sequence, and event IDs from unrelated sources mean different things.

For a read-only view of recent relevant records, run this in PowerShell:

Get-WinEvent -FilterHashtable @{
    LogName = 'Application'
    Id = 1000, 1001, 1002
    StartTime = (Get-Date).AddHours(-2)
} | Where-Object {
    $_.ProviderName -in @(
        'Application Error',
        'Windows Error Reporting',
        'Application Hang'
    )
} | Select-Object TimeCreated, ProviderName, Id, Message |
    Format-List

If no matching events are found, PowerShell may report that fact; widen the time window or inspect the log directly. Missing records are not proof that nothing failed. Save relevant details before cleanup, and remove personal paths or other private information before sharing logs publicly.

Step 4: Repair the Application That Keeps Crashing

Use the evidence from Steps 2 and 3 to choose the change:

• One application repeatedly fails: update it, test without recently added extensions, and use its supported Repair option if available. Back up its data before a reset or reinstall.
• The desktop or File Explorer repeatedly restarts: investigate recently installed shell extensions, synchronization tools, or other integrations that coincide with the first failures.
• Failures began after a driver change: check the PC or device manufacturer's supported driver. Consider rollback only when the timing and symptoms point to that change.
• A background app immediately relaunches: close it through its own controls or temporarily disable its recognized startup entry while repairing it.

Change one thing at a time and repeat the original action. A reduction in reporting activity is useful only if the application also stops failing. A disappeared reporter alongside a still-broken app is not a complete fix.

Step 5: Investigate High Disk Usage Separately

Open Resource Monitor from Start, select Disk, and inspect Processes with Disk Activity. Select the relevant process and expand Disk Activity to see file paths, read/write rates, and response times. Correlate what you see with the time of the failure.

If report or dump files are growing, preserve the recent evidence needed for diagnosis before removing old files. Additional full dumps can be large; do not turn on broad dump collection as a casual fix for an already busy disk. If a support tool enabled it, ask the responsible administrator or vendor to review the collection settings and retention.

If WerFault.exe finishes but disk active time remains high, follow the remaining busy process. Check Windows Logs → System for storage errors that match the pauses, and use the drive manufacturer's diagnostic guidance when appropriate. Back up important files before attempting repairs on a drive showing error symptoms.

Also check free space under File Explorer → This PC:

To reclaim space, use Settings → System → Storage → Cleanup recommendations on supported Windows 11 builds, or Disk Cleanup where appropriate. Review each selected category. If error-report or dump categories are offered, remove them only after retaining anything needed for support. Avoid selecting Downloads, previous Windows installations, or other categories indiscriminately. Microsoft's drive-space guide explains these tools.

Cleanup can recover capacity. It will not prevent fresh reports from being created while the application keeps crashing.

Step 6: Update and Repair Windows Components

Install the Windows updates available for your edition and support status, then restart if required. Keep the affected application current as well. If unrelated applications fail or Windows components appear damaged, open Command Prompt as administrator and run:

DISM.exe /Online /Cleanup-Image /RestoreHealth

After DISM completes successfully, run:

sfc /scannow

Allow both operations to finish. Note any error code and restart after repairs. This order follows Microsoft's System File Checker instructions. The repair itself can temporarily use CPU and disk resources, so compare performance after it finishes. These commands do not fix a third-party application's programming errors.

Step 7: Rule Out Malware or a Background Conflict

When the file path, signature, installed software, or behavior raises concerns, open Windows Security → Virus & threat protection → Scan options and run a Full scan. Use the equivalent scan in your active antivirus product if Windows lists another provider.

For persistent suspected malware, Microsoft Defender Offline scans after restarting into the recovery environment. Save work first and review Protection history afterward. Microsoft's scan-options guide explains the choices. Do not exclude WerFault.exe from scanning merely to reduce activity.

If the files check out but the source remains unclear, a clean boot can help isolate a background conflict. Record your starting configuration, open System Configuration, and select Hide all Microsoft services on Services before following Microsoft's clean-boot procedure. Temporarily disable the relevant remaining services and startup apps, restart, and reproduce the original workload. Restore items in groups to locate the trigger, then return to your previous configuration. Involve IT on a managed PC.

Should You Disable Windows Error Reporting?

Permanent disabling is not a good first-line repair for this problem. It changes reporting behavior rather than repairing the failing application, and it can make subsequent troubleshooting harder. WER has several settings and policy controls, so changing one service is not a universal switch for every diagnostic mechanism. Microsoft documents these distinctions in WER settings.

If the PC is unusable and you have already saved the relevant details, ending the identified busy reporting process may provide temporary relief. It can interrupt report collection; the next failure can launch reporting again. Treat that as recovery from an unresponsive session, then investigate the repeated crash. Any temporary reporting-policy change should be a controlled support test with the original settings recorded and restored.

How to Tell Whether the Fix Worked

Repeat the action that used to trigger the issue. Confirm that the application completes its work, no fresh matching failures appear, and sustained CPU or disk activity does not return. Check again after sign-in if that was the original trigger.

Old Reliability Monitor entries do not disappear when you fix the application. Compare timestamps and look for new failures. Brief reporting activity after a separate, genuine crash can still occur.

If the problem persists, provide the application version, Windows build, failure time, relevant event details, and the file paths associated with heavy disk activity to IT or the software vendor. Share crash dumps only through their approved support channel because dumps can contain application memory and private data.

FAQ