Introduction to Windows Reliability Monitor on Windows Server 2019

Windows Reliability Monitor is a built-in diagnostic tool in Windows Server 2019 that displays a Stability Index over time — a score from 1 (unstable) to 10 (perfectly stable) — alongside a chronological event log of application failures, Windows failures, hardware warnings, software installations, and Windows updates. Unlike Event Viewer, which requires knowing where to look, Reliability Monitor provides a visual timeline that makes it easy to correlate system instability with specific events such as a failed update, an application crash, or a driver installation. It draws data from the Reliability Analysis Component (RAC) service, which has been running in the background since the server was built. This guide covers accessing Reliability Monitor, interpreting the data, extracting reliability data programmatically, and responding to common reliability events.

Opening Reliability Monitor

There are several ways to open Reliability Monitor on Windows Server 2019:

From the Run dialog (Win+R): type perfmon /rel and press Enter. From Control Panel: navigate to System and Security > Security and Maintenance > View Reliability History. From the Action Center: click the flag icon in the system tray, then Review recent messages. From PowerShell:

Start-Process "perfmon.exe" -ArgumentList "/rel"

The Reliability Monitor window shows a graph with dates on the X-axis and the Stability Index on the Y-axis, plus icons on the timeline for each type of event. A downward trend in the Stability Index indicates increasing instability, typically caused by recurring failures.

Understanding the Reliability Monitor Interface

The main graph area shows the Stability Index plotted over time. Below the graph is a detailed event table for the selected day. The event types are categorized by columns:

Application failures (red X): Crashes and hangs in user-mode applications. Windows failures (red X): Blue screen of death (BSOD) events, unexpected shutdowns, and boot failures. Miscellaneous failures (red X): Various non-categorized reliability events. Warnings (yellow warning triangle): Application and Windows warnings that did not cause a crash but indicate potential issues. Information (blue circle-i): Software installs, software uninstalls, and Windows updates applied successfully.

Click on any event in the table to see detailed information including the faulting application name, faulting module (DLL or driver), exception code, and a link to check for solutions online (which queries Windows Error Reporting).

Interpreting the Stability Index

The Stability Index is calculated by the Reliability Analysis Component (RAC) using a weighted rolling average of failures over the past 28 days. Recent failures carry more weight than older ones. An index of 10 means no failures in the recent history. Each crash or failure lowers the score; as time passes without new failures, the score gradually recovers.

A sudden drop in the Stability Index on a specific date is a strong indicator that something changed that day — correlate it with the Information events on that date (Windows Updates, software installs) or check the Windows and Application event logs for that timestamp. A sustained low score (below 5) indicates a recurring instability issue that needs root-cause investigation.

Extracting Reliability History via PowerShell and WMI

Reliability Monitor data is stored in WMI under the Win32_ReliabilityStabilityMetrics and Win32_ReliabilityRecords classes. Use PowerShell to query and export this data for programmatic analysis or reporting.

Retrieve the Stability Index history for the past 30 days:

Get-CimInstance -ClassName Win32_ReliabilityStabilityMetrics | Select-Object SystemStabilityIndex, StartMeasurementDate, EndMeasurementDate | Sort-Object EndMeasurementDate | Format-Table -AutoSize

Retrieve recent reliability events (failures, warnings, and informational entries):

Get-CimInstance -ClassName Win32_ReliabilityRecords | Select-Object SourceName, ProductName, TimeGenerated, EventIdentifier, Message | Sort-Object TimeGenerated -Descending | Select-Object -First 20 | Format-List

Filter for only failure events (EventIdentifier values 1001, 1000, and 1002 are application crashes; 41 is unexpected shutdown):

Get-CimInstance -ClassName Win32_ReliabilityRecords | Where-Object { $_.EventIdentifier -in @(1000, 1001, 1002, 41) } | Select-Object SourceName, ProductName, TimeGenerated, Message | Sort-Object TimeGenerated -Descending | Format-List

Correlating Reliability Events with Event Viewer

Reliability Monitor provides a simplified view, but the full technical detail lives in Event Viewer. When you identify a failure event in Reliability Monitor, note the date and time, then query the corresponding Event Viewer logs. For application crashes, check the Application event log for Event ID 1000 (Application Error):

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

For unexpected shutdowns (kernel power failures), check the System event log for Event ID 41:

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

For BSOD (bugcheck) events, check Event ID 1001 in the System log:

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

Responding to Common Reliability Issues

Application crash (Event ID 1000): Note the faulting application, faulting module, and exception code. If the faulting module is a DLL that is not part of the application itself (e.g., a third-party DLL injected by antivirus), exclude the application from AV scanning or update the AV software. If the exception code is 0xc0000005 (Access Violation), the application has a memory bug — apply available patches or contact the vendor.

Windows feature failures / hung services: Check the System event log for Service Control Manager errors (Event IDs 7023, 7024, 7031, 7034, 7036) to identify which service failed and why. Verify the service’s startup account has the required permissions and that dependent services are running first.

For BSOD events, analyze the minidump file generated in C:WindowsMinidump using Windows Debugger (WinDbg). Run the following WinDbg command to analyze a dump:

!analyze -v

The output identifies the stop code, the faulting driver or module, and often points to a specific driver file to update or remove.

Disabling and Re-enabling the Reliability Monitor Service

Reliability Monitor data collection depends on the Task Scheduler tasks under MicrosoftWindowsRAC. If the Reliability Monitor shows no data or the graph appears empty, verify the RacTask task is enabled and running:

Get-ScheduledTask -TaskPath "MicrosoftWindowsRAC" | Select-Object TaskName, State

Enable and start the task if it is disabled:

Enable-ScheduledTask -TaskPath "MicrosoftWindowsRAC" -TaskName "RacTask"
Start-ScheduledTask -TaskPath "MicrosoftWindowsRAC" -TaskName "RacTask"

Reliability data is stored in C:ProgramDataMicrosoftRAC. If this folder is corrupt or missing data, the Stability Index calculation will be incomplete. Clearing this folder and restarting the RacTask will reset the reliability history and begin fresh data collection.