How to Configure Windows Error Reporting on Windows Server 2025

How to Configure Windows Error Reporting on Windows Server 2025

Windows Error Reporting (WER) is the built-in crash and error telemetry system in Windows Server 2025 that collects diagnostic information when applications crash, hang, or encounter unhandled exceptions, and can optionally submit that information to Microsoft for analysis. In enterprise server environments, WER serves two distinct roles: as a diagnostic pipeline to Microsoft’s Watson service for identifying systemic issues in Windows and third-party software, and as a local crash dump collection mechanism that lets operations teams gather .dmp files for in-house analysis using tools like WinDbg. This guide covers the architecture of WER, configuring its behavior through Group Policy and registry settings, disabling WER for privacy-sensitive environments, setting up local dump collection for application crash analysis, reading crash dumps, and managing the Watson reporting endpoint.

Prerequisites

• Windows Server 2025 with Administrator privileges
• Group Policy Management Console (GPMC) for domain-wide policy configuration
• PowerShell 5.1 or later for registry configuration via scripts
• WinDbg (Windows Debugger) from the Windows SDK for crash dump analysis
• Sufficient free disk space for local dump file collection (varies by application)
• Understanding of organizational privacy and compliance requirements before enabling crash reporting

Step 1: Understand WER Architecture and Components

WER consists of several cooperating components. The WER service (WerSvc) runs in the background and collects error reports. The WER client (wermgr.exe) presents the familiar crash dialog when running under an interactive session. On servers without interactive sessions, WER operates silently. Reports can be queued locally and sent to Microsoft’s Watson service over HTTPS, or stored locally as dump files for internal analysis. WER also integrates with the Problem Reports and Solutions subsystem accessible via Control Panel or werconcpl.dll.

# Check WER service status
Get-Service -Name WerSvc | Select-Object Name, Status, StartType

# Start WER service if stopped
Start-Service -Name WerSvc

# Set WER service to automatic startup
Set-Service -Name WerSvc -StartupType Automatic

# View recent WER entries in the Application event log
Get-WinEvent -LogName Application | Where-Object { $_.ProviderName -eq "Windows Error Reporting" } |
    Select-Object TimeCreated, Id, Message | Format-Table -AutoSize -Wrap

# View WER report queue (pending and archived reports)
Get-ChildItem -Path "$env:ProgramDataMicrosoftWindowsWERReportQueue" -ErrorAction SilentlyContinue
Get-ChildItem -Path "$env:ProgramDataMicrosoftWindowsWERReportArchive" -ErrorAction SilentlyContinue

Step 2: Configure WER via Group Policy

Group Policy is the preferred method for controlling WER behavior consistently across a server fleet. The relevant policies are under Computer Configuration > Administrative Templates > Windows Components > Windows Error Reporting in the Group Policy Management Editor.

# Key WER Group Policy paths (for reference when configuring via GPMC):
#
# Computer ConfigurationAdministrative TemplatesWindows ComponentsWindows Error Reporting
# ├── Disable Windows Error Reporting
# ├── Do not send additional data
# ├── Prevent display of the user interface for critical errors
# ├── Configure Error Reporting
# ├── Display Error Notification
# └── Advanced Error Reporting Settings
#     ├── Report OS Errors
#     ├── Report Unplanned Shutdown Events
#     └── Configure Report Queue

# Equivalent registry configuration via PowerShell:
$werPath = "HKLM:SOFTWAREPoliciesMicrosoftWindowsWindows Error Reporting"
if (-not (Test-Path $werPath)) {
    New-Item -Path $werPath -Force | Out-Null
}

# Disable automatic sending to Microsoft (keep local collection only)
Set-ItemProperty -Path $werPath -Name "DontSendAdditionalData" -Value 1 -Type DWord

# Suppress the WER dialog on Server GUI installs (servers should not show crash dialogs)
Set-ItemProperty -Path $werPath -Name "DontShowUI" -Value 1 -Type DWord

# Set report queue max size (number of queued reports)
Set-ItemProperty -Path $werPath -Name "MaxQueueSize" -Value 50 -Type DWord

# Set maximum number of archive entries
Set-ItemProperty -Path $werPath -Name "MaxArchiveCount" -Value 500 -Type DWord

Write-Host "WER Group Policy registry settings applied."

Step 3: Disable WER Entirely for Privacy-Sensitive Servers

On servers handling sensitive workloads — healthcare data, financial records, classified information — organizations may be required by policy or regulation to disable all external crash reporting. This prevents any data, including memory contents at the time of a crash, from being transmitted to Microsoft.

# Disable WER completely via registry
$werPath = "HKLM:SOFTWAREPoliciesMicrosoftWindowsWindows Error Reporting"
if (-not (Test-Path $werPath)) {
    New-Item -Path $werPath -Force | Out-Null
}

# Disable WER (0 = enabled, 1 = disabled)
Set-ItemProperty -Path $werPath -Name "Disabled" -Value 1 -Type DWord

# Disable Watson (the Microsoft online reporting endpoint)
$watsonPath = "HKLM:SOFTWAREMicrosoftWindowsWindows Error Reporting"
Set-ItemProperty -Path $watsonPath -Name "Disabled" -Value 1 -Type DWord

# Also disable the WER service
Stop-Service -Name WerSvc -Force
Set-Service -Name WerSvc -StartupType Disabled

# Disable via group policy registry path as well
Set-ItemProperty -Path "HKLM:SOFTWAREPoliciesMicrosoftPCHealthErrorReporting" `
    -Name "DoReport" -Value 0 -Type DWord -ErrorAction SilentlyContinue

# Verify WER is disabled
(Get-ItemProperty -Path $watsonPath -Name Disabled -ErrorAction SilentlyContinue).Disabled
(Get-Service -Name WerSvc).StartType

Step 4: Configure Local Crash Dump Collection

Even when external reporting to Microsoft is disabled, you can configure WER to collect local crash dump files for internal analysis. The LocalDumps registry key controls this behavior. Local dumps are invaluable for diagnosing application crashes without needing to reproduce them or wait for vendor support.

# Configure global local dump collection
$localDumpsPath = "HKLM:SOFTWAREMicrosoftWindowsWindows Error ReportingLocalDumps"
if (-not (Test-Path $localDumpsPath)) {
    New-Item -Path $localDumpsPath -Force | Out-Null
}

# Set dump folder location
Set-ItemProperty -Path $localDumpsPath -Name "DumpFolder" -Value "C:CrashDumps" -Type ExpandString

# Set maximum number of dump files to retain per application
Set-ItemProperty -Path $localDumpsPath -Name "DumpCount" -Value 10 -Type DWord

# Set dump type:
# 1 = MiniDump (small, fast — good for most crashes)
# 2 = FullDump (complete process memory — large but most information)
Set-ItemProperty -Path $localDumpsPath -Name "DumpType" -Value 2 -Type DWord

# Create the dump folder
New-Item -Path "C:CrashDumps" -ItemType Directory -Force | Out-Null

# Configure per-application dump collection (example: w3wp.exe IIS worker)
$iisAppPath = "HKLM:SOFTWAREMicrosoftWindowsWindows Error ReportingLocalDumpsw3wp.exe"
if (-not (Test-Path $iisAppPath)) {
    New-Item -Path $iisAppPath -Force | Out-Null
}
Set-ItemProperty -Path $iisAppPath -Name "DumpFolder" -Value "C:CrashDumpsIIS" -Type ExpandString
Set-ItemProperty -Path $iisAppPath -Name "DumpCount" -Value 20 -Type DWord
Set-ItemProperty -Path $iisAppPath -Name "DumpType" -Value 2 -Type DWord
New-Item -Path "C:CrashDumpsIIS" -ItemType Directory -Force | Out-Null

Write-Host "Local dump collection configured."
Get-ChildItem -Path $localDumpsPath

Step 5: Analyze Crash Dumps with WinDbg

WinDbg (Windows Debugger) is the primary tool for analyzing crash dump files. It ships as part of the Windows SDK or can be installed standalone from the Microsoft Store as “WinDbg Preview”. The !analyze -v command performs automated crash analysis and is usually the first command to run on any new dump.

# Install WinDbg via winget (Windows Package Manager)
winget install Microsoft.WinDbg

# Open a dump file from command line (after installing WinDbg)
# WinDbg.exe -z "C:CrashDumpsw3wp.exe.14328.dmp"

# Common WinDbg commands for server crash analysis:
# !analyze -v           -- Automated root cause analysis (start here)
# !process 0 0          -- List all processes at time of dump
# !thread               -- Show current thread call stack
# k                     -- Stack backtrace
# lm                    -- List loaded modules
# .lastevent            -- Show the event that caused the dump
# !gle                  -- Get last error for current thread
# !heap -s              -- Heap usage summary
# dt nt!_EPROCESS       -- Dump type definition

# PowerShell to list crash dumps with size and age
Get-ChildItem -Path "C:CrashDumps" -Recurse -Filter "*.dmp" |
    Select-Object Name, DirectoryName,
        @{N="SizeMB"; E={[math]::Round($_.Length / 1MB, 2)}},
        LastWriteTime |
    Sort-Object LastWriteTime -Descending |
    Format-Table -AutoSize

Step 6: Configure WER via PowerShell DSC or Automation Script

For consistent deployment across multiple servers, encapsulate your WER configuration into a reusable PowerShell function or DSC resource that can be applied during server provisioning.

# Reusable WER configuration function for server hardening scripts
function Set-ServerWERPolicy {
    param(
        [bool]$DisableExternalReporting = $true,
        [bool]$EnableLocalDumps = $true,
        [string]$DumpPath = "C:CrashDumps",
        [ValidateSet(1,2)]
        [int]$DumpType = 2
    )

    $werBase = "HKLM:SOFTWAREMicrosoftWindowsWindows Error Reporting"
    $werPolicy = "HKLM:SOFTWAREPoliciesMicrosoftWindowsWindows Error Reporting"

    foreach ($path in @($werBase, $werPolicy)) {
        if (-not (Test-Path $path)) { New-Item -Path $path -Force | Out-Null }
    }

    if ($DisableExternalReporting) {
        Set-ItemProperty -Path $werBase -Name "Disabled" -Value 1 -Type DWord
        Set-ItemProperty -Path $werPolicy -Name "Disabled" -Value 1 -Type DWord
        Set-ItemProperty -Path $werPolicy -Name "DontSendAdditionalData" -Value 1 -Type DWord
        Set-ItemProperty -Path $werPolicy -Name "DontShowUI" -Value 1 -Type DWord
        Write-Host "[WER] External reporting disabled."
    }

    if ($EnableLocalDumps) {
        $dumpsKey = "$werBaseLocalDumps"
        if (-not (Test-Path $dumpsKey)) { New-Item -Path $dumpsKey -Force | Out-Null }
        New-Item -Path $DumpPath -ItemType Directory -Force | Out-Null
        Set-ItemProperty -Path $dumpsKey -Name "DumpFolder" -Value $DumpPath -Type ExpandString
        Set-ItemProperty -Path $dumpsKey -Name "DumpCount" -Value 10 -Type DWord
        Set-ItemProperty -Path $dumpsKey -Name "DumpType" -Value $DumpType -Type DWord
        Write-Host "[WER] Local dump collection enabled. Path: $DumpPath"
    }
}

# Apply to the local server
Set-ServerWERPolicy -DisableExternalReporting $true -EnableLocalDumps $true -DumpPath "C:CrashDumps"

# Apply to remote servers via Invoke-Command
$servers = @("APP01", "APP02", "DB01")
Invoke-Command -ComputerName $servers -ScriptBlock ${function:Set-ServerWERPolicy} `
    -ArgumentList $true, $true, "C:CrashDumps", 2

Conclusion

Configuring Windows Error Reporting on Windows Server 2025 requires balancing diagnostic value against privacy and compliance obligations. For most enterprise server environments, the recommended posture is to disable external reporting to Microsoft while enabling local crash dump collection — giving operations and development teams full access to diagnostic data without any data leaving the organization. By using the LocalDumps registry keys with full dumps enabled and WinDbg for analysis, you gain a powerful crash investigation capability that can dramatically reduce mean time to resolution for application-level failures. Standardize your WER configuration through Group Policy or a PowerShell provisioning script to ensure every server in your fleet has consistent diagnostic settings from day one.