Reliability Monitor: the built-in view that answers "what changed before it broke"

A user tells you their laptop "started crashing last week". You open Event Viewer. You get twelve thousand lines across two logs, sorted by time, with no way to see that the crashes began four hours after a graphics driver landed. So you give up and reimage.

Windows has shipped a view that answers exactly that question since Windows Vista. It puts application failures, Windows failures, warnings and - the part that matters - informational events for driver installs, update installs and application installs on one shared timeline. It is called Reliability Monitor. You launch it by typing perfmon /rel. Almost nobody does.

This post explains what Reliability Monitor actually aggregates, where the data physically lives, which component populates it, every documented reason it can appear empty, and how to pull the identical data with PowerShell so you can run the same correlation across a fleet instead of one machine at a time.

The problem: correlation is the whole job, and Event Viewer cannot do it

Endpoint troubleshooting is almost never about finding a crash. Crashes are easy to find. The hard part is finding what changed immediately before the crash started.

That is a correlation problem. It needs two different kinds of record on one timeline. You need the failures - the crash, the hang, the bugcheck, the dirty shutdown. And you need the changes - the driver that installed, the quality update that applied, the application that a management agent reconfigured.

Event Viewer will not do this for you. The failures land in the Application log. Most of the changes land in the System log. Event Viewer can filter one channel at a time, or build a custom view across channels, but it has no concept of "show me installs and crashes side by side and highlight the gap between them". You end up exporting to CSV and doing it in Excel.

Reliability Monitor already does it. It reads both logs. It keeps only the records that bear on reliability. It classifies each one as a failure or an informational change. Then it draws them as rows on a shared day-by-day chart. Click a day and you get every failure and every install for that day in one report.

The reason nobody uses it is discoverability. It is not in the Start menu. It is not in Settings. It lives behind a command-line switch on perfmon, or four clicks deep in the legacy Control Panel, and the modern Windows 11 Settings app never mentions it.

Why it happens: Reliability Monitor is a WMI client and nothing says so

Before configuring anything, understand the chain. It is short, and knowing it tells you exactly where to look when the view is empty.

The chain, from event to pixel

1. Something happens on the device. An application crashes, a driver installs, Windows Update finishes. The responsible component writes an event to the Application or System event log through the normal Windows event pipeline.
2. The Reliability Analysis Component reads those logs. It keeps the subset of records that describe reliability, and it calculates the System Stability Index from them. The engine that does the calculation is C:\Windows\System32\RacEngn.dll. Its own file description reads "Reliability analysis metrics calculation engine".
3. The Reliability Metrics WMI Provider, C:\Windows\System32\wbem\RacWmiProv.dll, exposes the result as two WMI classes in the Root\CIMV2 namespace. Microsoft documents both classes, the provider name, and the registration file.
4. The Reliability Monitor user interface asks WMI for those two classes and draws the answer. That is all it does.

Step four surprises people, so it is worth being precise about how we know it. The binary that draws the view is C:\Windows\System32\werconcpl.dll. Reading the strings out of the shipped file on a Windows 11 build 26200 machine turns up the page identifier pageReliabilityView, class names such as CReliabilityView and CRacWmiQuerySink, and these two literal query strings:

The practical consequence is large. Anything the GUI can show you, Get-CimInstance can show you. There is no hidden data path and no private store the GUI reads that you cannot. If your PowerShell query returns nothing, the GUI is showing nothing too, and the reverse holds as well.

The two classes, and exactly what each exposes

Win32_ReliabilityRecords is the event list. One instance per reliability-relevant event log record. Microsoft documents every property.

Win32_ReliabilityStabilityMetrics is the graph. One instance per stability calculation sample.

Both classes also expose a static GetRecordCount method. That is a cheap way to ask "is there any data at all" without pulling every instance across the wire.

Microsoft documents the index behaviour, and the details matter when you read a graph:

• Recent failures are weighted more heavily than older ones. The index climbs back up once you fix something.
• Days the device was powered off or asleep are not used in the calculation. A laptop that sat in a drawer for a week is not penalised.
• If there is not yet enough data for a steady index, the graphed line is dotted rather than solid.
• A significant system clock change puts an Information icon on that day, because a clock jump distorts everything else on the timeline.

The report categories, and where each one comes from

Microsoft documents the categories the System Stability Report groups records into. Modern Windows 11 shortens the row labels on the chart, but the underlying grouping is the same.

Event Viewer: which channels and IDs actually feed the view

The two channels are stated once here. Both are classic logs, so the paths are short:

The table below lists the providers and IDs a real Windows 11 build 26200 device returned from Win32_ReliabilityRecords over a 30-day window, with the documentation status of each stated plainly.

System files and binaries in the flow

Registry: the whole reliability surface

Two of these are switches you may need to set. The other two are internal state you should read but never write.

Here is what the preference side of that looks like on a real client that has never had the policy applied. Note that the WMI subkey does not exist at all, and the providers still answer:

Why the view is empty: three documented causes and one stale one

Cause one, and by far the most common in enterprise: the Group Policy setting is Disabled. The policy is Configure Reliability WMI Providers. Microsoft's class documentation is explicit. The policy must be enabled to read either class. It is enabled by default on Windows client systems and disabled by default on Windows Server systems. And disabling it clears existing data within one hour. That last clause is why re-enabling it does not bring your history back.

Cause two: not enough uptime. Microsoft documents that Reliability Monitor starts showing a stability index and event detail about 24 hours after the operating system is installed. On a freshly imaged device, an empty view is correct behaviour rather than a fault. The GUI has a dedicated banner for this state - the string txtRacNotEnoughUptime inside werconcpl.dll.

Cause three, on servers and older builds: the RAC task trigger is disabled. Microsoft's article for a blank Reliability Monitor on Windows Server 2012 R2 states the cause directly. The recurring trigger on the RacTask task under \Microsoft\Windows\RAC is disabled after the task runs for the first time. The documented fix is to re-enable that trigger in Task Scheduler with Show Hidden Tasks turned on, set WMIEnable to 1 under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Reliability Analysis\WMI, and restart the computer.

For completeness on the historic store: the PublishedData and StateData subfolders under C:\ProgramData\Microsoft\RAC are named in a Microsoft support engineer's answer on Microsoft Q&A as the files to delete when resetting Reliability Monitor. That is a support answer rather than reference documentation, and the path does not exist on the build tested here. Treat it as historical context only.

How to verify: read the same two classes the GUI reads

Step 1: open the view by hand, once

Do this once so you know what the data looks like before you automate it. Press Win and R together, type perfmon /rel, then press Enter. The /rel switch is documented in Microsoft's perfmon command reference alongside /res, /report and /sys.

The Control Panel route reaches the same page. It is worth knowing because it is what you can walk a user through over the phone:

What you are looking at: a graph of the stability index across the top, then rows of icons per day underneath. Click any day column to load that day's report below the chart. The scroll bar at the bottom moves you outside the visible range when more than 30 days of data exist.

Step 2: confirm the providers are answering

This is the cheapest possible health check. It asks each class how many records it holds without transferring them. Run it from an elevated prompt.

Step 3: check the policy and preference values

If the counts came back zero, this tells you whether policy is the reason. Reading a value that does not exist is not an error condition here. Absent means "not configured", which Microsoft documents as enabled on client SKUs.

Step 4: look at the RAC task honestly

Do this to classify the device, not to fix it. Present-and-disabled is a real fault. Absent is normal on current Windows 11.

Step 5: run the companion script

Steps 2 to 4 confirm the plumbing. The script does the analysis. It issues the same two queries the GUI issues, classifies every record as a failure or a change, then for each distinct failing component lists what changed in the hours before that component's first failure.

git clone https://github.com/Imran76Awan/Windows-11-Scripts.git
cd Windows-11-Scripts\reliability-monitor-event-correlation
.\Get-ReliabilityTimeline.ps1 -Days 30 -CorrelationWindowHours 24 -Top 10

Useful variations. Narrow the look-back when you know the date something broke, because a 24-hour window on a busy managed device catches dozens of irrelevant installs:

.\Get-ReliabilityTimeline.ps1 -Days 14 -CorrelationWindowHours 8
.\Get-ReliabilityTimeline.ps1 -IncludeTimeline -Top 3

The fix: guarantee the data exists, then correlate it at fleet scale

Group Policy: the only first-class control surface

The policy lives in RacWmiProv.admx, which ships in C:\Windows\PolicyDefinitions on Windows 11. Its category display name is Windows Reliability Analysis, parented under Windows Components.

Console walkthrough, Group Policy Management Editor:

1. Open Group Policy Management on a domain controller or management workstation. For a local test, run gpedit.msc instead.
2. Right-click the organisational unit holding your devices and choose Create a GPO in this domain, and Link it here.
3. Name it something like Endpoint - Reliability Data and click OK.
4. Right-click the new GPO and choose Edit.
5. Expand Computer Configuration, then Policies, then Administrative Templates.
6. Expand Windows Components and select Windows Reliability Analysis.
7. Double-click Configure Reliability WMI Providers.
8. Select Enabled, then click OK.
9. On a target device run gpupdate /target:computer /force.
10. Confirm WMIEnable is now 1 under HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Reliability Analysis\WMI.
11. Wait. If the policy had previously been Disabled, the historical data was already cleared and you are starting a fresh collection window.

For a local-only test the Local Group Policy Editor path is identical:

Intune: there is no setting for this, and that is the honest answer

So what can you actually do from Intune? Three honest options, in order of preference.

Option A - do nothing, and verify. The policy is enabled by default on client Windows. On most estates the correct action is to confirm that nothing has disabled it, not to configure it. Deploy the companion script as a read-only Intune platform script and look at the results. If every device reports the providers enabled, there is nothing to configure.

Console walkthrough for deploying the read-only check:

1. Sign in to intune.microsoft.com.
2. Go to Devices, then Scripts and remediations, then the Platform scripts tab.
3. Click Add and choose Windows 10 and later.
4. Name it Reliability data health check (read-only) and add a description saying it makes no changes.
5. On Script settings, upload Get-ReliabilityTimeline.ps1.
6. Set Run this script using the logged on credentials to No. The reliability classes need SYSTEM or administrator rights.
7. Set Enforce script signature check according to your own code-signing policy.
8. Set Run script in 64 bit PowerShell Host to Yes.
9. Click Next, assign to a pilot device group, then Add.
10. Review results on the pilot before widening the assignment.

Option B - Group Policy for the machines that need it. If you have Windows Server instances, or any device where the policy was explicitly disabled, use the GPO path above. Server SKUs default to disabled, so servers are where you will actually need this.

Option C - the related settings that are in the Settings Catalog. These do not turn the providers on. They do improve the quality of the unexpected-shutdown data that feeds the Miscellaneous Failures row, so they are worth knowing.

1. Sign in to intune.microsoft.com.
2. Go to Devices, then Configuration, then Create, then New policy.
3. Platform: Windows 10 and later. Profile type: Settings catalog. Click Create.
4. Name it Endpoint - Shutdown reliability data.
5. On Configuration settings, click Add settings.
6. In the settings picker, search for Enable Persistent Time Stamp. It sits under Administrative Templates, then System.
7. Tick it, close the picker, and set it to Enabled. Leave the timestamp interval at the documented default of 60 seconds unless you have a reason to change it.
8. Optionally also add Report unplanned shutdown events, found under Administrative Templates, then Windows Components, then Windows Error Reporting, then Advanced Error Reporting Settings.
9. Click Next, assign, review and create.

The persistent timestamp is what lets Windows work out when an unexpected shutdown happened rather than only that one happened. Without it, dirty shutdowns land on the timeline with much less precision. Note the documented caveat: the feature can interfere with power settings that spin hard disks down after a period of inactivity.

Defender and endpoint security: genuinely not applicable

Nothing in this feature area touches Microsoft Defender Antivirus, Attack Surface Reduction, exploit protection, Windows Defender Application Control or the Windows Firewall. There is no Endpoint Security profile type and no ASR rule that affects reliability data collection. Reliability Monitor is a diagnostics feature, not a security feature. The only access control on it is the WMI provider policy plus normal administrator rights on the WMI namespace.

One adjacent point is worth making. Because Application Error event 1000 records the faulting module path, a reliability timeline will frequently show a security product's own DLL as the faulting module in third-party application crashes. That is correlation data, not an accusation. But it is exactly the kind of pattern this view surfaces and a single-log Event Viewer search does not.

Services and scheduled tasks: what to expect

Log files and data store paths

There is no plain-text log for this feature. The "log files" are the event log channels plus, historically, a binary store. Here is the honest picture, with the string to search for in each case.

Fleet triage: the pattern that actually scales

Once you accept that the GUI is a WMI client, the fleet approach writes itself. Collect Win32_ReliabilityRecords on a schedule, ship it to a central store, and query across devices. The MSEndpointMgr walkthrough listed in the references does precisely this, with a PowerShell collector, an Azure Function and a Log Analytics workspace. It is the best worked example of the pattern in public.

Two design notes come straight from the data. First, the store is a rolling window. On the device tested here it held about 30 days and 327 records, even though Microsoft's documentation says Reliability Monitor maintains up to a year of history. Collect at least weekly or you will lose events. Second, always ship Logfile and RecordNumber alongside each record, because those two values let you go back to the original event in Event Viewer on the device when you need full detail.

Proof it worked: a real run on a Windows 11 build 26200 device

Everything below is genuine output from Get-ReliabilityTimeline.ps1 on a domain-joined Windows 11 Enterprise build 26200 device, with the host name replaced and nothing else changed. It ran identically on Windows PowerShell 5.1 and PowerShell 7.6.5, with exit code 0 on both.

First the preflight. Note what it reports and what it declines to call a fault:

Then the data read and the stability index. The index tells you the shape of the month before you read a single event:

Now the part the GUI will not do for you. For each distinct failing component, the changes that landed in the hours before its first failure, with the gap in hours:

And the summary, which is what you would actually ship to a central store as one row per device:

Verified community deep-dives

Both of these were fetched and confirmed to load and to be on this topic.

References

• Win32_ReliabilityRecords class - every property, the ReliabilityMetricsProvider provider, RacWmiProv.dll and RacWmiProv.mof, and the statement that the Configure Reliability WMI Providers policy must be enabled.
• Win32_ReliabilityStabilityMetrics class - the stability index range, RelID reset behaviour, and the same policy requirement plus the one-hour data clear.
• perfmon command reference - the documented /rel, /res, /report and /sys switches.
• Reliability Monitor shows no information - the RacTask trigger cause, the Task Scheduler steps, and the WMIEnable registry value to set.
• Enable Data Collection for Reliability Monitor - the RACAgent scheduled task and the documented 24-hour delay after installation.
• Use Reliability Monitor to Troubleshoot - the report categories, the data fields in each, and the "up to a year of history" statement.
• Understanding the System Stability Index - weighting, powered-off days, dotted versus solid line, and clock-change icons.
• ADMX_Reliability Policy CSP - the four reliability settings that are available through MDM, and by omission the proof that Configure Reliability WMI Providers is not one of them.
• Event Logging (Windows Installer) - MsiInstaller event IDs 1033 through 1038 and what each message field contains.
• Event ID 20001 - Device Installation and Event ID 20003 - Service Installation - the driver-install records that populate the Software (Un)Installs row.
• Event ID 20 - WUA Update Installation - the Windows Update client failure record.
• Application or service crashing behavior troubleshooting guidance - Event ID 1000 as the application crashing event.
• MSEndpointMgr - Application Reliability Monitor with Log Analytics (verified) - the fleet-scale collector pattern.
• HTMD Blog - How To Check Reliability History In Windows 11 (verified) - the Windows 11 Control Panel walkthrough.
• Get-ReliabilityTimeline.ps1 - the read-only companion script for this post.

Two claims in this post came from the shipped binaries and the live device rather than from documentation, and are labelled as such throughout. The first is the pair of WQL query strings inside werconcpl.dll. The second is the complete absence of the \Microsoft\Windows\RAC task folder and the C:\ProgramData\Microsoft\RAC directory on Windows 11 build 26200 while both WMI classes still return data. Both are useful. Neither should carry a production detection rule on its own.