Command Prompt Fixes for BSOD and Stubborn System Errors

Start With a Triage Mindset, Not a Command List

Every experienced technician eventually learns the same lesson: the command line is a diagnostic scalpel, not a magic wand. It can rebuild a boot configuration, restore a corrupted system file from a cached image, force a drive to reallocate weak sectors, and reset a network stack that a bad driver update flattened. What it cannot do is repair failing hardware, undo physical damage, or compensate for a disk that is quietly dying. If you run repairs on a dying drive, you may buy an afternoon of stability and lose the data anyway.

That distinction should shape everything you do. Before typing a single command, classify the problem into one of three buckets:

• Software corruption. A system file, registry hive, component store image, or boot record has been damaged, half-written by an interrupted update, or replaced by incompatible software. Command-line repair tools are excellent here.
• Configuration drift. Drivers, network bindings, startup entries, or power settings now conflict with each other. These usually respond well to resets and clean uninstalls.
• Hardware degradation. Memory errors, failing storage, thermal shutdowns, or power delivery problems. Commands may mask symptoms temporarily, but the failure returns, often at the worst possible moment.

A useful rule: if the same stop code appears twice within a week, stop treating it as a software problem until memory and storage have been tested. If a machine crashes under load but is stable at idle, suspect thermals or power before you suspect Windows.

Equally important is preparation. Boot into a working environment, copy anything irreplaceable to external storage, and note the exact stop code and timestamp of each crash. Repair work on a machine with no backup is not repair work, it is gambling. Once you have a backup, a notebook, and a hypothesis, the command line becomes genuinely powerful.

Turning BSOD Stop Codes Into a Working Hypothesis

The Blue Screen of Death gives you more information than most people realize. The headline is a friendly name such as KMODE_EXCEPTION_NOT_HANDLED, CRITICAL_PROCESS_DIED, IRQL_NOT_LESS_OR_EQUAL, WHEA_UNCORRECTABLE_ERROR, or PAGE_FAULT_IN_NONPAGED_AREA. Beneath it sits a hexadecimal code and often the name of the driver or module that was executing when the fault occurred. That module name is your first real clue.

A practical decoding approach:

• WHEA_UNCORRECTABLE_ERROR almost always points at hardware: CPU, memory, PCIe devices, or power delivery. Software repairs rarely help.
• PAGE_FAULT_IN_NONPAGED_AREA commonly involves memory or a driver touching memory it should not. Test RAM, then look at recent driver installs.
• CRITICAL_PROCESS_DIED often follows corrupted system files or a failed update. System File Checker and DISM are reasonable first moves.
• IRQL_NOT_LESS_OR_EQUAL is frequently a driver problem, especially networking, storage, or anti-cheat and virtualization components.
• KMODE_EXCEPTION_NOT_HANDLED is generic, so rely on the named module and the crash dump.

From an elevated Command Prompt you can gather context without third-party tools. wevtutil qe System /c:20 /rd:true /f:text prints the most recent system events in readable form, and filtering for bugcheck entries narrows things quickly. driverquery /v produces a verbose list of loaded drivers with their paths, which is useful when you suspect a recently added component. wmic remains available on many systems for quick inventory, and PowerShell gives you Get-WinEvent and Get-CimInstance for the same job with better filtering.

Write down four things for every crash: the stop code, the named module, what you were doing at the time, and whether it is reproducible. Patterns matter more than single events. A crash that happens only during video export points somewhere different from one that happens during idle overnight.

Getting to a Reliable Command Prompt

Half of failed repairs come from running the right command in the wrong environment. You need an elevated prompt with the right permissions, and ideally a recovery environment that is not depending on the broken installation.

Three levels of access are worth knowing:

• Elevated Command Prompt inside Windows. Search for Command Prompt, right-click, and choose Run as administrator. Best for DISM, CHKDSK scheduling, and network resets.
• Safe Mode with Command Prompt. Reached through Settings, Recovery, Advanced startup, or by holding Shift during restart. Useful when a driver or startup item prevents normal boot.
• Windows Recovery Environment (WinRE). Booted from installation media or the recovery partition. This is the environment for boot repair, offline SFC, and disk checks on the system volume.

In WinRE your drive letters may shift. Run diskpart, then list volume, and confirm which letter now holds the Windows folder before you touch anything. Running boot repair against the wrong volume is one of the fastest ways to turn a recoverable machine into a reinstall.

Also check whether BitLocker or another full-disk encryption layer is active. Many repair commands fail or refuse to run on a locked encrypted volume, and repeated failed boots can trigger a recovery key prompt. Have the recovery key available before you start, not after.

Finally, disable automatic restart on system failure so you can actually read the screen: wmic recoveros set AutoReboot = False. It is a one-line change that saves a lot of guesswork.

First Repair Pass: System File Checker

System File Checker compares protected Windows files against a cached copy and replaces anything that does not match. It is the fastest first pass for corruption caused by failed updates, abrupt power loss, or aggressive cleanup utilities.

The standard command is sfc /scannow. Run it elevated, let it finish, and read the result rather than assuming. There are three meaningful outcomes: no integrity violations found, violations found and successfully repaired, or violations found that could not be repaired. The third result is not a dead end, it is an instruction to repair the component store first with DISM and then run SFC again.

If Windows will not boot at all, use the offline form from WinRE, pointing SFC at the offline installation:

sfc /scannow /offbootdir=D: /offwindir=D:/Windows

Adjust the drive letter to match what diskpart reported, not what you remember from normal operation.

For deeper visibility, review the log at the Windows folder under Logs, CBS, CBS.log. It is verbose, but searching for the word corrupt reveals exactly which files failed and often why. A single corrupt font or driver package is a very different problem from dozens of corrupted system binaries; the latter suggests storage or memory trouble rather than a one-off bad update.

A few practical tips. Do not interrupt SFC even if progress appears stuck at a percentage for several minutes. Close heavy applications first. And if SFC reports clean but the crash persists, do not run it five more times, move to DISM and then to hardware testing, because you are looking at a symptom that SFC cannot see.

Second Repair Pass: DISM and the Component Store

Deployment Image Servicing and Management repairs the component store, the reservoir of files that System File Checker draws from. If that reservoir is damaged, SFC has nothing healthy to copy from, which is why repair order matters: component store first, then protected files.

The sequence that works reliably:

1. DISM /Online /Cleanup-Image /CheckHealth reports whether corruption has been flagged previously. It is instant and read-only.
2. DISM /Online /Cleanup-Image /ScanHealth performs a full scan and takes several minutes. This is the honest check.
3. DISM /Online /Cleanup-Image /RestoreHealth performs the actual repair, pulling replacement files from Windows Update by default.

If Windows Update is itself broken, which is common on machines that crash during updates, point DISM at local repair media instead: provide a source using an ISO or mounted image with the appropriate install image path. This offline approach requires matching build versions. Using a mismatched source will fail with an error about the source files being unavailable, which is a version problem, not a corruption problem.

After RestoreHealth reports a successful repair, immediately rerun sfc /scannow. A large share of stubborn corruption resolves in this exact pairing. In the WinRE environment, add the offline switches so DISM operates on the mounted installation rather than the recovery image.

One caution: DISM will not fix a failing disk. If RestoreHealth repeatedly finds corruption that reappears within days, stop looping and test the storage device. Repeated corruption on the same volume is one of the clearest early warnings of hardware failure.

Third Repair Pass: Disk Integrity With CHKDSK

File system damage produces a distinctive family of symptoms: an operating system that hangs at startup, folders that appear empty, files that cannot be deleted, or a boot that suddenly demands a volume scan. CHKDSK verifies and repairs the file system layer.

Useful forms:

• chkdsk C: /scan runs an online scan of the volume without forcing a reboot. Good for a first look.
• chkdsk C: /f fixes file system errors and usually requires exclusive access, so it prompts to schedule the check at the next restart.
• chkdsk C: /r locates bad sectors, recovers readable data, and implies /f. It takes a long time on large mechanical drives, sometimes hours.
• chkdsk C: /spotfix performs a targeted online repair of problems found by an earlier scan.

Before running anything heavy, check the drive's own health metrics. wmic diskdrive get model,status gives a basic status, and drive manufacturer utilities or SMART readers give the fuller picture: reallocated sectors, pending sectors, and uncorrectable errors. If those counters are climbing, the correct next step is replacing the drive and copying data off it, not scanning it repeatedly.

The most common mistake is interrupting CHKDSK. Pulling power mid-repair can leave the volume in a worse state than before you started. Second most common: assuming a clean CHKDSK result means the disk is healthy. It only means the file system structure is consistent right now. A drive with failing media can produce a clean result today and catastrophic loss next week.

Hardware Checks You Can Run From the Console

Because a large share of recurring crashes trace back to memory or storage, a repair workflow needs hardware verification built in rather than bolted on at the end.

For memory, mdsched launches the Windows Memory Diagnostic and offers to test on the next restart. It is convenient and requires no downloads. For serious diagnosis, a dedicated bootable memory tester that runs several full passes is more thorough, especially for intermittent faults that only appear under extended load. Run memory tests with a single module installed if you need to isolate which stick is faulty, then repeat with a different slot to rule out the motherboard.

For storage, gather a baseline before repairs. wmic diskdrive get model,serialnumber,size,status identifies the device, and vendor tools or SMART utilities reveal the counters that actually matter. If you see pending sectors or a growing reallocation count, every software fix in this guide is a temporary bandage.

Other console-accessible checks worth knowing: powercfg /energy produces a power efficiency report that can reveal thermal or power policy problems, and powercfg /batteryreport documents battery health on laptops, where an aging battery can cause shutdowns that look like system crashes. Temperature monitoring requires third-party utilities, but if a machine only fails during sustained work such as rendering or compiling, clean the cooling system and reapply thermal compound before chasing driver theories.

Treat hardware verification as a gate. Passing it justifies spending hours on software repair. Failing it justifies a parts order.

Boot Repair: MBR, BCD, and Startup Recovery

A machine that fails before the login screen has a different class of problem. The boot chain is layered: firmware, partition table, boot sector, boot configuration data, then the operating system loader. Break any layer and Windows reports a missing operating system, a boot device error, or an automatic repair loop.

From WinRE, bootrec is the traditional toolkit:

• bootrec /fixmbr writes a standard master boot record. It is non-destructive to partitions.
• bootrec /fixboot writes a new boot sector. It can fail with an access denied message on modern UEFI systems, which is usually a firmware mode mismatch rather than a dead disk.
• bootrec /scanos searches all volumes for Windows installations.
• bootrec /rebuildbcd rebuilds the boot configuration data and lists installations it can add.

If rebuildbcd finds no installations despite a healthy Windows folder, the boot entries must be created manually with bcdboot, pointing at the Windows folder and the system partition. Confirm the partition layout first with diskpart, because an EFI system partition is formatted FAT32 and typically a few hundred megabytes, while the main partition is NTFS and much larger. Writing an EFI boot entry to the wrong partition is a common cause of the infamous boot loop.

Also verify firmware settings before assuming software damage. A BIOS or UEFI update that switches between legacy and UEFI boot modes, or a failed CMOS battery, will produce boot errors that no command can fix. Cheap to check, easy to overlook.

Network, DNS, and Driver Stack Resets

A surprising number of stop codes trace back to network and driver components, because those are the pieces most frequently updated and least frequently tested against each other. Resetting the stack is fast, reversible, and worth doing whenever a crash involves networking drivers or when connectivity breaks after updating.

An elevated prompt, in order:

1. netsh winsock reset restores the socket layer to a default state.
2. netsh int ip reset rewrites TCP/IP registry entries.
3. ipconfig /flushdns empties the resolver cache.
4. ipconfig /release then ipconfig /renew refreshes addressing.
5. netsh int ip reset resetlog.txt writes a log you can review if something goes wrong.

Restart after completing the sequence, since winsock changes only take effect on a new session.

For drivers, the console helps you identify rather than install. driverquery /v lists loaded drivers, versions, and paths. pnputil /enum-drivers shows third-party driver packages you have added. Removing a suspect package with pnputil /delete-driver and letting Windows reinstall a known-good version is often cleaner than fighting a vendor installer.

If a crash started immediately after a specific update, roll it back rather than repairing around it. wmic qfe list brief shows installed updates with identifiers and dates, which makes it easy to correlate the timeline. Sometimes the smallest change is the fix: remove the offending update, block it temporarily, and let the vendor ship a corrected version.

Mistakes, Escalation Criteria, and FAQ

Common mistakes that make things worse

• Running repairs without a backup. Always the first error. Copy data before you touch the system volume.
• Interrupting long operations. SFC, DISM, and CHKDSK should never be stopped mid-run.
• Repairing in the wrong order. Component store first, then protected files, then disk, then boot.
• Using the wrong drive letters in recovery. Always confirm with diskpart.
• Ignoring the pattern. If corruption returns within days, you are treating hardware failure as software.
• Applying every fix at once. Change one variable, test, then move on. Otherwise you never learn what worked.

Escalation criteria

The decision to stop repairing and start replacing is not a judgment call, it follows from evidence. Escalate when: SMART counters show pending or reallocated sectors; memory tests fail on any pass; the same corruption returns after a clean component store repair; the machine crashes during firmware or recovery operations; or data loss has already occurred once.

A practical escalation ladder looks like this. Software repair on the running system. Offline repair in the recovery environment. Hardware verification. Part replacement, starting with the cheapest suspect, usually memory, then storage, then power supply. Clean reinstall once hardware is proven good. In many cases a reinstall is faster and more reliable than a fifth round of repairs on a system with an unknown history.

Frequently asked questions

How long should System File Checker take? Anywhere from five to twenty minutes depending on storage speed and system state. Long pauses at a single percentage are normal. If it runs for an hour without progress, the disk itself is suspect.

Is CHKDSK safe for solid state drives? The online scan and spot-fix options are fine. The full surface scan is largely pointless on an SSD because bad blocks are managed internally by the controller, which is another reason to read SMART data instead.

Can command-line repairs fix a crash that only happens in games? Sometimes. Anti-cheat drivers, GPU drivers, and overclocking settings are the usual suspects. Reset the stack, clean-install the graphics driver, remove overclocks, then test.

What if DISM fails with a source error? You are almost certainly using mismatched repair media or an offline image from a different build. Match the version exactly, or let DISM pull from the update service on a working network connection.

Do these repairs delete personal files? SFC, DISM, and network resets do not. CHKDSK with repair options can move data into found-file directories if the file system was badly damaged, and boot configuration changes can affect multiple installations. Back up first.

Is a clean install the better answer? When hardware is proven healthy and the system has years of accumulated driver and software changes, a clean install often resolves issues that hours of repair cannot. Keep it as a legitimate option, not a last resort you resist out of pride.

Command-line repair is ultimately about disciplined observation: read the failure, form a hypothesis, test the cheapest explanation first, and stop when the evidence points to hardware. Do that consistently and the Blue Screen stops being a mystery and becomes a checklist.