How to Investigate Windows 10 and 11 Crashes Using Reliability Monitor and Event Viewer

BGR's Obaid Ur Rehman recently wrote up the pairing. His point is that an unexplained crash doesn't automatically mean a dead GPU, CPU, motherboard or RAM stick. Windows may already hold a record that narrows things down. This guide covers the workflow and adds the cautions Microsoft's own documentation attaches.

Start with Reliability Monitor: find when it went wrong​

Reliability Monitor gives you a timeline. Use it to pin down the date and rough time of the problem, then switch to Event Viewer for detail.

1. Press Win+R.
2. Type perfmon /rel and press Enter. Several guides also say you can search Start for "View reliability history". Press Windows key + R, enter perfmon /rel, and press Enter. You can also search Start for View reliability history.
3. Check the stability graph and the event list beneath it. You can switch the view between days and weeks. Selecting a day or week shows its details at the bottom.
4. Look for critical events, which one guide describes as a red circle with a white "X" for an application crash, Windows crash, or unresponsiveness.
5. Open View technical details on the entry for the failure details.

The command works on both Windows 10 and Windows 11. Reliability Monitor keeps up to a year of history, according to the ElevenForum tutorial. Other third-party guides give shorter figures for the daily view, so don't treat the retention period as settled.

How to read it: the timestamps let you compare failures with changes made around the same time. If an application starts crashing after an update, look at that application and its update. If a hardware error appears near a freeze, look at that hardware. Don't assume the first error on the screen caused the crash. Reliability Monitor is a triage tool. It can show the time and type of failure, but it often can't explain the underlying cause.

Move to Event Viewer: find what was logged​

Microsoft describes Event Viewer as a Management Console snap-in. It shows each event's source, date and time, and any error codes or messages.

Ways to open it, per Microsoft Support:

• Search for Event Viewer in the Start menu.
• Right-click Start and choose Event Viewer.
• Press Win+R, type eventvwr.msc and press Enter.

Then:

1. Expand Windows Logs.
2. Choose System if the whole PC restarted or froze. Choose Application if one program crashed and Windows stayed up. A game crashing over a graphics driver problem may need both.
3. Look for Critical and Error entries near the crash time.
4. Double-click an event and read the General and Details tabs.

To avoid scrolling through hundreds of events, filter the log. Click Filter Current Log in the Actions pane, tick Critical and Error under event level, and enter the event IDs you want. Every event has a level (Critical, Error, Warning or Information), a source and an ID. Microsoft warns that the same event number can be associated with different sources, so always read the ID together with its source.

Event IDs worth knowing​

Microsoft Learn's guide to unexpected reboots lists these as the clues for rebuilding a shutdown and reboot history. It is written for Windows Server, but the events appear on client Windows too.

Microsoft says a normal restart typically shows Event 1074, then 13 and 6009. An unexpected one is marked by Events 41 and 6008, often with 1001 if a bug check occurred. Filtering for 12, 13, 19, 41, 1001, 1074, 6008, 6009 and 7045 together gives you a history. You can see when the first unexpected reboot happened and whether a driver, service or update landed shortly before it.

Microsoft's own example is a driver-related service install (event 7045) followed soon after by bug checks. Its suggested response is to roll back or remove the driver and see whether the crashes stop. If they don't, collect a memory dump for analysis. Nearby timing is a reason to test, not proof of cause.

The Event 41 trap​

Event 41 is the entry most people find first, and the one most often misread. Microsoft's Windows client guidance says it records that Windows detected an unclean shutdown. On its own it may not say why. It can follow a stop error, a power interruption or a hang.

Practical points from that guidance:

• The event's BugcheckCode is recorded in decimal. Bug-check references usually use hex. Microsoft's example is that decimal 159 is 0x9F.
• If the bug-check code is zero, or Event 41 is missing, Windows may have shut down too quickly to log the error. It may also have been unable to write to disk, or lost power. Microsoft lists a drained or removed laptop battery, an unplugged desktop, a power outage, and an underpowered or faulty power supply as possibilities.
• A zero code doesn't prove the power supply is bad. It means the log doesn't have enough information.
• A nonzero PowerButtonTimestamp can indicate a forced shutdown using the power button.
• When the fields are zero, Microsoft suggests checking for volmgr Event 46, "Crash dump initialization failed". Its other leads are overclocking, memory configuration and health, power-supply capacity, and overheating.

BGR's piece says logs can help you tell a faulty driver, an application, a hardware issue or a power loss apart. That is a fair hope, but the Event 41 caveats show why "exactly why" is too strong. Sometimes Windows can't write the evidence at all.

When you saw a stop code​

If you saw a stop screen, Microsoft says the code, such as PAGE_FAULT_IN_NONPAGED_AREA or MEMORY_MANAGEMENT, appears on screen. If available, it also shows the module that was running at the time. An unexpected restart might be caused by a hardware device, its driver, or software. On Windows 11, version 24H2 and later may show a black stop-error screen, while 23H2 and older show the blue style.

Microsoft says a single unexpected restart usually needs no action. If the same stop code keeps recurring, its basic steps are:

1. Remove any newly added hardware.
2. Start in Safe Mode if Windows won't boot normally.
3. Open Device Manager and check for devices marked with an exclamation point. Update the driver, or disable or uninstall the device if that doesn't help.
4. Keep 10% to 15% of the drive free. Microsoft calls this a good idea, and the exact need varies.
5. Install the latest Windows updates.
6. If nothing helps, restore from a restore point or use another recovery option.

A sensible workflow​

1. Note roughly when the crash happened.
2. Use Reliability Monitor to find that date and see which entries cluster there.
3. In Event Viewer's System log, check for Events 41, 6008 and 1001. Look for the bug-check code and dump path.
4. Check 1074 to rule out a requested restart. Check 19 and 7045 for updates or service installs nearby.
5. If Event 41 offers nothing useful, treat the result as inconclusive. Consider a freeze, power loss or forced shutdown, and widen the search to nearby System and Application events.
6. Change one thing at a time, such as a driver rollback, and watch whether the crashes continue.

Bottom line​

Reliability Monitor and Event Viewer are free, already installed, and good at establishing a timeline. They won't always name a culprit. A crash with no bug-check data tells you the evidence wasn't captured, not that the hardware is faulty. Use the logs to narrow the field, and be sceptical of any single entry presented as the answer.