📌 Key Takeaways
- •Desktop, Documents, Pictures, Videos, Music, and other user folders;
- •Files outside user folders — for example files placed directly in other custom folders on the C: drive — which may not be preserved by a reset, and must be checked one by one;
- •At least one backup on an external drive, USB, or cloud; after backing up, open the backup to verify the files actually open — don't judge by capacity numbers alone.
- •Windows backup tools: Windows Backup can sync Desktop, Documents, Pictures, Videos, and Music folders to OneDrive; File History can back up Documents, Pictures, Music, Videos, Desktop, and OneDrive files, keeping older versions.
- •If needed, create a System Image as a complete backup of the whole computer for whole-machine restore reference.
After a Blue Screen: Don't Reinstall First — Save Your Data, Then Triage
Our earlier article covered the general causes of blue screens. This one covers something different: what to do after a blue screen has already happened — how to protect your data, then narrow down the culprit step by step with advanced tools. The order matters: back up and record the evidence first, try low-risk checks next, and only then consider high-risk tools or a reinstall. Reversing that order can easily destroy unbacked-up data or make the machine harder to diagnose.
Every procedure and definition in this article is traced to the two research notes' sources — Microsoft Learn, Microsoft Support, and Microsoft Q&A — and where a point comes from a third-party summary or a research synthesis, the article says so rather than dressing it up as an official instruction. One warning comes first: the same stop code can have several causes. One line on the blue-screen display alone cannot tell you which part has failed; you need the dump file, what changed just before the crash, and whether the pattern repeats before you draw a conclusion.
First principle: don't reinstall immediately — record evidence and back up
Microsoft Support's recovery-options document states plainly that before using recovery options you should try to back up important files to an external drive or the cloud, because some options — for example a reset or reinstall — can cause data loss. The same document's logic is also clear: reinstalling from recovery media or installation media comes after Windows fails to start, Startup Repair fails, and System Restore fails. In other words, reinstalling is a later option, not the first step. A clean install installs Windows from scratch and removes all files and applications on the computer, so backing up first is essential.
If you can still get into Windows, follow this order:
1. Record the evidence before making big changes: write down the stop code, the time it happened, and what you did just before — a driver update, a new program, new hardware, or a Windows update. Copy the .dmp files from C:\Windows\Minidump to another location, such as the desktop, and compress them for safekeeping. Don't delete them with Disk Cleanup before they have been examined. Several Microsoft Q&A replies recommend exactly this: copy the Minidump files to the desktop and compress them.
2. Back up before diagnosing: copy important files to an external drive or the cloud first, then run diagnostics that require a restart. Windows Memory Diagnostic, for example, only runs after a restart, so running it with unsaved work open is risky.
3. Then try lower-impact checks: updating or rolling back a recent driver, a system-file check, or a disk check. After each step, watch whether the crash still happens before moving on; otherwise, even if the problem goes away, you won't know which step fixed it.
4. If a disk problem is suspected, don't keep power-cycling to see if it works: this is an operating suggestion, not an official instruction. Every abnormal shutdown or restart can increase the risk to unbacked-up data.
If the machine won't boot, consider the Windows Recovery Environment (WinRE) route. A commonly described method in Microsoft Q&A is: while Windows is loading (the spinning dots), hold the power button for 5–10 seconds to force a shutdown, do that twice, and the third boot enters WinRE, which offers Startup Repair, Safe Mode, and Command Prompt. Following Microsoft Support's recovery-options logic, the order is Startup Repair first, then System Restore, then reinstalling from recovery media if you have it, or installation media if you don't. Once you reach Safe Mode, back up your data before checking drivers.
If you can reach Command Prompt in WinRE, Microsoft Q&A describes a practical workaround: open Command Prompt, type notepad.exe, then use Notepad's File → Open dialog as a file browser to copy files to a USB drive. Booting from installation media, choosing Repair your computer, then Troubleshoot, then Command Prompt gives you the same route. Creating installation media requires another working computer and a USB drive with at least 8GB of space, plus the Windows media-creation tool from Microsoft's official site. If none of these routes work and you have no backup, this article's advice is not to try formatting or reinstalling on your own — preserve the machine as it is and seek a check that can read the drive. That last sentence is a research recommendation, not an official quotation.
Which situations deserve extra care with data? Repeated KERNEL_DATA_INPAGE_ERROR (0x7A) or disk-related pointers: suspect the storage device or page-file reading first, give backup the highest priority, and don't run disk defragmentation or heavy writes first. Repeated CRITICAL_PROCESS_DIED (0xEF) where you cannot get into the system: system files or disk integrity may already be damaged, so WinRE's System Restore or an offline system-file check is worth trying before a direct reinstall. Even a single blue screen that never repeats is worth keeping: save the Minidump and note the timeline, so a later repeat of the same code can be compared.
Reading dump files: locations, types, WinDbg, and BlueScreenView
Default locations
Small memory dumps (Minidumps) live by default in %SystemRoot%\Minidump, normally C:\Windows\Minidump. Kernel or complete dumps default to %SystemRoot%\MEMORY.DMP, normally C:\Windows\MEMORY.DMP; MEMORY.DMP only appears after a genuine crash (bug check) — no crash, no file. Both locations come from Microsoft Learn's memory-dump-file-options article and related Microsoft Q&A discussion. If C:\Windows\Minidump is empty, either no dump has ever been generated or dump writing has been switched off, and you should check the Startup and Recovery settings first.
The settings path, in concept, is: Control Panel → System → Advanced system settings → Advanced → Startup and Recovery → Settings → the Write debugging information drop-down, where you can also see the small-dump directory and the dump-file path. After changing registry or settings values, Windows must be restarted for them to take effect — a point Microsoft Learn states explicitly. If you want dumps available later, don't set the option to None; if disk space is tight, keeping Minidumps is already enough for an initial comparison, and a complete dump is only appropriate when a deeper analysis is suspected. That paragraph is a practical research point, not an official quotation.
Dump-type comparison table
The table below follows the CrashDumpEnabled values listed in Microsoft Learn's memory-dump-file-options article. The original article is a Windows Server document, but the type definitions apply to the Windows dump mechanism; the article should note that provenance rather than presenting it as a consumer-edition-only description.
| Setting | What it contains | Default file |
|---|---|---|
| None (0x0) | No dump is produced | — |
| Complete memory dump (0x1) | The full contents of physical memory — the largest, most space-hungry option | %SystemRoot%\MEMORY.DMP |
| Kernel memory dump (0x2) | Only kernel-mode memory: the Windows kernel, hardware abstraction layer (HAL), kernel-mode drivers, and similar — no unallocated memory or user-mode program memory | %SystemRoot%\MEMORY.DMP |
| Small memory dump (0x3, 64 KB) | The smallest option: stop code, parameters, loaded-driver list, the faulting process/thread, and kernel stack, and other basics | %SystemRoot%\Minidump |
| Automatic memory dump (0x7) | The system decides based on available resources; similar in character to a kernel dump; one of the default directions | %SystemRoot%\MEMORY.DMP |
| Active memory dump (0x1 + FilterPages 0x1) | Filters out non-essential pages — smaller than a complete dump but more detailed than a kernel dump | %SystemRoot%\MEMORY.DMP |
WinDbg: the official way to examine a dump
WinDbg is Microsoft's debugger and can open user-mode and kernel-mode dumps; before analysing a dump you must set the symbol path, or the analysis cannot be accurate. The search summary for Microsoft Learn's Read small memory dump files article lists the common commands: !analyze -show shows the stop (bug check) code and its parameters; !analyze -v gives verbose output, including the error code, the likely faulting module, and the stack; lm N T lists loaded modules with their status and paths. The graphical WinDbg can use a symbol-server path such as srvC:\Symbolshttps://msdl.microsoft.com/download/symbols. The research note flags that the Learn page itself returned an access denial when opened directly, so these command points rest on the search summary and other Microsoft documents and should be rechecked against the original page before citation.
Fields to look for in WinDbg output, per a third-party summary consistent with Microsoft's command-output structure, are: BUGCHECK_STR (the human-readable blue-screen name), Probably caused by (the most likely faulting driver or module), IMAGE_NAME (the file that triggered the crash), and STACK_TEXT (the sequence of function calls before the crash).
The most important limitation must be stated clearly, not written as if one look tells you which part has failed: Probably caused by is only an automated best guess, not a verdict. If it points to ntoskrnl.exe (the Windows kernel itself), the kernel itself is rarely the culprit; the real cause often hides deeper in the stack, or comes from a third-party driver passing an invalid instruction. That point is a third-party interpretation, and the correct practice is to look further at the stack and at module names that repeat across crashes, never to swap a part on the strength of one line.
BlueScreenView: a quick comparison tool
BlueScreenView, developed by NirSoft, is a free tool that automatically scans all Minidump files produced during blue screens and lists each crash in a table: Minidump filename, crash date and time, Bug Check Code and its four parameters, and the possibly faulting driver or module. In use, the top half lists each crash by time and the bottom half lists the kernel modules loaded at the time, with drivers related to the crash stack highlighted; the key columns are Bug Check String (for example DRIVER_IRQL_NOT_LESS_OR_EQUAL) and Caused By Driver (for example a particular .sys file).
Its role needs to be stated: BlueScreenView suits a quick check of whether repeated crashes point to the same driver; it does not replace WinDbg's deeper analysis. It only displays what is already in the dump; it does not repair crashes, and it must not be described as a one-click repair tool. It is not a Microsoft official tool; its developer is NirSoft.
Event Viewer: when the blue screen flashes by too fast
After a restart, open Event Viewer → Windows Logs → System and look for the BugCheck event (Event ID 1001) to see the stop code and parameters. The Kernel-Power event (Event ID 41) only means the computer restarted without a clean shutdown; on its own it is not evidence of a blue screen, and it must be read together with 1001. That distinction matters: many people see a 41 and assume a blue screen, but 41 can also come from a power cut, a forced shutdown, and other restart causes.
Advanced stop-code comparison table: read the direction, not just the words
The official definitions below follow Microsoft Learn's bug-check documentation wherever possible; where they come via Q&A, that is noted. Every direction is a priority suspicion, not a diagnosis. The research note also warns that for 0x1A, 0xEF, 0x7A, and 0x50, only Q&A versions of the formal definitions were found this time, not the Learn originals, and those definitions should be rechecked in Learn's Bug Check Code Reference before being quoted as formal definitions.
| Stop code | Official / reported definition | Advanced triage direction |
|---|---|---|
| DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1) | A kernel-mode driver tried to access pageable memory while the process IRQL was too high. Its four parameters are the referenced memory, the IRQL at the time, read/write/execute, and the address referencing the memory. Source: Microsoft Learn Bug Check 0xD1. | Look first at which .sys file the dump points to — commonly display, network, or storage drivers; check whether the crashes began after a driver update or install; don't blame hardware at first sight. |
| IRQL_NOT_LESS_OR_EQUAL (0xA) | Memory that was paged (or invalid) was accessed while IRQL was too high. Q&A reports note this error often appears after installing a faulty device driver, system service, or BIOS. | Similar to 0xD1, but note the difference: 0xA does not necessarily name a driver, so the investigation must also cover system services, BIOS, and recent upgrades or changes; check the Event Viewer system log for the possibly faulting device or driver. |
| MEMORY_MANAGEMENT (0x1A) | A severe memory-management error occurred. | Don't read this as RAM failure directly: Q&A cases note that different first parameters mean different sub-problems — for example, one case with a particular first-parameter value was read as working-set free-list corruption and suspected hardware error — while the same code in other cases can point to driver or display-related factors. So run memory diagnostics, read the dump parameters, and check for overclocking or XMP setting changes before deciding on a hardware direction. |
| CRITICAL_PROCESS_DIED (0xEF) | A critical Windows process terminated unexpectedly, forcing a bug check. Q&A notes this class of error is more serious and usually points to system-file corruption, disk-integrity problems, or driver conflicts. | Check the Event Viewer records near 1001 and note which critical process failed — Q&A examples include smss.exe, csrss.exe, and wininit.exe; suggested check order: system-file check, disk check, storage or antivirus drivers, recent changes; if the machine loops from boot, use WinRE. |
| KERNEL_DATA_INPAGE_ERROR (0x7A) | A kernel data page requested from the page file could not be read into memory. | Investigate storage first: disk or SSD, connections, file system, and page file; Q&A also mentions disk hardware errors and damaged volumes as possible causes; don't start by testing only RAM. |
| PAGE_FAULT_IN_NONPAGED_AREA (0x50) | Invalid system memory was referenced. Q&A reports list common causes including device-driver errors, hardware-related memory problems, NTFS volume corruption, and antivirus software. | Split the direction in two: drivers, antivirus, and new hardware on one side; RAM and disk on the other. Read the dump's module pointer first, then decide what to test — don't start with a full reinstall. |
How to use stop codes for advanced triage
1. Record the full combination, not just the name: stop-code name plus its four parameters plus the module name in the dump — only together do they have comparison value. Remembering MEMORY_MANAGEMENT alone is not enough to triage.
2. Match the timeline: did the crashes start after installing new hardware, updating a driver, updating Windows, or installing antivirus or low-level tools? Several Q&A replies use this as the first triage step.
3. Match the repetition: one crash and several crashes pointing at the same .sys file mean completely different things. Multiple Minidump files pointing at the same driver are worth suspecting; if each crash points somewhere different, suspect a common cause first — memory, motherboard slots, power, or system files. This point is a research methodology built on the Minidump multi-file comparison property.
4. Verify layer by layer, don't skip levels: driver direction (update, roll back, or remove a recent driver) → system-file direction → memory diagnostics → disk checks → hardware isolation (one RAM stick at a time, removing newly added hardware). After each step, check whether the crash still happens before moving on.
5. Don't treat Probably caused by as the final answer: see the WinDbg limitations above.
Windows Memory Diagnostic: how to run it, read the result, and understand its limits
Official use
Method one: type memory in the taskbar search box and choose Windows Memory Diagnostic. Method two: press Win+R, type mdsched.exe, press Enter, then choose to restart and check now or check at the next startup. The official flow: after the restart, the diagnostic runs before Windows loads and the screen shows test progress; even if the screen looks stuck, the test is still running; when it finishes, Windows restarts automatically, and you see the result after signing in.
For test depth, pressing F1 during the test lets you use the arrow keys to set Test Mix to Basic, Standard, or Extended, then F10 applies it and continues; the default runs the standard test automatically. For reading results, the official document only says the result appears after sign-in; a third-party summary adds that if no notification appears after sign-in, you can open Event Viewer → Windows Logs → System and look for the source MemoryDiagnostics-Results — with Event ID 1201 described as the completed-test summary and 1202 as extra detail when hardware memory errors are detected. An additional official scenario: if the computer crashes because of a memory fault and Windows Memory Diagnostic detects a problem, the system prompts at the next restart to schedule a memory test.
Need a laptop repair expert?
Free diagnosis · Transparent pricing · No fix, no fee · 180-day warranty
Limits: passing does not mean the RAM is definitely fine
The built-in tool is a first screening step, more basic than dedicated memory-test tools; summaries note it can miss intermittent, heat-related, or timing-related faults. No errors detected does not rule out RAM: intermittent or software-related memory problems can still exist; if the problem persists, consider a deeper tool (for example a third-party test booted from USB) or testing RAM sticks one at a time to isolate which stick or slot is at fault. A power cut or interruption during the test means no result is left in Event Viewer, so don't force a shutdown mid-test. Save your work first, because the tool must restart the computer before it runs. Finally, don't tie a memory-diagnostic result too tightly to a stop code: MEMORY_MANAGEMENT points to a severe memory-management error, but its cause can be hardware, a driver, or other factors — don't write it as if seeing that code means the RAM must be replaced.
Clean boot: the right way to isolate third-party software conflicts
Definition and use
A clean boot starts Windows with a minimal set of drivers and startup programs, making it easier to identify and troubleshoot background software conflicts. Microsoft Support notes that a clean boot differs from Safe Mode in that it gives greater control over isolating the problem source. It suits suspected third-party software or service conflicts — for example, crashes that began after installing a program or an update, or crashes whenever a particular program opens. It does not directly prove a hardware fault; if the problem persists in a clean boot, the problem is probably not caused by the disabled third-party services or startup programs. Microsoft Support also notes that if a program still misbehaves in a clean-boot environment, the problem is not caused by interference from other programs or services.
Official steps (Windows 10 / 11)
1. Sign in as an administrator.
2. Search for msconfig and open System Configuration.
3. On the Services tab, tick Hide all Microsoft services, then choose Disable all, then Apply. This step is the most critical: disabling all services without hiding Microsoft services can cause system problems. Microsoft Support also warns against changing advanced startup options on a network-policy-managed computer without guidance from a Microsoft support engineer.
4. On the Startup tab, choose Open Task Manager.
5. On Task Manager's Startup apps tab, disable each Enabled item one by one, and note which items you disabled so you can restore them later.
6. Close Task Manager, click OK in System Configuration, and restart — you are now in a clean-boot environment.
7. During a clean boot the computer may temporarily lose some functionality; that is expected, not a new fault.
Finding the culprit by halving
The principle is simple: if the problem disappears in a clean boot, the culprit is among the disabled services or startup programs; if it persists, the culprit is not among them. Microsoft's recommended efficient method is not to try items one by one but to enable half of the disabled services or startup programs at a time and restart to test; if the problem returns, the culprit is in the half just enabled, so halve that half again next round; if the problem stays away, that half is clear, so try the other half; repeat until a single service or startup item is isolated. Once found, Microsoft Support's two reasonable outcomes are: contact the program's vendor for a fix, or leave that service unchecked or that startup item disabled in normal use.
You must restore normal startup afterwards
1. Search for msconfig and open System Configuration.
2. On the General tab, choose Normal Startup.
3. On the Services tab, untick Hide all Microsoft services, choose Enable all, and Apply.
4. On the Startup tab, open Task Manager and re-enable each previously disabled startup program, then click OK.
5. Restart when prompted.
A clean boot is only a troubleshooting mode — don't keep using it as if it were normal operation. Take a screenshot or note the disabled list, or restoration will miss items.
Driver Verifier: a tool that forces a faulty driver to reveal itself — not a repair tool
What it is
Driver Verifier monitors Windows kernel-mode drivers and graphics drivers, detecting illegal function calls or behaviour that could damage the system; it can apply various stress tests to drivers to find improper behaviour. The source is Microsoft Learn's verifier article. In practical terms, it is not a repair tool but a test tool that forces a faulty driver to show itself. A driver that rarely fails in normal use may blue-screen sooner with Verifier enabled, and that is the point: to obtain the stop code and file name pointing at that driver. When the system blue-screens because of Verifier, the display may show DRIVER_VERIFIED_DETECTED_VIOLATION plus the related .sys filename, and the dump produced can be analysed further with debugging tools.
You must be a member of the Administrators group to use Driver Verifier. The basic commands, per the official syntax: verifier /standard /all verifies all drivers with standard settings; verifier /standard /driver NAME verifies a named driver with standard settings; verifier /query queries the current settings; verifier /querysettings queries the enabled options and verified drivers; verifier /reset resets or switches Verifier off.
The graphical flow, as organised in Microsoft Q&A rather than as the single official flow, is: type verifier in the Start menu to open Driver Verifier Manager; choose Create custom settings and continue; choose Select driver names from a list and pick non-Microsoft drivers; restart, then use the computer normally and wait for the trigger condition to produce a stop code and .sys name.
The research recommendation is to target suspected drivers rather than verifying all drivers at once; verifying everything together makes attribution harder and makes the system more unstable. A Microsoft Q&A reply likewise warns to target only suspect drivers in a controlled way, because enabling Verifier for all drivers can sometimes produce endless blue screens after boot.
Risks: it can make the system more unstable, or unbootable
Microsoft Learn warns explicitly that running Driver Verifier can crash the computer, so it should only be run on a computer used for testing and debugging. A Microsoft Q&A warning is even more direct: before starting, make sure you know how to enter Safe Mode to switch Verifier off, or the computer may become unusable. Other risks, stated as risk warnings rather than guarantees: Verifier is not a daily-use tool — leaving it on keeps stressing drivers and can cause instability and performance effects; if it blue-screens early in boot, you may not reach the normal desktop and will need Safe Mode or WinRE; and if you enabled Verifier before backing up, a later reinstall or restore carries higher data risk.
Safe exit: know how to switch it off before you switch it on
Normal case, when you can reach Windows: open Command Prompt as administrator; type verifier /reset; restart the computer.
If you cannot reach the normal desktop, use the Safe Mode route: enter WinRE — for example by forcing a shutdown twice during boot loading, so the third boot enters the recovery environment; choose Troubleshoot → Advanced Options → Startup Settings → Restart, then press 4 or F4 for Safe Mode; in Safe Mode, open Command Prompt as administrator, type verifier /reset, and restart.
If even Safe Mode is unreachable, the fallback routes — stated as fallbacks, not first choices — are: in WinRE, use Command Prompt to run verifier /reset; or use System Restore to return to a restore point from before Verifier was enabled; or use Windows installation media to enter the recovery environment and do the same. An extra command appears only in a Microsoft Q&A reply, so it must be attributed at that level rather than as a Learn original: verifier /bootmode resetonbootfail, which a reply suggests using together with verifier /reset in the recovery environment so the next boot failure resets Verifier.
A pre-Verifier safety checklist: back up important files first; create a system restore point before enabling it; note exactly which drivers you are verifying; as soon as you find the culprit or finish triage, switch Verifier off immediately with verifier /reset — don't leave it on long-term; and note how to enter Safe Mode or WinRE before you need it, not after the machine won't boot.
Driver roll back vs update vs reinstall: how to choose
Don't mix up the three actions. Updating a driver installs a newer version, and suits an outdated driver, a known fix, or a new vendor release. Rolling back restores a previously installed older version, and suits problems that appeared after a driver or Windows update. Reinstalling removes the existing driver and installs it again from Windows or the vendor installer, and suits corrupted driver files or scrambled settings.
| Action | Meaning | Try it first when |
|---|---|---|
| Update driver | Install a newer driver version | The driver is outdated or the vendor has released a fix |
| Roll back driver | Restore the previously installed older version | The problem appeared after a driver or Windows update |
| Reinstall driver | Remove the existing driver, then install it again from Windows or the vendor installer | Driver files are corrupted or settings are scrambled |
The decision flow, as a research synthesis rather than an official flowchart, is: first ask the timing question — did the problem appear after a particular update? If yes, try roll back first, because the older version previously worked, so the new version is the likelier cause; if no, don't roll back blindly — first check whether there is a reason to update or reinstall. Then ask whether the Roll Back button is greyed out or unclickable: if it is, the system has no older version stored and cannot roll back, so use another route — download the older version manually from the device vendor's official site, or update to a newer fixed version. Microsoft Support's roll-back flow presupposes an older version to restore. Then ask whether the problem is driver corruption or scrambled settings rather than version age: if yes, try reinstalling. If roll back fixes the problem but a later Windows update pushes the faulty version back, a single roll back is not a long-term fix — watch whether later updates repeat the problem; if it repeats, record the version numbers and times and let a diagnostic judge whether to wait for a vendor fix or use another version. That point is a research recommendation, not a Microsoft promise. If all three methods have been tried and the problem persists, don't loop through drivers endlessly — move to clean boot, Driver Verifier (advanced and risky), system-file checks, memory checks, or the repair-assessment section below.
Common wrong claims to avoid: don't write that the newest driver is always best — problems can appear after an update, and Microsoft notes that rolling back can resolve post-update problems; don't write that roll back is always clickable — the button may be unavailable because no older version is stored; don't write that reinstalling a driver equals reinstalling Windows — the two differ completely in scope, since reinstalling a driver affects one device while reinstalling Windows affects the whole system and installed programs. For driver sources, prefer Windows Update or Device Manager, or the device vendor's official site; this article does not recommend driver download sites of unknown origin.
Triage-flow comparison table: what each step does, and what its result means
| Step | What it does | If the problem disappears, it means | If the problem persists, it means |
|---|---|---|---|
| Record evidence + back up | Note the stop code and timeline, copy Minidumps, back up to an external drive or the cloud | Not a fix — only that the basis for analysis and recovery is preserved | Keep going, and don't skip backup to try a high-risk step |
| Event Viewer 1001 | Read the BugCheck event's stop code and parameters, and confirm a real blue screen | A 1001 means a blue-screen record exists; a lone 41 does not equal a blue screen | No 1001 suggests a power cut, forced shutdown, or another restart cause |
| Memory Diagnostic mdsched.exe | Run Basic, Standard, or Extended tests before Windows loads | Errors point toward memory, needing isolation of which stick or slot | Passing does not rule out RAM — intermittent faults can be missed |
| Clean-boot halving | Disable non-Microsoft services and startup programs, then re-enable half at a time and test | The culprit is in the disabled group | The culprit is not in the disabled services or startup programs |
| Driver roll back / update / reinstall | Choose roll back, update, or reinstall for one driver based on timing | That driver version or file is a likely culprit | Don't loop endlessly — move to system-file, memory, and disk directions |
| Driver Verifier | Stress suspect drivers to obtain a stop code and file name pointing at one driver | A blue screen naming a .sys file gives the next investigation direction | Switch Verifier off immediately with verifier /reset — don't leave it on |
| Reinstall Windows | A more thorough software measure, in keep-my-files and remove-everything forms | The problem was more likely software-level | A blue screen after reinstall points more toward hardware — send for inspection |
Before reinstalling Windows: backup checklist, and reset vs clean install
Reset vs clean install: know the difference first
Keep my files reset: reinstalls Windows and keeps personal files, but removes installed applications and drivers and restores settings. Remove everything reset: reinstalls Windows and removes all personal files, installed applications and drivers, and settings. There are two reinstall methods: local reinstall (using the computer's own files) and cloud download (downloading a fresh Windows image from Microsoft's servers, which requires internet access). The key warning, in bold: even if you choose Keep my files, Microsoft Q&A replies still recommend backing up all personal files first, because an error during reset can still cause data loss; don't treat Keep my files as a backup.
Pre-reinstall backup checklist
A. Personal files (highest priority)
- Desktop, Documents, Pictures, Videos, Music, and other user folders;
- Files outside user folders — for example files placed directly in other custom folders on the C: drive — which may not be preserved by a reset, and must be checked one by one;
- At least one backup on an external drive, USB, or cloud; after backing up, open the backup to verify the files actually open — don't judge by capacity numbers alone.
- Windows backup tools: Windows Backup can sync Desktop, Documents, Pictures, Videos, and Music folders to OneDrive; File History can back up Documents, Pictures, Music, Videos, Desktop, and OneDrive files, keeping older versions.
- If needed, create a System Image as a complete backup of the whole computer for whole-machine restore reference.
- Browser bookmarks or favourites: export them or confirm they are synced to a Microsoft, Chrome, or Firefox account;
- Saved browser passwords: confirm they are synced, or use the browser's own export function to back them up — exported files are sensitive and must not be left in shared locations;
- Microsoft account sign-in details: you will need to sign in again after reinstalling, so note the account and an available second-factor method.
- Note the computer brand, model, graphics card, network card, and other key devices, so drivers can be downloaded from vendor sites after reinstalling;
- After reinstalling, check Device Manager for unrecognised devices and install any missing drivers from vendor sites;
- List the software to reinstall, together with each installer's source;
- Application licences or product keys: for licensed software such as Office, note the key and account; some software may need its licence deactivated before reinstalling, and that must be handled per each vendor's instructions, not as a blanket rule.
- BitLocker recovery key: if the device is encrypted, find and note the 48-digit recovery key before reinstalling; possible locations include a Microsoft account, a printed copy, or a text file on a USB drive; Microsoft Support states plainly that it cannot retrieve or recreate a lost key for you.
- Wi-Fi passwords: you will need to reconnect after reinstalling, so note them first;
- Keep the laptop plugged into power: a reinstall must not be interrupted by a drained battery.
- Don't force a shutdown or cut power during reinstalling;
- After reinstalling, run Windows Update first, then check that drivers and personal files are complete;
- Reinstall software from the earlier list one at a time, not all at once, so a newly introduced problem can be traced to one program.
When to stop and send it for inspection: repair-assessment signals, not a diagnosis list
The following is not a diagnosis list but a set of directions for when to stop repeating software attempts and hand the machine to professional inspection. Each signal is only a suspicion direction; only inspection results can confirm a fault — don't write any of them as a fixed verdict on a particular part.
1. Blue screens persist after reinstalling or resetting Windows: a Microsoft Q&A reply notes that reinstalling Windows is a more thorough software measure; if blue screens persist after reinstalling, a hardware problem becomes more likely.
2. Driver changes, roll back, reinstall, clean boot, and system-file checks have all been tried, and the problem keeps recurring: once reversible software steps are exhausted, repeating the same class of method has low returns — move to hardware inspection, for example memory, hard disk or SSD, cooling, and motherboard-related checks, rather than reinstalling endlessly. Microsoft Q&A replies after driver steps suggest Windows Memory Diagnostic for RAM, hard-disk health checks, and overheating checks.
3. Booting itself fails, Windows cannot be entered, or the machine blue-screens during boot: if even Safe Mode or the recovery environment is unstable, there is little room left for software triage — prioritise preserving data, for example by backing up in the recovery environment, then send the machine for inspection.
4. Overheating signs: for example an abnormally hot chassis, a fan running at full speed for long periods, or blue screens that cluster under heavy load or gaming. Microsoft Q&A replies list overheating as a blue-screen triage direction, recommending good ventilation, dust removal, and temperature monitoring.
5. Memory Diagnostic reports errors, or the problem is memory-related: Windows Memory Diagnostic (mdsched.exe) is the check method suggested in Microsoft Q&A; if it reports RAM errors, the relevant module may need replacing, and that judgement should be confirmed by inspection.
6. Other abnormal hardware observations: for example unusual sounds from inside the machine, unusual hard-disk sounds, a burning smell at boot, abnormal heat in one part of the chassis, crashes that began after plugging or unplugging a particular external device, or crashes that began after a drop or water exposure. These observations alone cannot diagnose a fault, but when sending the machine for inspection, describe clearly when it began, what you were doing, and what accompanied it, so the inspection can target the right checks. This article stops at sending the machine for inspection and does not teach board-level repair at home; in particular, opening the machine yourself for a motherboard-level problem can make things worse or affect later inspection.
Before sending the machine in, prepare: the blue-screen stop code (a photo is best if you caught one), how often it happens, what you were doing each time (booting, gaming, plugging in USB, waking from sleep); what changed recently — updates, new software, new hardware, a drop or water exposure; which steps you have already tried and their results (for example which driver you rolled back, whether the clean boot still crashed, whether reinstalling still crashed); and whether you have a backup and whether the BitLocker key has been found — clarify data handling before handing the machine over.
Pricing notes
All repair work is quoted in writing after inspection. Confirmed routine prices:
| Item | Price |
|---|---|
| Battery | HK$580 up |
| Screen | HK$1,280 up |
| Main board chip-level | HK$880 up |
| Keyboard | HK$480 up |
| Other repairs | Quoted in writing after inspection |
FAQ
Q1: After a blue screen, what should I do first — reinstall straight away?
A1: No. First note the stop code, the time, and what changed just before the crash, then copy the .dmp files from C:\Windows\Minidump to another location for safekeeping, and back up important files to an external drive or the cloud. Microsoft Support warns that recovery options should be preceded by backup because some options can cause data loss; reinstalling is a later option, not the first step.
Q2: What is the difference between a Minidump and MEMORY.DMP, and which is most useful?
A2: Minidumps live by default in C:\Windows\Minidump, with a new file per crash that is never overwritten — ideal for comparing whether repeated crashes point at the same driver. MEMORY.DMP lives by default in C:\Windows\MEMORY.DMP, appears only after a genuine crash, and its complete or kernel form is overwritten on each new crash. When disk space is tight, keeping Minidumps is already enough for an initial comparison.
Q3: After enabling Driver Verifier, my machine blue-screens more easily. Did I enable it wrong?
A3: Not necessarily. Driver Verifier is a test tool that forces a faulty driver to reveal itself, not a repair tool, so it may blue-screen sooner — the point is to obtain the stop code and file name pointing at that driver. But Microsoft Learn warns explicitly that running Driver Verifier can crash the computer and that it should only be run on a computer used for testing and debugging. Once you find the culprit or finish triage, switch it off immediately with verifier /reset; if you cannot reach the normal desktop, run the same command in Safe Mode or WinRE.
Q4: The problem disappeared in a clean boot. Does that mean the machine is fixed?
A4: No. A clean boot is only a troubleshooting mode; a disappearance only means the culprit is among the disabled services or startup programs. Use the halving method — re-enable half at a time and test — until a single service or startup item is isolated. Afterwards you must restore normal startup; don't keep using the clean-boot state as normal operation, or restoration will easily miss items.
Need Professional Laptop Repair?
Laptop King has 15+ years of repair experience in Shek Mun, Sha Tin. Free diagnosis, transparent pricing, no fix no fee. 180-day warranty for your peace of mind.