Computer Repair · October 23, 2026 · ComputerKing Team

Recurring Blue Screen Fix: WinDbg Dumps & Hardware Isolation

A recurring blue screen is not bad luck, but a root cause not yet found: preserve evidence, read the dump, isolate software and hardware, and choose the repair path, layer by layer, until the real culprit is locked down.

Recurring Blue Screen Fix: WinDbg Dumps & Hardware Isolation

Summary

A recurring blue screen is not bad luck, but a root cause not yet found: preserve evidence, read the dump, isolate software and hardware, and choose the repair path, layer by layer, until the real culprit is locked down.

---

Brief recap: what the earlier guide already covered, not repeated here

Our earlier guide, Windows Blue Screen (BSOD) Troubleshooting: Decoding Stop Codes and Safe Recovery Steps, already covered blue screen basics, stop-code decoding, Event Viewer and minidump fundamentals, and tiered self-recovery steps. This article does not repeat that material. It focuses only on rooting out a recurring blue screen: preserving evidence, deep WinDbg analysis, clean-boot isolation, safe Driver Verifier use, driver rollback and DDU, update rollback and safeguard holds, piece-by-piece hardware isolation, temperature and power-supply logs, and how to choose between a repair install and a clean reinstall.

---

1. A recurring blue screen is not the same as an occasional one

Microsoft's official position is clear: most occasional Windows 11 restarts are "resolved by the restart itself, with no further action needed"; but if a machine "restarts frequently because of the same stop code error," the basic troubleshooting steps should be followed. So the first step is not an immediate reinstall, but triage:

SymptomInitial readingNext step
Happens only once, then everything is normalAn occasional event; observe firstRecord the date, stop code, and what you were doing; do not start major repairs right away
The same stop code keeps coming backThere is a fixed clue to followFollow the official basic flow: remove newly added hardware, boot into Safe Mode, check Device Manager, check system drive space, update, restore
A different code every time, at random timesPoints to whole-machine instabilityDo not chase the latest code and swap parts; move to the hardware-isolation path: RAM, power supply, cooling, motherboard path
Blue screen right at boot, cannot reach the desktopA boot-layer or update-layer problemGo the WinRE route: first try uninstalling the latest quality update; if that fails, try System Restore
Blue screen only on a specific action (for example, opening one game, or plugging in one device)There is a clear trigger conditionIsolate that trigger condition first; do not swap parts across the whole machine

Example scenario (purely an illustrative scenario, not a real person or real case): suppose a machine blue-screens two or three times a week, with a different code each time, sometimes while gaming and sometimes while idle. That pattern of scattered codes plus random timing is itself a signal, pointing to a deeper problem with RAM, power, or cooling, not to "no clue at all." By contrast, if every crash shows the same code and the same `.sys` file, the clue is much more concentrated and worth following down the driver path.

2. Step one: preserve evidence; do not reinstall before investigating

The most common mistake with a recurring blue screen is reinstalling before recording anything, which destroys the evidence for judgment in one stroke. If the hardware itself is faulty, the blue screen will come back after a reinstall anyway. During an investigation, hold on to three things:

1. Make sure dump collection is turned on. Path: Control Panel > System > Advanced system settings > Startup and Recovery settings. Under "Write debugging information" you can choose a small memory dump (minidump, stored in `%SystemRoot%\Minidump`) or an automatic, kernel, or complete dump; the boot drive needs at least a 2 MB paging file for a dump to be written. For everyday use, an "automatic memory dump" or "small dump" is enough to keep records of repeated blue screens; only switch to a "kernel dump" during a recurring-blue-screen investigation, because a complete dump can be very large.

2. Keep the minidumps; do not clean them away. During a blue screen investigation, `C:\Windows\Minidump\` is the evidence. Never use a cleanup tool to delete these files; deleting them is the same as destroying diagnostic data.

3. Collect at least 3-5 dumps before drawing a conclusion. Do not convict on a single dump; check whether IMAGE_NAME and the call stack are consistent. Consistency is what makes root-cause work worthwhile; if every crash differs, the cause is more likely a deeper problem or symbols not yet loaded. For every blue screen, record: date and time, the full stop code, what you were doing (gaming, opening a program, plugging in USB, restarting after an update), and whether anything changed in the 7 days before the crash: Windows Update KB number, driver version, newly added hardware, BIOS settings (for example XMP or overclocking).

WARNING: Reinstalling without a backup, and without recording the code and timing, is the most expensive shortcut. A reinstall wipes dumps and timelines, so the next blue screen forces the investigation to start from zero again; and a reinstall cannot fix bad RAM, a bad SSD, an insufficient power supply, or overheating.

3. Deep WinDbg analysis: from "seeing a name" to "seeing a clue about the cause"

WinDbg is the tool for analyzing blue screen dumps. It is installed through Debugging Tools for Windows inside the Windows SDK, or as the newer WinDbg. Dump paths are generally `C:\Windows\Minidump\` (minidumps, usually under 1 MB) or `C:\Windows\MEMORY.DMP` (a complete dump, which can reach several GB).

Before opening a dump, you must set the symbol path, or you will only see addresses and no function names. The commonly used Microsoft public symbol server is: `srv*C:\Symbols*https://msdl.microsoft.com/download/symbols`, followed by `.reload`. In the WinDbg command line, use `.sympath` with the symbol path above, then `.reload`; or paste the same string into the symbol path settings field.

WARNING: Do not draw conclusions before symbols have loaded. An analysis result that shows only addresses and no function names is unreliable; set the symbol path and run `.reload` first, or you may easily blame an innocent driver.

The first command is always `!analyze -v`: Microsoft describes `!analyze` as the first step in debugging any crashed computer or program, and `-v` means verbose. Its output includes Bugcheck Analysis, BUGCHECK_CODE, four parameters, FAULTING_IP, STACK_TEXT, MODULE_NAME, IMAGE_NAME, and FAILURE_BUCKET_ID. Read it in the following order; do not just copy a driver name:

FieldHow to read itCommon mistake
BUGCHECK_CODE / BUGCHECK_STRFirst, learn which class of blue screen it is (for example 0xD1, 0x7E, 0x3B, 0xA, 0x124), but the code only says "what kind of event," not the root causeTreating the code as proof of hardware failure
Probably caused byOnly the "most likely" clue, not an absolute verdict; sometimes the named driver is the real culprit, sometimes it is only where the corruption surfacedAssuming whoever is named is the culprit
MODULE_NAME / IMAGE_NAMEThe file actually at fault (for example a `.sys` file); check its version, date, and publisher with `lmv` before judging whether it is an old driverReading only the file name without checking the version
STACK_TEXTThe sequence of function calls before the crash; if several consecutive blue screens point to the same driver or the same call chain, that has root-cause valueTreating each different stack as an unrelated event
FAULTING_IPThe faulting instruction location; ordinary users do not need to dig into it, but should know it exists, and should not treat an address as evidenceTreating an address as evidence

If you only want a quick look at the stop code and its four parameters, use `.bugcheck`; there is no need to run the full verbose output every time. Other useful commands can be listed as advanced reference: `lm` / `lmv` list loaded modules or module details to check driver versions; `kb` shows the call stack; `.exr`, `.cxr`, `.ecxr` show exception or context records.

The frequent appearance of ntoskrnl.exe does not mean the Windows kernel itself is broken. The kernel is only "the place standing there at the moment of the crash"; the real trigger is usually a driver or hardware. IMAGE_NAME, the stack, and cross-checking across multiple dumps are needed before drawing a conclusion. Saying "reinstall" the moment ntoskrnl appears is one of the most common misjudgments.

Special case 0x124: `!whea` and `!errrec`

0x124 WHEA_UNCORRECTABLE_ERROR means a fatal hardware error has occurred. Parameter 1 describes the error source type, and parameter 2 is the address of the `nt!_WHEA_ERROR_RECORD` structure. Two dedicated commands: `!whea` shows top-level WHEA information; `!errrec <parameter 2 address>` dumps the specified error record. The `!errrec` output is divided into sections listing Severity (for example Fatal), Notify Type (for example Machine Check Exception), Processor Generic, x86/x64 Processor Specific, and x86/x64 MCA; the MCA section states the error type (for example DCACHEL2_PREFETCH_ERR) and processor or bank information.

Note, though: 0x124 mostly points to hardware, but do not treat it as "100% hardware." The point is to "first read the `!errrec` sections, then triage together with temperature, overclocking, power supply, and RAM tests." Do not tell people to replace the motherboard or CPU the moment they see 0x124.

4. Clean-boot isolation: finding a third-party culprit by halving

A clean boot means starting up using only necessary Microsoft system files and basic drivers, temporarily switching off third-party startup programs and background services, to judge whether the problem is caused by a third-party software conflict. It is not the same as Safe Mode: Safe Mode loads the minimum drivers, while a clean boot keeps the normal Windows environment and only removes third-party items.

Microsoft's official steps are as follows:

1. Log in as an administrator and run `msconfig` to open System Configuration.

2. On the "Services" tab, check "Hide all Microsoft services" (this step matters most; without it you may switch off system services by mistake), then "Disable all."

3. On the "Startup" tab, open Task Manager and disable third-party startup items one by one.

4. Confirm and restart; the machine is now in a clean-boot state.

WARNING: Do not switch off Microsoft services by mistake. On the msconfig Services tab, you must first check "Hide all Microsoft services" before clicking "Disable all," or you will disable services the system needs.

The reading logic is the key point of this section:

Result after a clean bootMeaningNext step
The blue screen disappearsThe culprit is among the disabled third-party services or startup itemsUse the "halve and re-enable" method: re-enable half at a time; whichever half brings the blue screen back gets halved again, until a single item is locked down
The blue screen still happens on a clean bootThe culprit is more likely Windows itself, a driver, or hardwareStop circling around startup items and move to WinDbg, Driver Verifier, or hardware tests

Halving takes time: after re-enabling each half, restart and observe for long enough (an intermittent blue screen does not show up immediately); do not re-enable everything at once and call the halving done.

Remember the division of labor between Safe Mode and clean boot: if Safe Mode is stable but normal mode blue-screens, the problem leans toward third-party drivers or software; if a clean boot still blue-screens, it leans toward Windows itself or hardware. This reading method is derived from the logic of the sources above and is presented as a reading method, not as verbatim Microsoft text.

After diagnosis, you must restore: re-enable the disabled services and startup items one by one. Do not use a clean boot as a daily startup mode. A clean boot does not delete files, programs, or settings; it only temporarily changes the startup list. If you never restore, antivirus, backup, and cloud sync services will stay disabled long-term, which is a different kind of risk.

5. Driver Verifier: the most useful tool, and also the most dangerous

Driver Verifier monitors Windows kernel-mode drivers and graphics drivers, detecting illegal calls or behavior that could damage the system. It applies extra checks and stress tests to selected drivers, forcing hidden problems to surface early as a blue screen, so that the dump contains enough information to identify the faulty driver.

DANGER WARNING: Using Driver Verifier incorrectly can cause a boot loop. Do not try it casually on a production machine. Before turning it on, you must create a restore point or disk image and know the `verifier /reset` escape method in advance. Do not turn it on casually on a production machine, your only work machine, or a machine with no backup. Once the problem is found, you must switch it off again. Verifier does not switch itself off after a blue screen; if it is set to verify at boot and the faulty driver is required for booting, every boot will blue-screen. There are cases where even Safe Mode could not be entered, and the machine could only be freed through the WinRE command line or offline registry handling.

The official operating points are as follows, without oversimplifying them into distortion:

  • Turn on: run `verifier` to open Driver Verifier Manager, or from the command line use `verifier /standard /driver <driver name>.sys`.
  • Stop or reset: in Driver Verifier Manager choose "Delete existing settings" and then Finish, or from the command line use `verifier /reset`, then restart.
  • Check current status: `verifier /query` (drivers currently being verified), `verifier /querysettings` (current settings).

The safe-use checklist is not complete if any item is missing:

1. Create a restore point or disk image before turning it on. This step cannot be skipped.

2. Target only the suspect. The usual practice is to select non-Microsoft drivers or a single suspect driver. Do not select all drivers at once; selecting everything makes the problem harder to locate and makes it easier to get stuck.

3. Do not turn it on casually on a production machine, your only work machine, or a machine with no backup. Microsoft's documentation positions it as a testing and debugging tool, and community guidance generally warns against turning it on on a daily main machine.

4. Prepare an escape route in advance. Know how to enter Safe Mode and run `verifier /reset`. If Safe Mode cannot be entered, use Windows installation media to enter WinRE, then run `verifier /reset` at the command prompt, or restore from a restore point made beforehand.

5. Switch it off once the problem is found. After fixing the problem, use `verifier /reset` to switch it off. Do not leave it on long-term; leaving it on is the same as running the machine permanently in stress mode.

Two points to add: run Verifier as an administrator, and restart after applying the settings for them to take effect (the list above mentions a restart after a reset; the turn-on side needs one too).

How to read a Verifier blue screen: the blue screen itself is Verifier's "work product." The stop code is usually DRIVER_VERIFIER_DETECTED_VIOLATION and names a `.sys` file. Keep every minidump produced while Verifier is on; do not delete them, or the work is wasted.

Note the limitation: Verifier only tests driver software itself, not hardware. Bad hardware (for example RAM or power supply) may not cause a Verifier blue screen, so a clean Verifier result does not mean the hardware is fine.

6. Driver fixes: roll back first; use DDU only if rollback fails

Driver rollback has two hard limits

Method: Device Manager > right-click the device > Properties > Driver tab > "Roll Back Driver," choose a reason, confirm, restart. But two hard limits apply:

1. Windows only keeps the "previous version," not a whole library of old versions; you cannot pick an even older version step by step.

2. A greyed-out button (unusable) means there is no previous version to roll back to. Possible reasons: the driver was never updated, the old backup was deleted, or only one version was ever installed for that device. Printer drivers do not support the rollback feature.

After a rollback, guard against Windows Update immediately reinstalling the new version: combine the rollback with pausing updates to buy observation time, or the "fix" may only mean the new version has not been reinstalled yet. This point is presented as practical advice, not as a guarantee in Microsoft's original text.

DDU clean reinstall of display drivers

DDU, short for Display Driver Uninstaller, is a third-party tool, not a built-in Microsoft feature. Intel's official support documentation also teaches using DDU to uninstall Intel display drivers, with steps: download the latest DDU > restart into Safe Mode > run DDU > choose device type GPU and brand > click "Clean and restart" or "Clean and Shutdown". In short, DDU is "a third-party tool, whose method is also cited in Intel and MSI official support documentation." Do not treat it as a Microsoft official tool.

The widely agreed operating order is as follows:

1. Download everything first. Before going offline, download DDU and the replacement driver (from the NVIDIA, AMD, or Intel official site, not a third-party download site).

2. Create a restore point first. DDU itself has safeguards, but a restore point gives one more way back. Also note down the BitLocker recovery key and account password (a Windows Hello PIN may not work in Safe Mode).

3. Go offline. The MSI official FAQ explicitly requires downloading first and then working offline, so Windows Update cannot slip another driver in between removal and reinstall.

4. Run DDU in Safe Mode. Choose GPU, choose the correct brand, then "Clean and restart." After it finishes, Device Manager should show "Microsoft Basic Display Adapter," meaning the old driver has been cleared; a low-resolution display is normal.

5. Install the new driver in normal mode. Use the driver downloaded beforehand. Do not immediately install a pile of overclocking or overlay tools to test at the same time.

State the risks: DDU removes all driver files and settings for that brand. Clearing the wrong brand, or clearing integrated and discrete graphics in the wrong order, creates extra work. For dual-graphics laptops (Intel integrated plus NVIDIA or AMD discrete), some guides recommend clearing the discrete graphics first, restarting into Safe Mode, then clearing the integrated graphics. DDU is not a cure-all: if the crash is caused by hardware itself (for example a loose power connector or failed graphics card cooling), deleting drivers cannot fix a hardware fault. Download DDU only from the Wagnardsoft official site or Guru3D, and watch out for download-page ads disguised as download buttons.

7. Update rollback and safeguard holds: uninstalling only buys time

If you can get into Windows: how to uninstall

Settings > Windows Update > Update history > Uninstall updates; choose the update and uninstall it. Not every update can be uninstalled; some updates do not appear in the list. Command-line uninstall for a specific KB: `wusa /uninstall /kb:XXXXXXX`. Note, however, that for combined packages such as the January 2026 cumulative update, Microsoft states wusa may not apply, and DISM /Remove-Package is the supported route. For DISM, first run `dism /online /get-packages` to find the PackageName; do not pass the KB number directly as the PackageName.

If you cannot get into Windows: the WinRE uninstall route

Enter WinRE by forcing a shutdown three times in a row during boot (or by choosing "Repair your computer" from installation USB), then Troubleshoot > Advanced options > Uninstall Updates > choose "Uninstall latest quality update" or "Uninstall latest feature update". State the limit: WinRE only uninstalls the "latest" quality or feature update. If the problem started several updates ago, use System Restore instead. For an encrypted drive, WinRE tools may ask for the BitLocker recovery key; find it beforehand.

Pausing updates is not permanently switching updates off

Settings > Windows Update > Pause updates lets you choose a date within 35 days. When it expires, updates resume automatically; it is not a permanent switch-off of automatic updates. Newer controls allow extending by another 35 days before expiry, which is a renewable hold, not an off switch. Do not recommend these practices: stopping the Windows Update service, force-killing the installer in Task Manager, or deleting the SoftwareDistribution folder to cancel an update. Windows can restart the service on its own, and the latter two can leave an update half-installed.

Safeguard holds: Microsoft's block, do not force your way around it

A safeguard hold is a Microsoft official mechanism, not to be confused with a user clicking "Pause." When Microsoft's quality and compatibility data show that a feature update may fail, roll back, lose data, disconnect networking, or lose a critical feature, Microsoft places a safeguard hold on affected devices so Windows Update does not offer that new version; the hold is lifted only when a verified fix exists. A hold only affects devices receiving updates through Windows Update. Using ISO, the installation assistant, WSUS, or other routes to bypass a hold risks installing a version already known to cause problems.

Important reminder: uninstalling plus pausing only buys time; it is not a long-term solution. Update support for 24H2 Home and Pro editions ended on October 13, 2026. Staying un-updated long-term leaves a machine permanently behind, and the path forward is upgrading to 25H2. Enterprise supplement: Intune administrators can pause only one approved version (Autopatch per-update pause) without pausing the whole quality update; but machines that already installed it will not automatically roll back, and still need a KB uninstall, a workaround deployment, or a restore.

8. Piece-by-piece hardware isolation: change only one thing at a time

The core principle: change only one thing at a time, and after each change test for long enough (at least several times the usual blue-screen interval), or intermittent faults will easily be misjudged.

StepMethodHow to read the result
Step 0: Restore BIOS defaultsSwitch off EXPO / XMP (run at JEDEC default speed), switch off CPU / GPU overclocking or undervolting, switch off PBO and other automatic tuningThere are cases where 4 RAM sticks plus high-frequency EXPO were themselves the instability cause; do not start by assuming one particular stick is bad
Step 1: Remove non-essential devicesKeep only keyboard and mouse; unplug external drives, printers, USB dongles, memory cards. If hardware was newly added before the blue screens, remove it first (consistent with Microsoft's official first step)If it becomes stable after removal, plug items back one by one to find the culprit
Step 2: Test RAM one stick at a timeKeep only one stick at a time, in the slot recommended by the motherboard manual (commonly A2, the second slot counting from the CPU), and rotate through each stickOne stick always fails and another always passes: points to the failing stick. Each stick passes alone but they fail together: points to the memory subsystem (settings, slot, CPU memory controller), not a single bad stick. Both sticks fail alone: do not immediately judge all RAM bad; widen the investigation
Step 3: MemTest86See Section 9; default 4-pass flow; any reproducible error needs following upAn error that follows the stick: the stick is faulty. An error that stays in the same slot: the slot or motherboard direction
Step 4: Remove the discrete GPU and use integrated graphicsActually remove the card. Do not just move the cable from the discrete card to the motherboard (a card left in the slot still brings driver, PCIe, and power-load variables). After removing the card, connect the cable to the motherboard integrated output and test idle plus light useIf blue screens stop, that only proves a problem with the "discrete graphics configuration," not that the card itself is bad (driver, PCIe connection, extra power load are still possible). Trap: a CPU with no integrated graphics (for example a non-G Ryzen series) will show no picture after the card is removed; that does not mean the motherboard is bad
Step 5: Minimum systemCPU plus cooling, one RAM stick, integrated graphics, power supply; remove other drives and expansion cards, and see whether the machine can stay in BIOS for a long time. On a CPU with no integrated graphics (for example a non-G Ryzen series, or an Intel F series), keep the discrete graphics card in the minimum system instead of following the integrated-graphics versionIf problems occur even in BIOS, it is very likely not a Windows driver problem
Step 6: Power supply cross-testSwap in a known-good power supply for a cross-test; this is more decisive than reading voltage logs. When swapping a power supply, use its own original modular cables; do not mix old cables, because modular cable pinouts can differ between makers and models and mixing them can damage hardwareStable after the swap points to the original power supply; unchanged after the swap rules the power supply line out
Step 7: Rule out the current Windows with another systemA Live Linux USB (without installing) or a clean Windows install on a spare driveProblems that still occur outside the current Windows point toward hardware or firmware; but short-term stability proves little (intermittent faults)

9. Reading hardware stress tests: telling CPU, GPU, and power supply apart

MemTest86: how many passes count as a pass? State the disagreement honestly

Important note: this research did not directly obtain a PassMark official document stating a pass count. The pass recommendations below all come from third-party tutorials or community consensus, and never treat it as a "PassMark official requirement." The mainstream consensus: at least 2 complete passes; for a serious check of intermittent faults, run 4 passes or overnight. One pass is only a quick confidence check: it catches hard faults, but may not catch edge faults that only appear once the machine is warm. The older MemTest86+ community practice differs: some tutorials recommend 7-8 passes. Do not mix that up with PassMark MemTest86's 2-4 passes; they are different branches with different default test counts.

A PassMark official execution-time page cited in the other research report describes a default 4-pass flow and timing examples: the first pass is quicker, with examples of about 15 minutes for 1 pass and about 120 minutes for 4 passes (the official example gives no capacity), and a large capacity plus a slow CPU can run overnight. But "how many passes count as passing" itself remains third-party tutorial consensus; do not upgrade that consensus into an official rule.

The capacity timetable below is a third-party tutorial approximation, measured on a different basis from the official example above, so the two cannot be compared directly (the larger the capacity, the longer it takes): 8 GB about 20-35 minutes per pass, 16 GB about 40-70 minutes, 32 GB about 1.5-2.5 hours, 64 GB about 3-5 hours, 128 GB about 6-10 hours. Actual time depends on CPU, channels, frequency, and firmware.

Iron rules for reading results:

  • Any reproducible error needs following up. Do not dismiss it because there is "only one red line".
  • A red line does not mean 100% that the stick is bad: the memory controller, motherboard slot, firmware settings, temperature, or an unstable overclock or XMP setting can all make the same address fail. Use the "swap sticks across slots and retest" triage: an error that follows the stick points to the stick; an error that stays in the same slot points to the slot or motherboard direction.
  • Zero errors are not a 100% guarantee: intermittent errors that appear only under temperature, voltage fluctuation, or extreme load may still escape MemTest86.
  • MemTest86 runs outside Windows, booted from USB, so it can test almost all RAM (the tool itself and reserved areas are not testable). The built-in Windows memory diagnostic (`mdsched`) is shallower; there are cases where the built-in tool passed but MemTest86 failed within one pass. Do not treat a built-in tool pass as a conclusion.
  • Before testing, confirm that the total capacity shown by MemTest86 matches the actually installed capacity (for example, if 2 sticks of 16 GB only show 16 GB, stop and check the modules first; do not just run it).

Prime95 and FurMark: telling CPU, GPU, and power supply apart

Prime95 is a CPU stress test: it uses prime-number computation to continuously stress the CPU and compares results against known correct results; any mismatch counts as a hardware error. If a worker errors during testing, it mostly points to CPU stability, memory, or power supply. Common failure causes: memory unstable at its rated speed (especially after XMP is turned on), insufficient cooling, power supply unable to deliver under heavy load (clear drops in 12V, 5V, or 3.3V), overclock voltage too low, or excessive droop. Newer Prime95 using AVX or AVX2 stresses particularly hard, and sometimes even an otherwise stable system will fail; do not condemn a system on a single AVX failure. To tell CPU from memory, use Small FFTs for a mainly CPU load and Blend when memory is also under load; otherwise the test you ran does not match the CPU-versus-memory conclusion.

FurMark is a GPU stress test: look for visual artifacts, crashes, blue screens, and high temperatures. Artifacts mostly point to an unstable GPU or VRAM or overheating; a system that directly restarts or shuts down under heavy load mostly points to a power supply problem.

WARNING: Stress tests need a person watching; do not run them overnight unattended. Running Prime95 plus FurMark together under heavy load pushes temperature and power supply to their limits, and aging hardware or poor cooling carries risk. Clean dust and confirm cooling is normal before running, and watch the machine while it runs. Safety-limit reference (third-party tutorial consensus, not official specifications): stop if the CPU goes above about 95 degrees C or the GPU above about 90 degrees C; stop if fans run at 100% for more than 15 minutes, or if throttling, a crash, or a blue screen appears. A combined test is generally recommended to be capped at 30-60 minutes; do not run it for a long time unattended. Overnight runs apply to MemTest86 only, not to Prime95 plus FurMark.

Power-supply instability signs deserve their own paragraph, not just "try swapping the power supply":

  • Blue screens or restarts only when CPU plus GPU are under heavy load together (for example gaming, rendering, or Prime95 plus FurMark at the same time), while light loads are completely normal.
  • No blue screen and no dump: a direct black-screen restart or power-cut-style shutdown (different from an ordinary driver blue screen; the dump may record nothing at all).
  • Prime95 workers failing randomly, and voltage monitoring showing clear drops under heavy load.

Reading temperature and power-supply logs: do not look at a single number

Reference ranges (third-party guides; stated as general reference, not official limits from CPU or GPU makers for each model): desktop CPU idle about 35-50 degrees C, heavy load 70-85 degrees C is common. Some high-end processors are designed to boost up to a 95-degree C thermal limit before pulling back, so seeing 95 degrees C does not necessarily mean a fault. GPU edge temperature under gaming load 60-85 degrees C is common; GPU hotspot or junction is usually 15-25 degrees C higher than edge temperature, and only sustained readings above 90 degrees C are worth investigating for cooling.

How to read HWiNFO: in the Sensors window, look for "Thermal Throttling," "PROCHOT," or "Core Thermal Throttling" changing from No to Yes; only then is it true heat throttling. Check at the same time whether clock frequency drops together. GPUs have a similar performance-cap reason field. Power-supply voltage reference (the general ATX plus-or-minus 5% rule, a forum compilation; cite it as such, not as an official standards document): 12V should be 11.4-12.6V, 5V should be 4.75-5.25V, 3.3V should be 3.135-3.465V.

State the limits clearly: HWiNFO voltage readings cannot catch every brief electrical disturbance or internal power-supply fault, and changing wall sockets does not rule out the power supply itself. Kernel-Power 41 only means Windows found on next boot that the previous shutdown was abnormal; it does not diagnose a faulty power supply unit. You must also look at BugcheckCode and whether there is a dump. Practical logging method: turn on HWiNFO logging, record every blue-screen time, and match it against temperature, voltage, and throttling fields in the log before the blue screen. Without a log, replacing cooling based only on "it seems hot" is guessing.

10. System-level notes: 25H2, 2026 update cases, and Secure Boot certificates

Windows 11 25H2: check the timeline first; do not blame the version itself first

What 25H2 is: a lightweight enablement package released September 30, 2025, built on 24H2, sharing core code and monthly updates with 24H2. Support extends to October 2027 (24H2 support ends October 13, 2026). Confirmed or mitigated early issues (around October 2025): playback problems for DRM-protected content in some Blu-ray, DVD, and digital TV programs (partly mitigated in the September 29, 2025 preview update KB5065789; streaming services were unaffected); installing updates from a network shared folder containing multiple `.msu` files through WUSA could fail (`ERROR_BAD_PATHNAME`), mitigated through Known Issue Rollback or by copying files locally first; SMBv1-related issues (KB5065789 addressed some cases; best practice remains disabling SMBv1).

WinRE input failure is an important lesson from the October 2025 updates, because it affects the repair itself: after the October 14, 2025 security update or SafeOS update KB5067039, USB keyboards and mice could become unresponsive in WinRE. Microsoft confirmed this in 25H2 Release Health known issues on October 17, 2025, and later fixed it with out-of-band updates KB5070773 and KB5070762. Practical meaning: before entering WinRE to repair a recurring blue screen, first confirm the system has the latest fix updates installed; otherwise you may enter WinRE and find you cannot press anything, and mistakenly think the hardware is broken.

Upgrade-process blue screens need their source level kept clear: when upgrading from Windows 10 or an older Windows 11 to 24H2 or 25H2, the install stage could blue-screen and abort the upgrade. Common causes include outdated or incompatible drivers, old USB Wi-Fi dongles, and Sentinel Protection Installer present on the system. That vendor's approach was to uninstall Sentinel Protection Installer first, restart, then upgrade. Treat this as an Avid lab observation, not applicable to every machine, and never as a Microsoft official conclusion.

2026 update cases: official acknowledgment versus third-party reporting, kept separate

CaseLevel of official acknowledgmentPhenomenonCorrect wording
January 2026 KB5074109 (January 13; 25H2 Build 26200.7623, 24H2 Build 26100.7623)Microsoft confirmed, with a limited scope: a limited number of devices, with early reports saying mainly commercial (not home) computers; Microsoft took steps so the problem would not affect general consumersBoot failure, stop code UNMOUNTABLE_BOOT_VOLUMEDo not write "the January 2026 update blue-screened or bricked all Windows 11 computers." The cause was later attributed to a December 2025 update rollback failure leaving devices in an "improper state," triggered by the January update. That "December rollback failure chain" is a third-party analysis account; treat it as such. Official recovery direction: recover through existing WinRE methods; in severe cases, clean-reinstall Windows 11 from ISO. Later fixes included KB5078127 (emergency out-of-band update) and KB5077181 on February 10, 2026
June 2026 KB5094126 (25H2 Build 26200.8655, 24H2 Build 26100.8655)Must be written separately: a Windows Latest article on June 21, 2026 said Microsoft confirmed some KB5094126 issues, but at the same time wrote that "Microsoft has not yet acknowledged the (BSOD / BitLocker loop) part we found". Another retrospective described June as "over 150 reports within 48 hours," a third-party statistic, not a Microsoft official figureSome devices showed a black-screen boot error 0xc0430001 or fell into a BitLocker recovery loop, with reports concentrated on HP commercial machines (EliteBook 840 G10, ProBook 460 G11, Engage One Pro 15.6 G2 AiO POS, ZBook, and others) and some Dell Precision machinesThird-party analysis of a possible mechanism (do not write as a proven root cause): the update touched Secure Boot certificates, Boot Manager, and EFI content; an old-style 100MB EFI partition (versus newer 500MB-1GB) may run out of space, or HP firmware recovery files stored in the EFI partition may tighten space further, causing Secure Boot to refuse loading and producing a black screen or BitLocker loop. Event Viewer may show TPM-WMI "secure boot update failed...insufficient disk space" type errors. Third-party workaround (not a Microsoft official prescription; label it as such): enter BIOS, temporarily switch Secure Boot off, enter Windows to complete the update, then switch Secure Boot back on; prepare the BitLocker recovery key beforehand
March 2026 KB5079473Unconfirmed; do not treat as fact: there are reports that some users saw blue screens, freezes, and reboot loops, with stop code ATTEMPTED_WRITE_TO_READONLY_MEMORY (0xBE), while the report itself also states that "Microsoft has not yet acknowledged this issue"Blue screens, freezes, reboot loopsOnly write "there are reports or community reports, not acknowledged by Microsoft." Never write it as a "Microsoft known issue" or "KB5079473 will definitely blue-screen"

Other 2026 update regressions, mentioned only as background that "there were other update incidents in the same year," not to be mixed up with blue screens: in March 2026, according to a third-party review, KB5079473 broke Microsoft account sign-in and was fixed 11 days later by out-of-band update KB5085516; the KB5079391 preview was pulled because of an install error loop; in April 2026, KB5083769 could trigger BitLocker recovery, but Windows Latest verification said it was not the blue-screen cause rumored; in May 2026, KB5089549 failed to install when the EFI system partition had 10MB or less remaining, with error 0x800f0922, later emergency-patched; in July 2026, Microsoft blocked KB5101650 on Dell machines because of an Intel driver conflict causing unexpected shutdowns, overheating, and power drain. New October 2026 development (background, not a blue screen): Microsoft acknowledged that an October Patch Tuesday update meant to fix Always On VPN did not actually fix it, with status changed back from Resolved to Mitigated. This reminds readers that "official status can change"; check the current release health page, not just an old screenshot.

How to think about 25H2: do not blame 25H2 itself first for a recurring blue screen. Check the timeline first. Did the blue screens start only after a particular update? Is there a safeguard hold? Was there a backup before uninstalling that update to test? At the same time, check the current Release Health status; do not convict on a single KB number.

2026 Secure Boot certificate expiry: expiry does not mean the machine cannot boot right away

Expiry timetable (official sources and third-party cross-checks agree):

Old certificateExpiry date2023 replacement certificatePurpose / storage location
Microsoft Corporation KEK CA 2011June 24, 2026Microsoft Corporation KEK 2K CA 2023Signs DB / DBX updates, stored in KEK
Microsoft UEFI CA 2011June 27, 2026Microsoft UEFI CA 2023, Microsoft Option ROM UEFI CA 2023Signs third-party boot programs / EFI programs / option ROMs, stored in DB
Microsoft Windows Production PCA 2011October 19, 2026Windows UEFI CA 2023Signs Windows Boot Manager, stored in DB

As of October 23, 2026, all three deadlines have passed. The most important clarification, without creating panic, is this: expiry does not mean the machine immediately cannot boot. Secure Boot generally does not enforce certificate expiry dates at boot time; a registered 2011 certificate can still boot a device even after expiry. The real effect is a "freeze": devices that have not moved to the 2023 certificates will no longer receive new Secure Boot database updates, DBX revocation lists, or Windows Boot Manager protection updates. In other words, the boot chain's security basis stays frozen at the expiry moment, and future boot-chain vulnerability fixes will not arrive.

Practical meaning for recurring blue screens or repairs: do not casually switch Secure Boot off or clear DB or KEK before a repair. Clearing the wrong entries breaks the boot trust chain, turning a blue screen problem into a machine that cannot boot at all. Most devices receive 2023 certificates automatically through Windows Update; those that do not catch up are mostly old firmware, devices with Secure Boot itself switched off, unsupported Windows versions, or devices with BitLocker conflicts. Before a firmware update, repair install, or reinstall, first confirm whether the device has 2023 certificates, check the Secure Boot status, and confirm the BitLocker recovery key is backed up. Only proceed with the boot layer when all three are ready.

WARNING: Do not casually clear the Secure Boot DB or KEK, and do not casually switch Secure Boot off. Clearing the trust chain by mistake leaves the blue screen unsolved and may leave the machine unable to boot at all. Handle 2023 certificate issues by following official guidance; do not delete entries by hand.

11. Before any hands-on repair: prepare the BitLocker recovery key

A BitLocker recovery key is a 48-digit numeric password. When the boot environment changes (for example firmware update, repair, or hardware change), an encrypted drive may ask for the recovery key before unlocking. The screen shows a recovery key ID (Key ID); match it by its first 8 digits against the stored key. Do not guess.

The most common backup locations for personal devices: a Microsoft account (account.microsoft.com/devices/recoverykey, viewed by logging in from another trusted device). For company or school devices: Entra ID, a school or company account, or the IT department. Other possible locations: a printout made when BitLocker was turned on, a text file saved to a USB stick, or a file backup chosen at the time. Note: the key follows "the account used when it was first set up," which is not necessarily the account currently logged in. For a second-hand machine or a machine set up by a shop, the key may be in the previous owner's or the shop's account.

HARDEST WARNING: Microsoft cannot retrieve, provide, or rebuild a lost recovery key on a user's behalf. If the correct key cannot be found, the usual only way out is a clean reinstall, and data on the encrypted drive will be lost. Do not post a photo of the full 48-digit key online, paste it into a forum, or hand it to an unverified third-party tool or support chat. Before confirming the key, do not perform a Reset, reinstall, or format the drive.

The BitLocker check belongs at the very first step "before any repair install, reinstall, or firmware update," not as a footnote at the end. The four pre-work items must all be ready: personal files backed up (a restore point does not count), a restore point manually created with a name describing the change, the BitLocker recovery key found, and the account password noted down (a Safe Mode PIN may not work).

12. Choosing the repair path: repair install versus clean reinstall

A repair install (in-place upgrade or repair install) means: use Windows installation media (mount the ISO and run setup.exe) and choose "Keep personal files and apps," replacing only the operating system core while keeping installed software, settings, and files. It suits fixing damaged system files or failed updates without reinstalling every program. A repair install has to run from inside Windows: mount the ISO and run setup.exe after signing in. Booting from USB and running setup goes down the clean-install route, not a repair install.

A clean reinstall means: wipe the system drive and install Windows from scratch. Personal files, programs, and settings will all be lost unless backed up beforehand. It suits deep system problems, serious malware infection, or persistent driver conflicts that a repair install cannot solve.

SituationTry first
A single driver or software conflict is locked down; system files may be damagedRepair install (keep files and programs); after fixing, reinstall suspect drivers one by one
Multiple dumps point to different drivers; WinDbg, Verifier, clean boot, and hardware tests have all been done with no leadRepair install first; only consider a clean reinstall if that fails
Suspected deep infection, a system changed beyond recognition, or the same blue screen returns immediately after a repair installClean reinstall (with a full backup beforehand, plus BitLocker key and license or password list)
Hardware tests have proven a RAM, SSD, or power-supply problemReplace the hardware first; do not use a reinstall to mask a hardware problem. A reinstall cannot fix bad RAM

Whichever path is chosen, back up first: although a repair install is designed to keep files, data can still be lost if something goes wrong during the process. Never write "keeping files means no backup is needed". Pre-checks before a repair install: the C: drive needs enough space (third-party tutorials suggest at least about 25 GB free; treat this as a suggested value, not a Microsoft hard requirement), confirm TPM 2.0, Secure Boot, and CPU compatibility, and making a disk image beforehand is even safer.

Multi-machine same-stop-code triage, stated only as a triage question without expanding into enterprise process: ask about commonality first. Is it the same batch of updates, the same driver version, the same software (for example security software, VPN, monitoring programs), the same hardware batch, or the same firmware version? The stronger the commonality, the more you should first stop or roll back the common item and check Release Health or vendor announcements, rather than wasting time doing hardware tests machine by machine. If many machines fail at the same time after one update, first check whether that update has a safeguard hold or an out-of-band fix; do not immediately reinstall each machine.

13. Recurrence prevention policy: written as an executable checklist

Dump settings: Make sure the system has dump collection turned on, or the next blue screen will leave no evidence. After a blue screen, keep the `C:\Windows\Minidump\` files; do not delete them with cleanup tools.

Driver update strategy (stated as practical advice, not official rules):

  • Update drivers only through vendor official channels or Windows Update. Do not use third-party "one-click update all drivers" tools to replace everything at once.
  • Update only one suspect driver at a time, and observe for a period before touching the next one; otherwise, when something goes wrong, you will not know which update caused it.
  • Create a restore point before updating, and note down the old driver version so you can roll back.

Restore points and backups: Before turning on Verifier, updating drivers, updating BIOS or firmware, or doing a repair install, you must first have a restore point or disk image. No restore point means no way back. Do not mix up the three layers (Microsoft official backup overview): Windows Backup or OneDrive backs up personal files and settings; File History uses an external drive or network location to keep multiple versions of personal files continuously; System Protection or System Restore points are snapshots of system files, settings, and the registry, which can restore system changes but will not restore deleted personal files. System Protection may not be turned on by default. First go to "Create a restore point" > System Protection tab > choose the C: drive > Configure > Turn on system protection, and only then can you create one manually. Before every major change, manually create one with a name describing the change, for example "Before Graphics Driver Update" or "Before Windows Update".

Restore-point time limits need careful wording: a third-party compilation updated October 21, 2026 states that Windows 11 restore points have a 60-day limit, after which they are gone, with no setting to extend it. Feature updates can also clear all restore points. Long-term rollback needs a full system image backup, not restore points. This point comes from third-party reporting compilations; do not treat it as original Microsoft official documentation text; put it this way: "According to 2026 third-party compilations, restore-point retention is limited; do not assume an old point is still there. Check the timestamp right before doing anything".

Monitoring: After a blue screen, record the date, time, what you were doing, and the stop code. Use Event Viewer to match the timeline; do not just record "blue screen again." Regularly check temperature, fans, and drive health; do not wait for a blue screen before checking.

14. Myth-busting

1. "`Probably caused by` names a driver, so that driver is the culprit." Wrong. It is only a clue; cross-confirm with multiple dumps, stacks, and lmv.

2. "Seeing ntoskrnl.exe means Windows is broken and needs a reinstall." Wrong. The kernel appears often because it is the place standing there at the moment of the crash; the real trigger is usually a driver or hardware.

3. "MemTest86 with 1 pass and no errors means the RAM is 100% fine." Wrong. One pass is only a quick check; intermittent faults need 2-4 passes or overnight runs to have a chance of being caught, and zero errors are still not a 100% guarantee.

4. "A red line in MemTest86 definitely means that RAM stick is bad; replacing it fixes it." Wrong. A red line can come from the slot, motherboard, controller, firmware settings, temperature, or unstable XMP; swap sticks across slots and retest before concluding.

5. "A clean Driver Verifier result means drivers and hardware are both fine." Wrong. Verifier only tests driver behavior, not hardware; bad hardware may not trigger a Verifier blue screen.

6. "A clean boot can be used long-term as a resource-saving mode." Wrong. A clean boot is a diagnostic state; restore afterwards, or antivirus, backup, and sync services will stay disabled long-term.

7. "Secure Boot certificate expiry means the machine immediately cannot boot." Wrong. Boot time generally does not enforce expiry dates, and the machine can still boot; the real effect is that future boot-chain security updates and revocation lists will no longer arrive.

8. "Reinstalling Windows can fix every blue screen." Wrong. Bad RAM, a bad SSD, insufficient power, or overheating cannot be fixed by reinstalling; rule out the hardware path before reinstalling.

9. "A repair install keeps files, so no backup is needed." Wrong. Keeping files is the design goal, not a guarantee; data can still be lost if something goes wrong during the process, so back up beforehand.

10. "Different blue screen codes every time means there is no cure." Wrong. Different codes every time are themselves a clue, pointing to deeper RAM, power, motherboard, or unloaded-symbol problems, not to "no lead."

11. "If the BitLocker key cannot be found, Microsoft can retrieve it." Wrong. Microsoft states clearly that it cannot retrieve, provide, or rebuild a lost recovery key.

12. "DDU is a Microsoft official tool that fixes everything." Wrong. DDU is a third-party tool; hardware faults (loose power, failed cooling) cannot be fixed by deleting drivers.

13. "Driver rollback lets you pick back any older version step by step." Wrong. Windows only keeps the previous version; a greyed-out button means there is nothing to roll back to.

14. "Pausing updates means permanently switching updates off." Wrong. Pausing is a hold limited to 35 days, renewable; it resumes automatically when it expires. Staying un-updated long-term leaves a machine behind; 24H2 update support already ended on October 13, 2026.

15. "Bypassing a safeguard hold to install a new version is fine." Wrong. A hold exists because Microsoft already knows that combination has serious problems; bypassing it risks installing a version already known to cause problems.

16. "WinRE can uninstall any old update." Wrong. WinRE only uninstalls the latest quality or feature update; older problems need System Restore.

17. "Kernel-Power 41 means the power supply is broken." Wrong. 41 only means the previous shutdown was abnormal; BugcheckCode and dumps need checking before they mean anything.

18. "Normal HWiNFO voltages mean the power supply is definitely fine." Wrong. Software readings cannot catch brief disturbances or internal power-supply faults; swapping in a known-good power supply for a cross-test is decisive.

19. "The January or June 2026 updates blue-screened all computers." Wrong. The January KB5074109 official acknowledgment covers a limited number, mainly commercial devices; for June KB5094126, keep the BSOD or BitLocker part split between Microsoft acknowledgment and third-party reporting.

20. "Reinstalling Windows right after a blue screen is fastest." Wrong. Reinstalling without isolation, without a backup, and without recording codes and timing destroys judgment clues; if the hardware itself is faulty, the blue screen will return after reinstalling.

15. Stop and send for repair red lines: stop immediately if any one appears

If any of the following appears, stop at once. Do not keep powering on repeatedly or reinstalling repeatedly (a synthesis of the judgment logic from the sources above; practical advice, not item-by-item official text):

  • Problems still occur in BIOS or in a minimum-system state (Windows drivers already ruled out).
  • Single-stick RAM, slot swaps, power-supply swaps, discrete-GPU removal, XMP off, and BIOS defaults restored have all been tried, and the blue-screen pattern is unchanged.
  • A burnt smell, swollen capacitors or burn marks, unusual power-supply noise or smell, or a swollen battery (laptops).
  • Hard drive or SSD noises, or SMART signs already clearly indicating failure (The previous article already covered SMART in depth; this article only needs to call a stop).
  • Data not backed up while the drive itself is suspected faulty: stop to protect data first; do not repeatedly reinstall or run chkdsk writes on a suspected faulty drive.
  • A machine still under warranty: dismantling or replacing parts yourself may affect warranty; check the warranty terms first.
  • A company or encrypted machine: do not enter WinRE and uninstall updates without a BitLocker key or administrator authorization.
  • `!errrec` showing a Fatal hardware error, MemTest86 still showing errors after slot swaps, or a suspected power supply not yet ruled out.

On pricing, once again: no public price list applicable to this company for recurring blue screen root-cause work could be found. All repair items are "price on individual quotation." This article gives no price estimates and no success-rate figures.

Frequently Asked Questions

Q1: My machine blue-screens once a month. Does that count as a recurring blue screen?

Look at the codes and timeline. Microsoft states that most occasional restarts are resolved by the restart itself; but the same stop code appearing frequently should be followed up. Once a month with the same code every time is worth recording and following up. If the code differs every time and intervals are long, observe and record first; do not start major repairs right away.

Q2: WinDbg says "Probably caused by" a certain driver. Should I remove it right away?

Do not conclude that fast. "Probably caused by" is only the "most likely" clue; sometimes it is the real culprit, sometimes only where the corruption surfaced. Check whether IMAGE_NAME and the stack are consistent across 3-5 more dumps, then use `lmv` to check version and publisher before deciding to update, roll back, or remove.

Q3: I see ntoskrnl.exe. Does that mean Windows is broken and needs reinstalling?

No. ntoskrnl.exe appears often because the kernel is the place standing there at the moment of the crash; the real trigger is usually a driver or hardware. Cross-check IMAGE_NAME, the stack, and multiple dumps before concluding.

Q4: I turned on Driver Verifier and now cannot get into Windows. What do I do?

There is an escape method: enter Safe Mode and run `verifier /reset`. If Safe Mode cannot be entered, use Windows installation media to enter WinRE, then run `verifier /reset` at the command prompt, or restore from a restore point made beforehand. That is why a system restore point or system image needs creating before turning Verifier on, and why Verifier should never be turned on casually on your only work machine.

Q5: How many MemTest86 passes count as a pass?

This is third-party tutorial consensus, not an official rule: at least 2 complete passes; for a serious check of intermittent faults, run 4 passes or overnight. One pass is only a quick check, and zero errors are still not a 100% guarantee. Any reproducible error needs following up, and red lines need retesting by swapping sticks across slots before deciding whether the problem is the stick or the slot.

Q6: The blue screen disappeared after a clean boot. Does that mean the machine is fixed?

No. A clean boot is only a diagnostic state, proving the culprit is among the disabled third-party services or startup items. Afterwards, use the "halve and re-enable" method to lock down a single item, then update, remove, or configure that item. Finally, restore the disabled services and startup items; do not use a clean boot as a daily mode long-term.

Q7: After the 2026 Secure Boot certificate expiry, can the machine no longer boot at all?

No. Boot time generally does not enforce certificate expiry dates; a registered 2011 certificate can still boot a device even after expiry. The real effect is that new Secure Boot database updates, DBX revocation lists, and Windows Boot Manager protection updates will no longer arrive. Before a repair, do not casually clear DB or KEK, and do not casually switch Secure Boot off.

Q8: Before touching Secure Boot or doing a repair install, what matters most?

Find the BitLocker 48-digit recovery key first. Match it using the first 8 digits of the Key ID shown on screen. Personal devices usually find it in the Microsoft account; company or school devices should ask the IT department. Microsoft cannot retrieve a lost key on a user's behalf, so do not perform a Reset, reinstall, or drive format if the key cannot be found.

Q9: How do I choose between a repair install and a clean reinstall?

If a single driver or software conflict is locked down and system files may be damaged, try a repair install first (keeping personal files and apps). If a deep infection is suspected, or the same blue screen returns immediately after a repair install, consider a clean reinstall. If hardware tests have proven a RAM, SSD, or power-supply problem, replace the hardware first; do not use a reinstall to mask a hardware problem. Whichever path is chosen, back up first; keeping files is the design goal, not a guarantee.

Q10: When should I stop and send the machine for repair instead of trying further myself?

Stop if problems occur in BIOS or a minimum system, if the full isolation set has been tried with no change in pattern, if there is a burnt smell or burn marks or swollen capacitors, if data is unbacked up while the drive is suspected faulty, if warranty terms have not been checked for a machine under warranty, or if a company encrypted machine lacks a key or authorization. In any of these cases, stop powering on repeatedly or reinstalling repeatedly and send it for repair.

Sources

---

Related articles

Frequently Asked Questions

My machine blue-screens once a month. Does that count as a recurring blue screen?

Look at the codes and timeline. Microsoft states that most occasional restarts are resolved by the restart itself; but the same stop code appearing frequently should be followed up. Once a month with the same code every time is worth recording and following up. If the code differs every time and intervals are long, observe and record first; do not start major repairs right away.

WinDbg says "Probably caused by" a certain driver. Should I remove it right away?

Do not conclude that fast. "Probably caused by" is only the "most likely" clue; sometimes it is the real culprit, sometimes only where the corruption surfaced. Check whether IMAGE_NAME and the stack are consistent across 3-5 more dumps, then use `lmv` to check version and publisher before deciding to update, roll back, or remove.

I see ntoskrnl.exe. Does that mean Windows is broken and needs reinstalling?

No. ntoskrnl.exe appears often because the kernel is the place standing there at the moment of the crash; the real trigger is usually a driver or hardware. Cross-check IMAGE_NAME, the stack, and multiple dumps before concluding.

I turned on Driver Verifier and now cannot get into Windows. What do I do?

There is an escape method: enter Safe Mode and run `verifier /reset`. If Safe Mode cannot be entered, use Windows installation media to enter WinRE, then run `verifier /reset` at the command prompt, or restore from a restore point made beforehand. That is why a system restore point or system image needs creating before turning Verifier on, and why Verifier should never be turned on casually on your only work machine.

How many MemTest86 passes count as a pass?

This is third-party tutorial consensus, not an official rule: at least 2 complete passes; for a serious check of intermittent faults, run 4 passes or overnight. One pass is only a quick check, and zero errors are still not a 100% guarantee. Any reproducible error needs following up, and red lines need retesting by swapping sticks across slots before deciding whether the problem is the stick or the slot.

The blue screen disappeared after a clean boot. Does that mean the machine is fixed?

No. A clean boot is only a diagnostic state, proving the culprit is among the disabled third-party services or startup items. Afterwards, use the "halve and re-enable" method to lock down a single item, then update, remove, or configure that item. Finally, restore the disabled services and startup items; do not use a clean boot as a daily mode long-term.

After the 2026 Secure Boot certificate expiry, can the machine no longer boot at all?

No. Boot time generally does not enforce certificate expiry dates; a registered 2011 certificate can still boot a device even after expiry. The real effect is that new Secure Boot database updates, DBX revocation lists, and Windows Boot Manager protection updates will no longer arrive. Before a repair, do not casually clear DB or KEK, and do not casually switch Secure Boot off.

Before touching Secure Boot or doing a repair install, what matters most?

Find the BitLocker 48-digit recovery key first. Match it using the first 8 digits of the Key ID shown on screen. Personal devices usually find it in the Microsoft account; company or school devices should ask the IT department. Microsoft cannot retrieve a lost key on a user's behalf, so do not perform a Reset, reinstall, or drive format if the key cannot be found.

How do I choose between a repair install and a clean reinstall?

If a single driver or software conflict is locked down and system files may be damaged, try a repair install first (keeping personal files and apps). If a deep infection is suspected, or the same blue screen returns immediately after a repair install, consider a clean reinstall. If hardware tests have proven a RAM, SSD, or power-supply problem, replace the hardware first; do not use a reinstall to mask a hardware problem. Whichever path is chosen, back up first; keeping files is the design goal, not a guarantee.

When should I stop and send the machine for repair instead of trying further myself?

Stop if problems occur in BIOS or a minimum system, if the full isolation set has been tried with no change in pattern, if there is a burnt smell or burn marks or swollen capacitors, if data is unbacked up while the drive is suspected faulty, if warranty terms have not been checked for a machine under warranty, or if a company encrypted machine lacks a key or authorization. In any of these cases, stop powering on repeatedly or reinstalling repeatedly and send it for repair.

WhatsApp 2115 9219