How to Fix Werfault.exe Application Error in Windows?

6.6K

The WerFault.exe system process collects debug data from crashed apps and system processes, and then sends error reports and diagnostics to Microsoft. If the system encounters a problem while processing an application or the system crashes, the user will see a “WerFault.exe Application Error” message. It might look like this:

WerFault.exe – Application Error
The instruction at 0x0000000 referenced memory at 0x0000000. The memory could not be written.
Click on OK to terminate the program.

Or:

The application was unable to start correctly 0xc0000142. Click OK to close this application.

Error messages from WerFault.exe do not mean that this process itself is faulty. It is simply a report of a problem with an installed program or component that has been detected by the Windows Error Reporting Service.

Note. The legitimate WerFault.exe file is located in the C:\Windows\System32 directory. In case you find a WerFault.exe process running from another location, this may indicate that malware/potentially unwanted app impersonating a Windows system process. In this case, you should perform a full antivirus scan using Microsoft Defender/another trusted security product (note that running an offline scan may help detect malware that hides from the running OS).

This guide applies primarily to Windows 11 (24H2/25H2), but the same troubleshooting steps also work on supported Windows Server versions and most Windows 10 systems.

Windows Error Reporting (WER) Service Reporting

The WerFault.exe process is a background system process of the Windows Error Reporting Service (WerSvc). The WER service is enabled by default in Windows and is used to collect crash dumps after a user-mode application crashes.

When a program or system process crashes with an unhandled exception, WER detects the failure and triggers the WerFault.exe process instance to run in the background. WerFault.exe collects debugging data (may include full memory dump), sends reports to Microsoft and shows an error with basic technical info.

All the debug info is saved to the ProgramData system folder (%ALLUSERSPROFILE%\ Microsoft\Windows\ WER\ ReportArchive). For each error, a separate folder is created, which name contains the error type (Critical, AppCrash, AppHang, Kernel, etc) and the name of the failed process.

Report.wer file

Each folder contains a Report.wer file with diagnostic information, including:

• System information
• Process name and ID
• Exception codes
• Memory dumps (if enabled)

You can config LocalDumps by creating the following registry key:

HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps

Here are the common values:

• DumpFolder – folder where crash dumps are stored
• DumpType – type of dump (mini, full, etc.)
• DumpCount – maximum number of dump files to retain

Capture crash dumps with ProcDump

As an alternative to Windows Error Reporting LocalDumps, Microsoft Sysinternals ProcDump can capture app crash dumps on demand. You can use this tool to collect crash dumps without permanently modifying WER settings. Here is an example:

procdump -e -ma -n 3 app.exe

The generated dump can then be analyzed using WinDbg. Keep in mind that the -n parameter limits the number of dump files generated. This helps prevent excessive disk usage if the app crashes repeatedly.

Configure WinDbg symbols

Before analyzing a crash dump, you should config the Microsoft public symbol server to ensure accurate stack traces and module info. After opening a dump in WinDbg, run:

.symfix
.reload

Alternatively, you can config the symbol path manually:

.sympath srv*C:\Symbols*https://msdl.microsoft.com/download/symbols
.reload

Basic WinDbg analysis

After opening the crash dump in WinDbg, a few basic commands can help you to identify the root cause. The following command runs an automated crash analysis and displays the exception code, faulting module, and call stack:

!analyze -v

You can list the loaded modules (DLLs and drivers) with the command:

lm

To display the current call stack, use the command:

kb

These commands are often sufficient to identify the app module/third-party component responsible for the crash.

The following simplified output illustrates the most important fields returned by the !analyze -v command:

• FAULTING_MODULE: ntdll.dll
• PROCESS_NAME: MyApp.exe
• EXCEPTION_CODE: c0000005 (Access Violation)

In this example:

• FAULTING_MODULE identifies the module where the exception occurred. Keep in mind that this is not always the root cause — the crash may have been triggered by another app module/injected DLL.
• PROCESS_NAME identifies the executable that terminated unexpectedly.
• EXCEPTION_CODE indicates the type of failure. For example, 0xc0000005 usually represents an access violation caused by invalid memory access.

Find the name of crashed app

In some cases, the WerFault.exe error does not contain the name of the crashed application. You can find the process name in Event Viewer if this happens. You can also use Reliability Monitor (perfmon /rel) to view a graphical timeline of app crashes and system failures. This tool is often easier for beginners because it displays app failures, Windows crashes, and updates in a chronological view.

1. Open the Event Viewer (eventvwr.msc) snap-in;
2. Expand Windows Logs > Application;
3. Right-click and select the Filter Current Log;
   

   

4. Type 1000 into EventID box and click OK;
   

   

5. Only entries with an Event ID of 1000 and a source of Application Error will remain in the list of events. You should also check Event ID 1001 entries from the Windows Error Reporting source. These events often contain additional diagnostic info (including WER report IDs, crash bucket identifiers, and paths to generated dump files);
6. Look for the latest event;
7. Information about the failed EXE or DLL file is included in the description of this event.

   

   Log Name: Application
   Event ID: 1000
   Event source: Application Error
   Event message: Faulting application name: crashed.EXE, version: EXE_file_version, time stamp: EXE_file_build_time
   Exception code:
   Fault application path: EXE_path
   Fault module path: EXE_or_DLL_path

Note. If the crash occurred with one the Microsoft Store apps, the full name of the UWP application will be listed under the Faulting package full name.

In managed environments, admins typically collect Windows Error Reporting events centrally instead of reviewing Event Viewer on individual machines. Event ID 1000 and 1001 entries can be forwarded to monitoring and SIEM platforms (such as Microsoft Sentinel, Splunk, or Elastic) to detect widespread app crashes across multiple devices.

Exception Code	Meaning	Typical causes
0xc0000005	Access Violation	Invalid memory access, buggy DLLs, faulty drivers, RAM corruption
0xc0000409	Stack Buffer Overrun	Buffer overflow, corrupted app state, security mitigations
0xc0000374	Heap Corruption	Memory corruption, faulty app, third-party DLL injection
0xc0000142	DLL Initialization Failed	Missing/corrupted DLLs, app compatibility issues
0xc000007b	Invalid Image Format	32/64-bit mismatch, corrupted DLLs, missing Visual C++ runtime
0xc0000135	Unable to Locate DLL	Missing .NET runtime, missing DLL, incomplete application installation

Find crash events with PowerShell

You can also retrieve recent app crashes from PowerShell instead of using Event Viewer. Use the following command:

Get-WinEvent -FilterHashtable @{
LogName='Application'
Id=1000
} -MaxEvents 20

This command displays the latest Application Error (Event ID 1000) events and is useful for scripting, remote troubleshooting, or collecting crash info from multiple machines.

How to Fix WerFault Error on Windows

Do not worry if the WerFault error occurs once or twice. Usually, restarting the machine and relaunching the failed app is enough.

However, in some cases, recurring application errors can cause multiple WerFault.exe errors, which can be annoying for the user. In some cases, this can even cause a high CPU load and reduce computer performance (this usually happens when a crashing app repeatedly triggers the Windows Error Reporting process in a loop).

Before repairing system files/reinstalling apps, we recommend you to determine if the problem is caused by Windows itself or by third-party software/drivers.

In case the WerFault.exe error does not appear in Safe Mode/after a clean boot, it may mean that the problem is likely related to third-party services, startup apps, shell extensions, antivirus software, or device drivers.

You can perform a clean boot using msconfig and then re-enable services/startup items one-by-one to identify the problematic component.

While a clean boot is an effective way to isolate third-party software conflicts, you can use Microsoft Sysinternals tools for faster diagnostics. Autoruns helps identify non-Microsoft startup items, services, shell extensions, and drivers, while Process Monitor (ProcMon) can capture file system, registry, and process activity leading up to an app crash.

Note that recurring random WerFault.exe crashes across multiple unrelated apps may indicate faulty RAM, unstable XMP profiles, overheating, or memory overclocking instability. In this case, you should test the system memory using Windows Memory Diagnostic (mdsched.exe) or third-party tools such as MemTest86. To launch the built-in Windows memory test, press Win + R, type mdsched.exe, and restart the machine to begin diagnostics.

Check Windows for corrupted or missing system files

1. Open an elevated command prompt;
2. Scan and repair Windows image Component Store using the command:
   Dism /Online /Cleanup-Image /RestoreHealth
   

   

   Note. The DISM /RestoreHealth command may require Internet access in order to download clean component files from Windows Update. In corporate environments where computers use WSUS/isolated update infrastructure, the repair operation may fail with source file errors. In this case, you may need to specify a local Windows image source manually using the /Source parameter:
   

   Dism /Online /Cleanup-Image /RestoreHealth /Source:wim:D:\sources\install.wim:1 /LimitAccess

   In this example, DISM uses the install.wim image from the Windows installation media instead of downloading files from Windows Update. Keep in mind that most Windows 11 installation media now contains install.esd instead of install.wim, so adjust the /Source parameter accordingly.

   If your Windows installation media contains an install.esd file instead of install.wim, you need to use the esd:
   

   Dism /Online /Cleanup-Image /RestoreHealth /Source:esd:D:\sources\install.esd:1 /LimitAccess

   Keep in mind that the wim: and esd: prefixes must match the type of image file used as the repair source.
3. Then scan all protected system files and replace corrupted files using the System File Checker tool:
   sfc /scannow
4. Then check your system drive for file system errors:
   chkdsk C: /f
5. Check for Windows Updates and install them if available;
6. Check for software updates. This is particularly important if the WerFault.exe error occurs with third-party apps;
7. If possible, reinstall the application that the Werfault.exe error is referred to;
8. Try to run the faulty program in the compatible mode. (Right click > Properties > Run this program in compatible mode > Select the previous version of Windows). This is mainly useful for legacy desktop apps designed for older versions of Windows;
   

   

9. If available, use system restore points to roll back your Windows installation to a previous working state.
10. Check for hardware drivers updates and install if available:
    On Windows 10:
    Settings > Update & Security
    On Windows 11:
    Settings > Windows Update
    Or manually update drivers for core computer devices (graphics, chipset, network adapters, etc.).
    

    

11. Temporarily disable real-time protection (if appropriate) or create a temporary exclusion to determine whether your security software is causing the app crash. In managed enterprise environments, security software is often controlled centrally and should not be disabled without following your organization’s security policies.

Disable Windows Error Reporting temporarily (last resort)

If the WerFault.exe dialog itself becomes disruptive and the underlying app issue cannot be resolved immediately, you can temporarily disable Windows Error Reporting. This suppresses error reporting but does not fix the app crash.

Warning. Note that disabling WER prevents Windows from collecting crash diagnostics and sending them to Microsoft. This may also prevent Windows from generating or storing crash diagnostics and application dump files, which makes future troubleshooting significantly harder. You should only disable WER as an absolute last resort.

Enterprise environments

On domain-joined/Microsoft Entra-managed devices, Windows Error Reporting settings are often controlled centrally. Keep in mind that in case the Windows Error Reporting Service is managed by Group Policy/Microsoft Intune, manually changing the service startup type may be reverted during the next policy refresh.

• Group Policy: Computer Configuration → Administrative Templates → Windows Components → Windows Error Reporting
• Microsoft Intune: Configuration Profiles or Settings Catalog → Windows Error Reporting policies

If your device is managed by your organization, you need to check the configured policies before attempting to disable the service locally.

Still, if there are no other issues and your computer works fine, disabling the WerSvc may give you peace of mind.

1. Press Win + R and enter the services.msc command;
2. Find Windows Error Reporting Service and double-click it;
3. Stop the service and change its startup type to Disabled;
   

   

4. Save the changes and restart the computer.