XDA’s João Carrasqueira makes a useful case against treating Event Viewer as a daily maintenance checklist. But “most errors are normal” is better understood as reassurance than as a measurable rule. The more defensible advice is that severity labels and totals, on their own, cannot tell you what needs fixing.
What Event Viewer’s severity levels actually mean
Microsoft defines five predefined Windows Event Log levels. These describe the kind of event being reported, rather than prescribing a repair for every entry.
| Level | Microsoft’s definition, summarized |
|---|---|
| Critical | An abnormal termination or exit |
| Error | A severe error event |
| Warning | A warning condition, such as an allocation failure |
| Information | A non-error event, such as entering or leaving an operation |
| Verbose | Detailed tracing information |
These definitions also explain why some common assumptions fall short. Information does not necessarily mean “everything completed successfully,” while Critical does not necessarily mean “a component is permanently defective.” The label classifies the event; interpreting the machine’s condition requires additional evidence.
An error count cannot make that distinction for you. The sensible question is not “How do I eliminate every red icon?” It is “Which entries help explain the problem I am investigating?”
Why a Critical event may describe the aftermath
Kernel-Power Event ID 41 is a particularly useful example. Microsoft explains that Windows records it at the next startup after an unexpected shutdown. Possible circumstances include interrupted power, a stop error, or a forced power-off. The entry alone may not establish which occurred.
Consider a desktop losing power during an outage. An Event ID 41 afterward is consistent with that interruption; it does not independently prove a defective power supply or damaged Windows installation. That is an interpretation of Microsoft’s documented behavior, not a hardware diagnosis.
There is a practical timing wrinkle, too: because Windows writes this event during the following startup, its timestamp need not be the exact moment the original failure began. Microsoft recommends examining surrounding evidence, including entries before the shutdown.
The takeaway: an event can document a consequence without identifying the cause. Replacing hardware or changing system settings based solely on that entry gets the investigation backward.
A calmer Windows 11 troubleshooting workflow
For a Windows 11 PC that actually crashes, freezes, or restarts unexpectedly, use Event Viewer to answer a specific question. Microsoft’s stop-error guidance supports examining event logs alongside the stop code and other diagnostic evidence.
- Record the symptom and approximate time. Note what you were doing and whether the problem followed a hardware, driver, or software change. If Windows displays a stop code or module name, record that too; Microsoft identifies both as useful clues.
- Open Event Viewer and inspect the System log. Concentrate on entries around the incident rather than the accumulated total. Microsoft recommends checking this log for messages that may identify a relevant device or driver.
- Read the event’s source, message, and details. Do not research an event number in isolation: Microsoft cautions that different sources can use the same numbers. Match the source as well as the ID.
- Compare the sequence, not just one entry. For an unexpected shutdown, Microsoft recommends checking both Application and System logs for relevant preceding events. Treat a nearby entry as a lead to investigate, not proof of causation.
- Escalate recurring failures. Microsoft distinguishes an isolated unexpected restart from frequent restarts with the same stop code, for which further troubleshooting is warranted. Its basic steps include checking recent hardware changes, Device Manager, available disk space, and Windows Update.
Success here means gathering a useful description of the failure and narrowing the investigation. It does not mean making Event Viewer empty.
If no clear cause appears, that is not permission to guess. Microsoft explicitly warns that Event ID 41 may lack enough information to explain an incident; additional diagnostic evidence may be necessary.
Reliability Monitor is another starting point
For readers who prefer the alternative highlighted by XDA, Windows 11 includes Reliability Monitor. Microsoft documents a direct launch command: perfmon /rel. Press Windows + R, enter that command, and press Enter; the expected result is Reliability Monitor opening. No third-party download is required.
Use it as another way into an investigation, not as a promise that every failure will receive a neat explanation. Nor should it be described as an identical copy of Event Viewer: Microsoft’s command reference confirms how to launch it, not equivalence between the tools.
Don’t confuse reassurance with ignoring evidence
For home users, the sensible conclusion is to stop chasing an error-free log. It is not to dismiss recurring crashes or assume every Warning is harmless. Microsoft’s guidance calls for further investigation when stop-code failures recur, using the symptom and supporting evidence to choose the next step.
There is also an important boundary for IT administrators: proactive log review can be valuable. Microsoft documents using filtered system events to establish reboot history, frequency, and possible causes. “Don’t obsess over your personal PC’s error total” should not become “never monitor logs.”
Event Viewer is evidence, not a verdict. Investigate relevant patterns, preserve the distinction between cause and aftermath, and resist repairs aimed only at silencing a label. The goal is a reliable computer—not a spotless-looking log.