How to Configure Network Load Balancing on Windows Server 2022

What Is Windows Error Reporting?

Windows Error Reporting (WER) is an infrastructure built into Windows Server 2022 that automatically detects application crashes, hangs, kernel-mode failures, and driver problems, collects diagnostic data, and can transmit reports to Microsoft or a corporate WER server for analysis. WER captures the data needed to diagnose failures — crash dumps, application event logs, version information, module load order — and stores or transmits it without requiring manual administrator intervention at the moment of the crash.

For server administrators, WER serves two critical purposes. First, it provides crash artifacts (dump files) that can be analyzed with a debugger to identify the root cause of failures in production. Second, in large enterprise environments, it enables centralized collection of crash data from hundreds of servers to a corporate Windows Server WER (WS-WER) server, allowing pattern identification across a fleet.

WER is distinct from the Windows Error Reporting service (WerSvc). The service queues and uploads reports. WerFault.exe is the process that runs at crash time to capture the report data. Both must be configured correctly for WER to function.

The Windows Error Reporting Service

The WerSvc service (Windows Error Reporting Service) manages the queuing and sending of error reports. Check its current status:

Get-Service -Name WerSvc

On Windows Server 2022, WerSvc is set to Manual (Trigger Start) by default — it starts automatically when an error report is queued. For corporate WER server environments, set it to Automatic to ensure reports are always uploaded promptly:

Set-Service -Name WerSvc -StartupType Automatic
Start-Service -Name WerSvc

The WerFault.exe process runs briefly at crash time to capture the report. It is located at C:WindowsSystem32WerFault.exe. Do not block or terminate this process — doing so prevents dump files from being collected.

Configuring WER via Group Policy

Group Policy is the primary enterprise mechanism for configuring WER consistently across many servers. WER settings are under Computer Configuration > Administrative Templates > Windows Components > Windows Error Reporting. Key policies include:

Disable Windows Error Reporting — Turns off all WER functionality. Not recommended for servers you need to diagnose.

Do not send additional data — Prevents sending extended WER data (heap dumps, supplemental files) to Microsoft. Recommended for environments with data sensitivity requirements.

Configure Corporate Windows Error Reporting — Redirects all WER reports to an internal WS-WER server instead of Microsoft. Set the server name here.

Automatically send memory dumps for OS-generated error reports — Controls whether minidumps generated by crash events are included in WER reports.

Queue behavior for applications errors — Controls whether reports are queued for sending or discarded when the reporting server is unavailable.

To configure these via PowerShell using Group Policy registry writes to apply immediately on the local machine, see the registry section below.

WER Registry Settings

WER is primarily controlled through registry values under HKLMSOFTWAREMicrosoftWindowsWindows Error Reporting. The most important keys and values are:

Disable WER entirely (value 1 disables, 0 enables):

Set-ItemProperty -Path "HKLM:SOFTWAREMicrosoftWindowsWindows Error Reporting" -Name "Disabled" -Value 0 -Type DWord

Set WER to corporate server mode (consent to send without prompting):

Set-ItemProperty -Path "HKLM:SOFTWAREMicrosoftWindowsWindows Error Reporting" -Name "DontSendAdditionalData" -Value 0 -Type DWord
Set-ItemProperty -Path "HKLM:SOFTWAREMicrosoftWindowsWindows Error Reporting" -Name "LoggingDisabled" -Value 0 -Type DWord

Configure the corporate WER server (requires creating the subkey if it does not exist):

$werPath = "HKLM:SOFTWAREMicrosoftWindowsWindows Error ReportingCorporateWerServer"
If (-not (Test-Path $werPath)) { New-Item -Path $werPath -Force }
Set-ItemProperty -Path $werPath -Name "Server" -Value "wer.corp.local" -Type String
Set-ItemProperty -Path $werPath -Name "Port" -Value 1273 -Type DWord
Set-ItemProperty -Path $werPath -Name "IsPeer" -Value 0 -Type DWord

Set the local dump folder where WER stores crash report data before sending:

$localDumpPath = "HKLM:SOFTWAREMicrosoftWindowsWindows Error ReportingLocalDumps"
If (-not (Test-Path $localDumpPath)) { New-Item -Path $localDumpPath -Force }
Set-ItemProperty -Path $localDumpPath -Name "DumpFolder" -Value "C:CrashDumps" -Type ExpandString
Set-ItemProperty -Path $localDumpPath -Name "DumpCount" -Value 10 -Type DWord
Set-ItemProperty -Path $localDumpPath -Name "DumpType" -Value 2 -Type DWord

The DumpType value controls the type of dump: 0 = custom, 1 = mini dump (small, fast), 2 = full dump (complete process memory). For detailed post-mortem debugging, use full dumps. For storage-constrained environments or high-frequency crashes, use mini dumps.

WER Data Collection Paths

WER stores queued reports and local crash data in the following locations on Windows Server 2022:

User-mode crash reports (per-user): C:Users%USERNAME%AppDataLocalMicrosoftWindowsWERReportQueue and ReportArchive.

Machine-wide crash reports: C:ProgramDataMicrosoftWindowsWERReportQueue and ReportArchive.

LocalDumps folder (if configured via registry): the path specified in the DumpFolder registry value above.

List existing WER reports in the machine-wide location:

Get-ChildItem -Path "C:ProgramDataMicrosoftWindowsWERReportArchive" -Directory | 
    Sort-Object LastWriteTime -Descending | 
    Select-Object Name, LastWriteTime

Each report folder contains a Report.wer file (text, machine-readable report metadata), an AppCompat.txt file (installed applications list), and potentially a minidump .mdmp file.

Configuring Crash Dump Types

Kernel crash dump settings (for blue screen / BSOD events) are separate from WER’s user-mode LocalDumps and are controlled under System Properties > Advanced > Startup and Recovery, or via registry at HKLMSYSTEMCurrentControlSetControlCrashControl:

Set kernel crash dump to full memory dump:

Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlCrashControl" -Name "CrashDumpEnabled" -Value 1 -Type DWord

CrashDumpEnabled values: 0 = none, 1 = complete memory dump, 2 = kernel memory dump, 3 = small memory dump (minidump), 7 = automatic memory dump (recommended for most servers — Windows chooses the appropriate size automatically).

Set the dump file path:

Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlCrashControl" -Name "DumpFile" -Value "C:WindowsMEMORY.DMP" -Type ExpandString

Ensure the system is set to automatically restart after a BSOD (recommended for production servers):

Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlCrashControl" -Name "AutoReboot" -Value 1 -Type DWord

WerFault.exe and Problem Reports

WerFault.exe is invoked by the OS at crash time (for user-mode application crashes) to collect the crash report. It runs briefly and then exits. On Server Core, WerFault still runs but there is no GUI prompt shown to users — reports are queued silently.

To manually invoke WerFault to simulate a crash report for testing:

WerFault.exe -u -p  -ip  -s 

View application crash events in the Windows Event Log (Application log, EventID 1000 for application crashes, 1001 for WER reporting):

Get-WinEvent -FilterHashtable @{LogName='Application'; Id=1000; StartTime=(Get-Date).AddDays(-7)} | 
    Select-Object TimeCreated, Message | 
    Format-List

Corporate WER Server (WS-WER)

Windows Server WER (WS-WER) is a server-side component available through the Windows Error Reporting enterprise solution. It acts as a proxy — receiving WER reports from your servers and either storing them locally or forwarding them to Microsoft. This is valuable in environments where servers cannot reach the public internet but you still want centralized crash data collection.

WS-WER is deployed as an IIS web application on a Windows Server. Client machines are configured to point at it via the Group Policy or registry settings described above. The default port is 1273 (HTTP) or 443 (HTTPS). After configuring your servers to send to the WS-WER endpoint, the server-side application collects reports into a configurable storage location and optionally relays them to Microsoft’s WER service.

Verify WER is sending to the corporate server by checking the WER log:

Get-WinEvent -LogName 'Application' -FilterXPath "*[System[Provider[@Name='Windows Error Reporting']]]" | 
    Select-Object -First 20 TimeCreated, Message | Format-List

Analyzing Crash Dumps with WinDbg

WinDbg (Windows Debugger) from the Windows SDK is the standard tool for analyzing crash dumps captured by WER or the kernel crash mechanism. Install WinDbg from the Microsoft Store or via the Windows SDK installer. To open and analyze a dump:

windbg -z C:CrashDumpsAppName.exe.3928.dmp

In the WinDbg command window, configure the Microsoft public symbol server and run the basic crash analysis command:

.symfix
.reload
!analyze -v

The !analyze -v output provides the faulting module, exception code, stack trace, and in many cases a direct pointer to the root cause. For kernel dump files (MEMORY.DMP from a BSOD), the analysis identifies the bugcheck code, the faulting driver, and the call stack at the time of the crash — essential information for hardware driver issues, memory corruption, and kernel-mode component failures.