Blue screens and crashes
finding the component at fault instead of guessing

Why is a random crash actually diagnosable?

The sentence I hear most often is that the computer just crashes sometimes, for no reason. To the person sitting in front of it, that is exactly how it looks: the machine drops out from under them before they can read anything. To the machine, none of it is random. Before Windows goes down it writes a line to the system log with a fault code and an exact time, and in most cases it also saves a picture of memory to disk. The evidence exists. The only question is whether anyone collected it.

The XIT agent sends a health snapshot every 15 minutes. Each snapshot carries the crash count for the last 30 days, the number of critical system-log errors in the last 24 hours, and the crash events themselves — each with a timestamp and a stop code. The threshold is deliberately low: one blue screen in 30 days already raises a warning. Separately, 50 or more system errors in 24 hours raises its own warning, because a machine flooding its own log is usually on the way to a crash rather than past one.

The difference between "it crashes sometimes" and a diagnosis is not talent, it is data. Anyone who looks at the machine only after the user complains sees a computer that works. Anyone who looks at its history sees that the crashes started on precisely the day a particular driver was installed.

Event 1001 versus event 41 — the distinction that matters

XIT's crash count is built on two Windows system-log event IDs, over a 30-day window:

• Event 1001 (BugCheck) — a genuine blue screen. Windows hit a condition it could not recover from, stopped, and recorded a stop code in 0x00000000 form. This is a fault.
• Event 41 (Kernel-Power) — the machine started up without a clean shutdown having happened first. It does not say the machine crashed. It says the machine lost power or was cut off before it could shut down properly.

This is not pedantry. An event 41 with no event 1001 beside it is usually electrical, not software — a power cut, a long press on the power button, an overloaded strip, or a power supply beginning to fail. A machine with five event 41s and zero event 1001s did not crash five times, and treating it as though it did sends the repair in the wrong direction entirely: swapping drivers and reinstalling the operating system when the problem is a wall socket.

So the XIT dashboard never shows a single number. It shows real blue screens and unclean shutdowns and restarts as two separate figures, and adds a line stating that an unclean shutdown is not a blue screen. Event 6008, Windows' companion record for an unexpected shutdown, is counted separately again.

Then comes the step that turns counting into diagnosis: every event 41 is correlated against what happened in the 15 minutes before it. The agent also collects 30 days of hardware and storage events — WHEA-Logger (CPU, memory and PCIe errors), disk and NTFS events, storage-controller events and Kernel-Processor-Power — each timestamped. If an event 1001 falls inside that window, the restart came from a real blue screen and the stop code is shown. A WHEA error points at hardware: memory, CPU or heat. A disk or controller error points at storage. And if nothing is found, the report says exactly that: an unclean shutdown of unknown cause, most often power, not necessarily a fault at all.

How a memory dump names the component at fault

When a blue screen happens, Windows does more than stop. It writes an image of memory to disk — a dump file. The small variant, the minidump, lands in C:\Windows\Minidump and is usually a few hundred kilobytes. Inside it are two things available nowhere else: the exact stop code, and the name of the module or driver that was executing when the system died.

XIT's crash-analysis check reads those files directly. It pulls the stop code from the dump header, translates it into a name and a classification, and cross-references it with the BugCheck detail in event 1001. Each code points at a family of problems:

• 0xD1 DRIVER_IRQL_NOT_LESS_OR_EQUAL and 0x3B SYSTEM_SERVICE_EXCEPTION — a driver.
• 0x1A MEMORY_MANAGEMENT and 0x50 PAGE_FAULT_IN_NONPAGED_AREA — memory or a driver.
• 0x124 WHEA_UNCORRECTABLE_ERROR — hardware: CPU, memory or heat. This one is almost never software.
• 0x133 DPC_WATCHDOG_VIOLATION — a driver or a disk that stopped responding in time.
• 0x9F DRIVER_POWER_STATE_FAILURE — a driver that hung going into sleep or shutdown.

That classification alone already points the work in the right direction. When the exact filename is needed, Microsoft's debugging tools can be installed on that specific machine, and the check then runs a deep analysis that returns the MODULE_NAME, IMAGE_NAME and "probably caused by" fields — the actual .sys file. The tools go only on a machine that has crashes to analyse, never across the whole fleet.

Why is crash dumping checked before the crash?

This is where most crash investigations quietly fail. Windows only writes a dump if the setting is on. It lives in the registry under CrashControl, and the values are: no dump at all, small (minidump), kernel, complete, or automatic. If the value is none — and it happens, whether from an optimisation tool, a vendor image or a manual change — the machine can blue-screen ten times and leave zero evidence.

The trap is that you discover this after the crash, when it is already too late. So the crash-dump setting is checked as routine, in every snapshot, before any crash has happened. It is not a check you run when something breaks; it is the check that guarantees there will be something to read when something does. The status appears in the customer report as crash logging for diagnosis.

There is a second condition: writing a dump needs free disk space. A machine down to under 10% free is not only slow — it may also fail to save the evidence of its own crash. That is one reason the hardware check and disk space are not a separate topic from crashes.

An application crash is not a system crash

Both get called "a crash" and they have almost nothing in common.

An application crash is event 1000 (Application Error) or 1002 (Application Hang): one program dies, the computer carries on. Chrome closes itself, Teams freezes, Excel stops responding. Once is ordinary noise and needs no action. The agent counts application crashes over 30 days and breaks them down by application name, because the difference between "something crashed once" and "this same application crashed 40 times" is the difference between noise and a finding.

A system crash is a blue screen: the kernel itself went down and took everything with it. On a Mac the equivalent is a kernel panic, checked separately in the system log.

Why this costs money: whoever conflates the two treats a Chrome crash as a memory problem, buys new RAM and fixes nothing. And whoever shrugs off a blue screen because "Chrome crashes sometimes too" misses a dying disk. The XIT report separates them inside one section — stability and crashes — with distinct lines for application crashes, system crashes, crash analysis, crash logging, shutdown and startup behaviour, and stability over time.

Cause table: what broke and how you know

Each common cause has its own identifying signal. This is the table you decide by, instead of replacing parts in a random order:

One caveat: a single blue screen after a large update is sometimes a one-off. What decides is recurrence — the same stop code, or the same file, showing up again.

Stability over time — one crash versus decline

A machine that crashed once three weeks ago and has been fine since is not the same machine as one that crashes every week, a little worse each time. A 30-day count alone cannot tell them apart. History can.

Snapshots are retained for 60 days, which is what makes trend rather than moment visible. The health score is judged on a 7-day window: because every blue screen carries a timestamp, a machine that crashed three weeks ago and has been stable since is not penalised forever. Application crashes, by contrast, arrive as a bare count with no timestamps anywhere — so they stay a 30-day figure and are labelled as one, rather than being passed off as something that happened this week.

History also produces two signals no single snapshot can give: three or more restarts in seven days flags a suspected stability or hardware problem, while a machine that has not restarted in over 30 days gets a note — not as a fault, but because a restart applies pending updates and frees memory. Neither is ever forced: XIT recommends the restart and the customer picks the moment. There is also a dedicated check that pulls the system reliability timeline — crashes, update installations and driver installations in one chronological sequence. That is the view that answers "what changed the day this started", and it is often clearer than the event log itself. More on the underlying mechanism is on the monitoring page.

Why reinstalling Windows is the wrong first move

Reinstalling is the popular answer because it feels like a clean slate. In practice it does two bad things: it destroys the evidence — the event log and the dump files disappear with the old installation — and it does not touch most of the real causes. Failing memory stays failing. A dying disk keeps dying. A weak power supply stays weak. Heat stays heat.

Even when the culprit genuinely is software — a driver — reinstalling usually does not help, because Windows Update will detect the hardware and install that exact same driver again. Half a day of work, every application set up from scratch, and the same crash returns next week.

The sensible order is the reverse: preserve the evidence, read the stop code, identify the family (driver, memory, storage, heat, power), and only then act. A reinstall is a legitimate tool — at the end of the list, once you know it is not hardware, not at the start instead of knowing.

What XIT actually does when a machine crashes

XIT is a managed IT service for home users, freelancers and small businesses in Israel. A lightweight agent runs on the machine and sends a snapshot every 15 minutes, and behind the data sits a human technician who acts on what it shows. A machine that has not reported for one hour is flagged, and after 24 hours it is critical — because a computer that stopped reporting in the middle of the day is sometimes exactly the computer that crashed.

The moment a single blue screen is counted, an alert is raised. From there the checks are deliberate: dump-file and stop-code analysis, a review of shutdown and startup events, the stability timeline, and whichever hardware checks the code points at. The report the customer receives is written in plain language and grouped into six sections, with the stability and crashes section holding the whole picture in one place.

The agent collects system and configuration state only — it does not read, collect or upload personal files, documents, photos, email or browsing content. The full explanation is on the report privacy page. Packages are $5 per month per computer for monitoring, and $10 per month per computer for monitoring plus a human technician; the detail is on the pricing page, and what is included is on the services page.

FAQ

Read next

• Hardware check — memory, disk and heat: the physical side of most crashes
• Computer monitoring — what is measured every 15 minutes and how 60 days becomes a trend
• Updates and maintenance — the update or driver that landed the day before the crashes started
• Pricing — $5 and $10 per month per computer, crash analysis included