Your fan ramps up, the mouse starts stuttering, and Task Manager shows Windows Problem Reporting eating CPU for no obvious reason. Nothing crashed on screen, yet WerFault.exe won't settle down. The tempting move is to kill it or disable the service and move on. Don't do that yet. In most cases, Windows Problem Reporting high CPU isn't the fault. It's the messenger working overtime because something else keeps failing, and if you silence it first you'll destroy the evidence you need to find that fault.
Why Disabling Windows Problem Reporting Rarely Helps
You found the standard advice already. End WerFault.exe, restart the service, disable Windows Error Reporting, apply a registry tweak. That advice reduces a visible number. It rarely repairs anything.
Windows Problem Reporting is part of Windows Error Reporting (WER), the automated infrastructure Windows uses for application crashes, hangs, and other failures. When an app fails, WerFault.exe can collect diagnostic information, process crash data, and submit a report, as described in Microsoft guidance on troubleshooting high CPU usage. That's event-driven work, not a general background workload that spins up for fun.
A Burst Is Not a Loop
A brief spike while one report is generated is normal behavior. Persistent usage is different. It commonly points to repeated application failures, a recurring hang, or an accumulating reporting workload. If you disable WER at that point, the unstable app, driver, or service keeps failing. You just lose the crash records, timestamps, and dumps that would've named it.
Bench rule: Treat disabling WER as temporary containment, never as a diagnosis. If the CPU drops after you disable it, you've hidden a symptom, not fixed a cause.
That distinction is the whole job here. You're not asking how to stop WerFault.exe. You're asking what's making it run again and again. Sometimes the answer is a single app in a crash loop. Sometimes it's a backlog of reports, disk pressure, or a suspicious file pretending to be a system component. Those cases need different responses, and you can't tell them apart from one Task Manager percentage.
Work in order. Capture the incident first, identify the faulting process second, fix that process third. Touch WER policy last, and only after you've preserved evidence. It's slower than a registry edit. It's also the only approach that stops the problem from returning next week with a different process name at the top of the list.
What Windows Problem Reporting Actually Does
Start with the names, because you'll see three of them. WerFault.exe is the reporting client that appears when a failure is handled. WerFaultSecure.exe handles related work for processes running with higher privileges. WerSvc is the background Windows Error Reporting service that supports queuing and submission.
The pipeline below shows why a single glance at Task Manager can mislead you.
WER isn't just a notification window. It's an event-based subsystem that collects information about hardware and software problems, reports it to Microsoft, and can return available solutions, according to Microsoft documentation on what WER does. Beginning with Windows Vista, Windows enabled reporting for crashes, application non-responses, and kernel faults by default without requiring application changes. WER can also receive application-specific reports through its API for problems that aren't ordinary crashes.
The Sequence That Burns CPU
Microsoft documents a defined sequence in its explanation of how WER processes a problem event. A problem occurs, the operating system invokes WER, WER collects diagnostic data and builds a report, and it may prompt for consent. If consent is provided, WER sends the report to Microsoft's Watson Server, and if that server requests more information, WER collects more data and may prompt again.
For applications registered for recovery and restart, WER can also run recovery callbacks while collected data is compressed and transmitted. Run that sequence once and you'll barely notice. Run it in a loop because an app crashes every few minutes, and collection, compression, storage, and retries add up to sustained CPU and disk activity.
The video below is useful if you want to see how that reporting activity presents on a live system before you start changing settings.
Vista's October 2006 release matters here. A Microsoft Research paper on a decade of large-scale Windows debugging says Vista dramatically pushed up error-reporting coverage while errors per user continued to decline, a history detailed in the Microsoft Research paper on large-scale Windows debugging. More reporting doesn't prove Windows got less stable. It means failures became more visible. A short, legitimate burst is WER behaving as designed. A loop that returns after several minutes is your real target.
First-Line Triage With Task Manager and Event Viewer
Don't guess from a frozen screenshot. Reproduce the spike and capture an incident envelope. You need the exact executable, the timestamp, the faulting application, and the recurrence pattern.
The four moves below give you that envelope with built-in tools.
Open Task Manager, sort by CPU, and watch whether WerFault.exe spikes alone or right after another process fails. Right-click the process and check its details, file location, and command line where available. A legitimate Microsoft-signed binary in the expected Windows location is a different case from an unsigned file with a similar name in a user folder.
Match the Timestamp to an Event
Open Event Viewer and check Windows Logs > Application for Event ID 1000 application errors around that exact time. Then check Services Logs > Microsoft > Windows > Windows Error Reporting for the matching reporting activity. Reliability Monitor is coarser, but it's faster for spotting whether the same app has been failing for days.
- Record the faulting module: Write down the application name, module, and exception details before you clear anything.
- Note the interval: One failure after an update is not the same pattern as a crash every few minutes.
- Verify the binary: Confirm the file path and digital signature before you label anything malware or safe.
This is where a systematic debugging workflow helps, because you're forming a hypothesis from evidence instead of changing settings at random. If the spike disappears in Safe Mode, use a clean boot to isolate third-party startup services. Microsoft specifically recommends Safe Mode, clean boot, and malware scanning for these cases in its guidance on WerFault high CPU usage.
Run an offline or full malware scan before you change reporting settings if the path or signature looks wrong. Don't repeatedly end WerFault.exe while you investigate. You'll interrupt report processing and learn nothing about what's triggering it.
Going Deeper With Windows Performance Recorder
Task Manager tells you a process is busy. It doesn't tell you what code inside that process is hot. When the same spike keeps returning and Event Viewer doesn't settle the question, capture a trace.
Use Windows Performance Recorder (WPR) while the spike is actively occurring, not after it fades. Microsoft recommends collecting performance data at 1-to-5-second intervals and recording a WPR trace during the high-CPU condition. The process name alone isn't enough to identify a root cause.
Select the First Level Triage profile and the CPU Usage profile, save the ETL file, and open it in Windows Performance Analyzer (WPA). That workflow, built on Event Tracing for Windows (ETW), is covered in Microsoft documentation for WPR and WPA support tools. WPR records system and application behavior, and WPA lets you analyze stack-based tables and graphs instead of staring at a percentage.
Reading the Trace
In WPA, start with Computation > CPU Usage (Sampled) and group or pivot by Process. Then inspect Process > Stack, and if you need finer detail, Process > Thread ID > Stack. You're looking for the hottest call paths, not just the tallest bar.
- Crash loop pattern: Repeated stacks from a faulting process followed by WerFault activity point to the application, not WER.
- WER-owned pattern: CPU concentrated in WER's own stacks points you toward report generation, dump collection, disk latency, permissions, or a corrupted queue.
- Weak pattern: One short trace with no matching event proves very little, so capture again.
Don't infer causality from a single sampled snapshot. Validate with repeated captures and line up ETL timestamps against WER and application-crash records.
Capture hygiene matters. Take a short baseline trace during normal operation and a second trace during the incident. Keep the recording long enough to include several spike cycles, but don't let it run until the file becomes unwieldy. For a one-off spike on a machine that's been stable for months, this is overkill. For a recurring Windows Problem Reporting high CPU problem, it's the strongest evidence you'll get.
Matching the Symptom to the Right Response
Most bad fixes come from treating four different patterns as one problem. Use your incident envelope to pick a row before you touch a setting. If you can't place the incident in a row, you don't have enough evidence yet.
Triage Patterns for Windows Problem Reporting High CPU
| Pattern | Evidence That Fits | Best First Move |
| One-off short spike | Signed WerFault.exe, one application error, CPU settles and doesn't return | Let the report finish, note the app, and monitor |
| Repeated same-application crash | Recurring Event ID 1000 records naming the same app or module, spikes follow each failure | Update or reinstall that app or driver, and preserve a dump |
| Unknown or unsigned executable | Unfamiliar path, missing or invalid signature, no clear faulting application | Run an offline or full malware scan before changing WER settings |
| Persistent WER-owned CPU | Other processes look healthy, WER stacks dominate a trace, disk activity or report backlog is high | Inspect the report queue, free disk space, permissions, and dump activity |
The first row needs patience, not intervention. A report being prepared, compressed, or submitted can look alarming for a short period. If it finishes and the system stays calm, record what crashed and move on.
The second row is the most common useful diagnosis. Sustained activity often reflects repeated failures or report processing, a distinction emphasized in this overview of what WerFault.exe is and why it runs. Fix the named application. Don't punish the reporting client for showing up after every crash.
The third row changes your priorities completely. Verify location and signature first, then scan. The fourth row is narrower than people assume, and you should only land there after Event Viewer or WPA shows WER doing the work itself. That's when queue backlog, storage, compression, and upload activity deserve direct attention, a trade-off explored in this discussion of Windows Problem Reporting CPU and disk usage.
Targeted Fixes That Preserve Your Diagnostic Trail
Fix in ladder order, least invasive first. Your goal is to stop the failures while keeping enough evidence to prove you did.
Fix the Culprit Before the Reporter
Update or reinstall the application or driver named in Event Viewer, Reliability Monitor, or your WPA trace. If a clean boot isolated a third-party startup service, update, repair, or remove that service and retest under the same conditions that triggered the spike. A fix that only works when you avoid the workload isn't a fix.
Check the reporting workload next. Confirm the system drive has free space, look at whether reports are accumulating, and let current processing finish before you judge the result. Report creation, compression, storage, and upload can keep both CPU and disk busy, especially when a backlog builds behind repeated crashes.
Capture a Dump Before You Change Policy
For a recurring fault, configure LocalDumps so the next crash leaves usable evidence. Microsoft's application-crash guidance identifies Event ID 1001 as WER-related information and gives an example that sets a dump folder to C:\WER, limits retained dumps with DumpCount set to 10, and uses DumpType 2 for full dumps, as shown in Microsoft guidance on troubleshooting application crashing behavior. Full dumps consume storage, so use them selectively and match each dump to its event record.
- Preserve first: Save the dump, event timestamp, faulting module, and exception code together.
- Contain last: Change WER policy only after triage rules out an unknown executable and you've captured evidence.
- Avoid the reflex: Don't repeatedly end WerFault.exe, delete report queues without recording timestamps, or disable consent and reporting through registry edits as a first move.
What you'll lose matters: Disabling WER can remove the diagnostic reports that would identify a recurring application or driver fault. Preserve the evidence first, then decide whether containment is justified.
If you do disable reporting temporarily, write down why, when, and what evidence you saved. Set a condition for turning it back on. Permanent silence should never be the accidental result of a bad afternoon.
Keeping WER Healthy Without Hiding Future Crashes
Leave WER on by default. It's the official crash-data channel, not junk telemetry you remove on sight. Reserve disabling it for cases where triage is inconclusive and disk pressure or privacy is the immediate priority.
A full system drive can make reporting work crawl and look like a CPU problem. Check free space on the system drive and the WER report location periodically, especially after repeated crashes or after you've enabled full dumps. Clear space deliberately, and record timestamps before you remove old artifacts you'll never be able to inspect again.
A Small Maintenance Checklist
- Check Reliability Monitor: Look for the same application failing across multiple days.
- Check disk headroom: Confirm the system drive and dump folder aren't filling up.
- Keep a baseline: On a high-value system, capture an occasional ETW trace during normal operation so the next incident has something to compare against.
- Review after updates: If a spike follows an application or driver update, correlate the timestamp before blaming WER.
Publications such as NeoTeo cover Windows troubleshooting with Task Manager and diagnostic utilities as part of broader PC maintenance coverage, which fits the same principle. Use the tool that names the failing component. Don't settle for the tool that merely lowers a graph.
Your standard is simple. A healthy WER setup reports a crash, finishes, and goes quiet. When it doesn't go quiet, you follow the timestamps, stacks, signatures, and dumps to the component that keeps failing. That's how you fix Windows Problem Reporting high CPU without hiding the next crash from yourself.
NeoTeo publishes practical Windows troubleshooting, PC hardware guides, software explainers, and retro computing coverage that helps you diagnose problems instead of masking them. If you want more bench-tested guidance for keeping a Windows system stable and understandable, visit NeoTeo and explore its latest technology tutorials.
