Computer Repair · October 26, 2026 · ComputerKing Team

Windows Blue Screens Keep Coming Back? Use the Crash Timeline and Stop-Code Pattern to Decide: Reinstall, Replace, or Get Help

One blue screen and repeated blue screens are two completely different problems. This article shows how to log each crash, check it against Windows' reliability timeline, and use three patterns to decide: reinstall, replace a part, or get help.

Key Summary: One blue screen and repeated blue screens are two completely different problems. This article shows how to log each crash's date, stop code, and what you were doing, check it against Windows' built-in reliability timeline, and then use three patterns to decide the next step: reinstall, replace a part, or get help — instead of guessing again.

Introduction

When a blue screen first appears, most people want a fix right away. The first-response steps are the right ones: photograph the stop code, check Event Viewer, update or roll back a driver, and run system file checks. Those steps are covered in full in our first blue screen guide, and this article does not repeat them.

But there is a situation the first guide cannot decide for you: you have already done the basic checks, and the machine still blue-screens every so often. At that point, the question is no longer "why did it crash this time?" but "what is the whole pattern telling me?" Looking at only the latest crash, you see a single stop code. Lining up several crashes, you see a pattern: is it the same code every time? Does it only happen when doing one particular thing? Did it start getting frequent only after a certain update or change? The answers to those questions are what decide between reinstalling, replacing hardware, or getting help.

This article covers that second phase: how to keep a blue screen log, how to use Windows' built-in reliability timeline to check it, how to act on three patterns, and what to prepare before getting help, so whoever checks the machine does not have to start from zero.

One clarification about how this article differs from article No. 90: No. 90, "Recurring Blue Screen Fix: WinDbg Dumps & Hardware Isolation", takes the technical deep-dive route — reading dumps with WinDbg, clean-boot isolation, and piece-by-piece hardware isolation to find the root cause. This article takes a timeline-decision route that needs no dump reading at all, using only the log and the reliability timeline to decide the next step. It does not teach hardware isolation and does not repeat No. 90's dump analysis. The two routes serve different readers; pick the one that fits your ability — there is no need to follow both.

1. Why Look at the Pattern, Not Just This One Crash

A single blue screen tells you very little. The stop code tells you what kind of error happened this time, but not whether it is a one-off or a systemic problem. A machine that blue-screens once a month and one that blue-screens four times a week look identical if you only ever deal with one crash at a time — yet their severity is completely different.

Looking at patterns has three practical uses. First, it narrows the suspect list: if the same stop code repeats, the range of causes is much smaller. Second, it reveals timing: if crashes only became frequent after a certain date, whatever changed around that date is the prime suspect. Third, it makes communication possible: hand someone a record with dates, stop codes, and context, and they can start from the most likely direction instead of guessing.

So the first step of this second phase is not to run another repair tool. It is to stop and organise the crashes that have already happened into a record. If you did not keep one, Windows has kept part of it for you — the next section shows how to get it back.

2. Build a Blue Screen Log, Then Check It Against the Reliability Timeline

Six Things to Log for Every Blue Screen

For each blue screen, note these six items. Missing one is fine, but the more complete the log, the clearer the pattern:

1. The date and approximate time.

2. The stop code, and any .sys file name shown on the screen.

3. What you were doing when it crashed: gaming, video rendering, opening a particular program, or nothing at all — the machine idle.

4. Anything unusual just before the crash: the fan suddenly loud, the machine very hot, the screen flickering, or strange noises from the hard drive.

5. Any change made within the previous day: a Windows update, a driver update, a new program, new hardware, or a settings change.

6. Whether the machine got back into Windows afterwards, or needed several attempts.

The method does not matter — a phone note is fine. What matters is using the same format every time, so the pattern can be lined up.

Using Reliability Monitor to See the Timeline

Windows has a built-in tool called Reliability Monitor. Open it by searching the Start menu for "reliability" and choosing "View reliability history", or by typing `perfmon /rel` in the Run dialog. It shows a timeline of the machine's stability, with a stability index line scored from 1 to 10 — the sharper the drop, the denser the problems in that period. The timeline can be viewed by day or by week; the further back you look, the clearer the pattern.

Below the timeline, events are grouped: red crosses are critical events, including application crashes and Windows failures; yellow triangles are warnings, usually failed updates that did not crash the machine; blue circles are informational events, such as successfully installed updates or drivers. The way to read it is simple: click the day where the stability index dropped most sharply, and look at what happened that day and the day before. The combination most worth noticing is an informational event (for example, a driver or update installed successfully) followed a day or two later by red critical events. That sequence is evidence of a timing relationship.

One point to be clear about: Reliability Monitor is not a repair tool. It only lays out what has already happened as a timeline. Its value is turning guessing into checking against time, and all three patterns in the next section depend on that timeline plus your own log.

How Event Viewer and Reliability Monitor Divide the Work

Our first guide covered using Event Viewer to find BugCheck records, and that method is still correct. The division of work is this: Event Viewer is the tool for checking one specific crash — when you need the exact stop code and parameters for a particular blue screen, go there. Reliability Monitor is the tool for seeing the whole picture — when you need the density of crashes over a week or a month, and what changed before they started, go there. Used together, they are both precise and panoramic. Using only one, you will miss something.

3. Three Patterns, Three Decisions

Once the log and the timeline are lined up, most repeated blue screens fall into one of three patterns. Before matching your case, one caution: what follows is a guide to judgement, not a guarantee. The final decision still depends on actual inspection results, and all charges depend on inspection results and are quoted individually — there is no published flat-rate blue screen repair price in Hong Kong, and any quote given before inspection that promises a fixed price should be treated with care.

Pattern 1: The Same Code Repeating Means the Scope Has Already Narrowed

This is the easiest of the three patterns to handle, because the suspect list is already small. Look up the code's official definition in Microsoft's Bug Check Code Reference, then check your log for whether that code started appearing after a particular driver update or device change. If you have already tried rolling back the driver and doing a clean reinstall from the maker's official site, and the code still repeats, the next step is not to try more driver versions. It is to consider whether the device itself is faulty. That judgement point matters: trying more drivers does not equal trying correctly, and past a certain point the work should move to a hardware check instead of circling in driverland.

Pattern 2: Different Codes Every Time — Do Not Chase Them One by One

The common mistake in this pattern is to look up each new code online, follow that code's advice, then look up the next code when it appears. The result is a month spent chasing codes while the machine gets less stable. The reason is that when the underlying hardware is unstable, any program running on top of it can fail in a different place, so each code is different. In this situation, the correct move is to stop chasing codes. Back up important data first, then get a hardware-level check. The longer an unstable system keeps writing data, the greater the risk.

Pattern 3: Only Under Specific Conditions — the Trigger Is the Clue

The key in this pattern is the trigger condition itself. For example, if crashes only happen under heavy load and never during ordinary document work, then cooling, power, and graphics load are the directions to examine. If crashes only happen when opening one program, then that program and the driver it uses are the suspects. The verification method is simple: deliberately avoid the trigger for a while, and if crashes really stop, the trigger is confirmed. If crashes continue even without the trigger, then the trigger is not the only cause, and you should go back to the whole timeline. When noting a trigger, be specific — not just "when gaming", but which game, how long before the crash, and roughly how hot the machine and how loud the fan were. The more specific the note, the faster a checker can find the direction.

4. Four Questions to Ask Before Reinstalling Windows

At some point with repeated blue screens, many people think: why not just reinstall Windows and be done with it? Reinstalling is sometimes right, but often the problem comes back afterwards, and you have also lost the time spent reconfiguring the machine and risked any backup that was incomplete. So before reinstalling, ask these four questions. If any cannot be answered, deal with that one first.

Reinstalling is not wrong. What is wrong is treating it as the first step and the only step. With backup, pattern judgement, and a verification standard all done first, reinstalling becomes a meaningful decision rather than a frustrated one.

5. Four Situations Where You Should Stop Trying Immediately

If any of the following four appears, stop trying things yourself:

1. The machine starts failing to get into Windows, or crashes again very quickly after getting in. Continuing to try things in such an unstable state risks corrupting data being written. Backup first, repair later.

2. Strange hard drive noises, a burning smell, abnormal heat, or automatic shutdowns. These are no longer purely software-level signals. Continuing to power on and try things risks expanding hardware damage.

3. Crashes getting denser in a short period. Rising density is itself a signal of deterioration. Do not wait until the machine will not start at all.

4. You can no longer remember what you have tried or changed. Trying things without a record only makes it harder for whoever checks the machine later. Stopping to organise the log is the responsible move, for yourself and for the checker.

Stopping does not mean giving up. It means handing the next step to someone with the equipment and experience for an in-depth check. The only two things to do before stopping are backup and organising the log — done properly, the check that follows will be much faster.

6. Six Items to Prepare Before Getting Help

If you decide to get help, preparing these six items lets the checker start from the most likely direction immediately, instead of starting from zero by asking and guessing:

On charges, once more: inspection and repair charges depend on inspection results, model, and actual conditions, and are quoted individually. There is no published flat rate. Any claim of a fixed price before inspection, or a promise to fix it in one go, should be treated with care.

7. Four New Mistakes That Only Appear at the Repeated-Crash Stage

The mistakes from the first guide are not repeated here. The following four only appear once blue screens start repeating:

Mistake 1: Trying Something New After Every Crash, With No Control

Change one thing at a time, or you will never know what worked. Change the driver today, change a setting tomorrow, run another tool the day after, and by the end you will not even know what you changed — and the pattern can no longer be separated out. The correct approach is: change one thing, observe for a period, note the result, and only then decide the next step.

Mistake 2: Treating Informational Events on the Reliability Timeline as Faults

Blue-circle informational events mean a successful update or driver install. They are not faults. Deleting or rolling them back because they look like suspects is misreading the timeline. Their purpose is to tell you what changed before the crashes started, not to be cleared one by one as suspects.

Mistake 3: Turning Off Automatic Restart and Thinking No Restart Means No Problem

Some people change the setting so the machine does not restart automatically after a blue screen, thinking this lets them read the screen slowly. Reading the screen is fine, but if the change is then treated as the problem being solved, that is self-deception. Automatic restart is only a behaviour after a blue screen; changing it does not change the cause of the blue screen.

Mistake 4: Deleting Minidump Files and Event Logs to "Clean Up"

Deleting files in C:\Windows\Minidump and event records to save space or "clean up" throws away your own log. The next time it crashes, you have to accumulate evidence from zero again. Records themselves do not slow the machine down. Do not delete diagnostic evidence for the sake of cleaning.

8. How to Know the Machine Is Stable Again

After any decision, there must be a verification period — not a feeling that "it seems fine". A practical verification method is: use the machine normally under the same conditions that used to trigger blue screens, and keep logging. If, during that period, all the conditions that used to cause crashes have been tried and the machine has not crashed at all, only then can it be called stable again. How long the period should be has no fixed standard; it depends on the previous crash density. If crashes used to happen several times a week, then at least several crash-free weeks are persuasive. If they used to happen once a month, the verification period must be longer. The key is to verify under real use, not by leaving the machine idle and claiming that no crash means fixed.

During verification, keep watching the reliability timeline. If the stability index line recovers and no new red critical events appear, that is objective evidence of stability — not a feeling.

Frequently Asked Questions

Q: What is the difference between Reliability Monitor and Event Viewer? Do I need both?

A: They divide the work differently, and using both is best. Event Viewer checks one specific crash's stop code and parameters; Reliability Monitor shows the density of crashes over a week or a month and what changed before they started. Looking only at Event Viewer, you will miss the pattern; looking only at the timeline, you will miss the exact stop code of a particular crash.

Q: If the same stop code keeps repeating, does that mean that driver is definitely faulty?

A: Not necessarily, but the scope has narrowed enough to focus there. The stop code tells you the error class, but the final cause needs the .sys file name, the timeline, and the results of what has already been tried. If rolling back and clean-reinstalling have both been tried without effect, consider a hardware problem with that device rather than trying endlessly in driverland.

Q: If every stop code is different, does that mean the machine cannot be saved?

A: No. Different codes do not mean unsalvageable; they only suggest the problem may be at the underlying hardware level rather than in one driver. In that case, do not chase codes one by one. Back up first, then get a hardware-level check. Stopping the code-chasing approach early reduces the chance of damaging data on an unstable system.

Q: Is reinstalling Windows the most thorough fix for blue screens?

A: No. Reinstalling is only thorough for software-level problems and useless for hardware problems. Before reinstalling, answer the four questions in Section 4: is data backed up, is the pattern clear, is there a record of what has been tried, and how will you verify afterwards? If any cannot be answered, deal with that first. Do not treat reinstalling as the first step.

Q: When getting help, do I need to hand over all of the machine's event records?

A: No, the highlights are enough. The six items in Section 6 — log, timeline observations, what has been tried, hardware and software list, backup status, and trigger conditions — are plenty. When handing over records, watch for personal data: do not casually hand over screens showing private file names or account details. Noting the key dates and events is enough.

Q: After turning off automatic restart, can I read the stop code slowly?

A: Yes, reading the stop code carefully is useful, but changing that setting does not change the cause of the blue screen. After reading the code, still log it, place it in the timeline, and act on the pattern. Do not treat changing the setting as solving the problem.

Q: Do blue screen records disappear on their own?

A: Yes, depending on system settings and disk space, old event records and minidump files can be overwritten or cleaned up. So when there is any suspicion, copy the stop code and date into your own log as soon as possible, and do not rely entirely on the system to remember for you. Your own log is the most reliable record.

Q: How do I know the machine is stable again?

A: Use it normally under the same conditions that used to trigger blue screens, keep logging, and watch the reliability timeline. If all the conditions that used to cause crashes have been tried with no crash at all, and the stability index has not dropped sharply again, only then can it be called stable. Leaving the machine idle with no crash does not prove the problem is fixed.

Summary

1. Look at the pattern, not just this crash: log each blue screen's date, stop code, and context, then check it against the reliability timeline. The pattern is the basis for decisions.

2. Three patterns, three decisions: the same code repeating means focusing on that driver or device; different codes every time means stopping the code chase, backing up, and getting a hardware check; only-under-specific-conditions means noting the trigger and using it to verify.

3. Four questions before reinstalling, six items before getting help: with backup, records, pattern judgement, and verification standards all done, the decision is responsible — not guessing.

Stopping point: if the machine starts failing to get into Windows, if there are strange noises or abnormal heat, if crash density keeps rising, or if you can no longer remember what you have tried, stop immediately on any one of these. Back up first, organise the log, and hand it to someone experienced for an in-depth check.

Sources

1. Microsoft Learn — Bug Check Code Reference — https://learn.microsoft.com/th-th/windows-hardware/drivers/debugger/bug-check-code-reference2 — Used to check the official definitions of repeatedly appearing stop codes. Accessed: 2026-10-26.

2. Microsoft Support — Troubleshooting Windows unexpected restarts and stop code errors — https://support.microsoft.com/en-US/Windows/Experience/Performance-Optimization/troubleshooting-windows-unexpected-restarts-and-stop-code-errors — Source of the first-response steps, already used in the first guide; cross-referenced here, not repeated. First verified: 2026-10-21.

3. How-To Geek — Reliability Monitor explainer — https://www.howtogeek.com/there-is-a-hidden-windows-diagnostic-tool-that-has-been-there-since-vista-and-almost-nobody-uses-it/ — Explains the Reliability Monitor interface (by-day/by-week timeline, 1-to-10 stability index, critical/warning/informational event categories, opening via searching "reliability" or perfmon /rel). Used as a secondary explainer; judgements still rest on the log and timeline themselves. Accessed: 2026-10-26.

4. ComputerKing first blue screen guide — /blog/windows-bsod-deep — Full first-response steps (photographing the stop code, Event Viewer BugCheck records, driver-versus-hardware distinctions, tiered self-help steps). Cross-referenced here, not repeated.

5. ComputerKing backup strategy article — /blog/backup-strategy-hk — Backup reminder before reinstalling; methods are detailed there.

6. ComputerKing article No. 90, recurring blue screen root-cause guide — /blog/windows-bsod-recurring-root-cause — Division of labour (that article takes the WinDbg dump-reading and hardware-isolation route; this article takes the timeline-decision route, without repeating it).

Related Articles

• Windows Blue Screen Troubleshooting: Reading Common Stop Codes and Self-Help Steps
• Recurring Blue Screen Fix: WinDbg Dumps & Hardware Isolation
• Hong Kong User Backup Strategy: How to Do the 3-2-1 Backup Rule Properly