Shared Windows repair guidance

A similar error code is a starting clue. Match the symptom, trigger, affected component, and proposed action to the Issue and Resolution steps of the guide you are using.

Confirm that the action targets the actual device, driver, update, account, disk, partition, or setting on your computer. A missing model, build, or package version must be resolved whenever it determines the repair branch.

The general guidance here does not supply a missing diagnosis or authorize an additional repair. Continue only with the branch whose prerequisites you can establish.

Use a different diagnostic path when the named component, trigger, boot stage, or demonstrated cause differs. One shared stop code does not establish the same cause.

Firmware changes, storage-controller changes, partition operations, driver removal, Reset, and reinstallation require a matching diagnosis and a recovery plan. RAID or SCSI instructions apply only to systems that actually use that configuration.

A source discussion can document a successful recovery without proving the original cause or establishing that the result applies to other computers.

Record the exact target, its current value or version, why it matches the selected repair, the available backup or rollback, and the condition that will stop the procedure. Resolve missing model, build, package, disk, or partition information before it is used to choose an action.

A report from one configuration is evidence about that configuration. Source-reported outcomes are not independent TechXplored laboratory tests.

Confirm the exact symptom, trigger, and affected item against the selected Resolution steps. An error code by itself does not establish the cause. Collect the missing logs, device identity, disk layout, or version information when it determines the action.

Use only the matching operation topic below. Driver evidence belongs to a driver change; SetupDiag and Panther/Rollback logs belong to a feature-upgrade investigation; disk and BCD inspection belongs to a boot repair. A recent update does not make every subsequent application or network failure an upgrade failure.

For hardware isolation, change one variable at a time and establish whether the fault follows the suspected component in a known-good configuration. For Reset or reinstallation, first establish why less destructive repairs do not apply or have failed.

When the source omits information needed to confirm the diagnosis, stop and resolve that gap. The shared reference does not fill it in by inference.

1. Record the exact message, error code, time of failure, and the change that preceded it.
2. Back up accessible personal files to separate storage and confirm that the backup can be read. Recovery media and a restore point do not replace a backup of personal files.
3. Record the original setting, package, connection, and configuration that the selected repair will change.
4. Make one material change at a time and keep the evidence needed to reverse it.
5. Arrange administrator access or Windows Recovery Environment only when the selected procedure needs it. Keep recovery media or another working device available if the PC may not restart.

Use only the preparation topic that matches the actual Resolution steps. The driver, update, hardware, firmware, boot, and reinstall notes below are conditional references; they are not a checklist of repairs to try.

Use stable power for firmware, storage, update, and installation work. If Windows will not start, use a trusted recovery environment to back up accessible files without changing partitions. Unlock an encrypted volume only with its matching recovery key; stop if the required data cannot be accessed safely.

If storage becomes intermittent or copying fails repeatedly, stop repair writes and protect the data before continuing.

Microsoft: choose a backup solution · Microsoft: recovery options

Use this checklist for the application, service, device, account, or setting named by the selected Resolution steps. Preserve the original value, package, connection, or restore point required to undo that action.

1. Record the current application, service, device, account, and Windows state before changing it.
2. Apply the demonstrated action to the exact affected item; do not change adjacent settings or unrelated packages.
3. Restart when the action changes a driver, service, update, system file, or startup component.
4. Repeat the exact operation that failed and compare the result with the recorded before-state.

Use this checklist only when the selected Resolution steps require changing the identified driver. Have a usable rollback path before removal. Record its name, hardware ID, provider, version, date, status, and published INF. Obtain the correct replacement or previous package for the exact computer or device model.

1. Download the exact-model OEM driver or the previously working package before removing anything. Extract it locally when the installer is an archive.
2. Open Device Manager, open the affected device’s Properties, and record the Driver tab plus Details > Hardware Ids.
3. When the failure began after an update and Roll Back Driver is available, use that reversible option first and restart.
4. Otherwise uninstall only the identified device or vendor package. Keep the existing Driver Store package unless the evidence shows that package is reinstalling the fault and a replacement is ready.
5. Install the prepared package, restart, confirm the expected provider/version, and repeat the exact failing operation.

Do not remove every driver from one manufacturer or use an unaffiliated driver-download utility. If the change worsens operation, use the recorded previous OEM package or Device Manager Roll Back Driver when available.

Microsoft: update, reinstall, or roll back a driver

Use this checklist only for a Windows update or feature-upgrade repair. Update removal applies only when the selected branch calls for removing that exact update.

1. Record the complete error/result code, KB or target release, percentage, Setup phase, and operation before clearing caches or retrying.
2. Preserve Windows Update history and, for feature upgrades, copy the Panther and Rollback logs and retain the SetupDiag result.
3. If the demonstrated action is rollback, use Settings > Windows Update > Update history > Uninstall updates, or WinRE > Troubleshoot > Advanced options > Uninstall Updates when Windows will not start.
4. If the action changes a blocker, remove or update only the named driver, application, profile, device, or package.
5. Restart and attempt the same update once. If it fails, preserve the new logs before making another change.

Do not repeatedly retry an upgrade while overwriting the previous failure logs. Stop if the specified package cannot be removed or the failure no longer matches the selected branch. Preserve new logs before trying another action. After update removal, reinstall only when Windows is stable and a corrected package or driver is available.

Use this checklist only when the selected branch requires physical hardware work. Follow the exact device manufacturer's disassembly and power-isolation instructions. Have a known-good comparison component or a repeatable isolation test; do not infer failed hardware or purchase a part from one stop code.

1. Shut down, remove power, and use appropriate antistatic precautions before disconnecting internal hardware.
2. Record the original slot, cable, port, and firmware configuration. Test one component or connection at a time.
3. Use a known-good component, another known-good system, or a repeatable vendor diagnostic to determine whether the fault follows the suspected part.
4. Replace or RMA the component only after the isolation test follows it. Reassemble the minimum working configuration first.
5. Repeat the original workload, restart sequence, or Setup attempt before reconnecting the remaining devices.

Return an original component only when it is known safe. Otherwise leave it disconnected and restore the last stable configuration. Stop repair attempts if storage becomes unstable or the proposed test would endanger the only readable copy of important files.

A firmware-setting change and a firmware flash are different operations. Perform only the operation identified by the matching guide.

1. Identify the exact computer or motherboard model and hardware revision from the chassis label or current firmware screen.
2. Photograph every relevant firmware page and the current boot order. Download only the exact-model vendor instructions and recovery file.
3. Connect stable AC power. If the repair changes one setting, change only that setting; if it flashes firmware, follow the vendor’s required intermediate-version order.
4. Save, restart, and allow any memory training or firmware recovery cycle to finish without interrupting power.
5. Return to firmware setup, verify the intended value and Windows Boot Manager entry, then test Windows startup.

Do not flash firmware for a similar model, interrupt a flash, or change storage-controller mode without a tested rollback path. Stop when the exact model, hardware revision, target setting, firmware file, or recovery path is uncertain. Restore only the recorded setting or use the exact-model vendor recovery procedure.

Identify the exact boot target before modifying it. Have Windows installation or recovery media and a written record of the current disk, volume, and BCD layout. BCDEdit /export and /import operate on the system store; they are not a backup and restore method for an arbitrary offline store. Preserve an offline store with an appropriate file or image backup instead.

1. Start Windows Recovery Environment from the installed recovery options or matching Windows installation media, then open Troubleshoot > Advanced options > Command Prompt.
2. Run diskpart, list disk, and list volume. Record the output and run exit. Do not assume Windows is C: in recovery.
3. Locate Windows by testing the likely letters with dir C:\Windows, dir D:\Windows, and so on. Continue only after the actual Windows directory is visible.
4. Detect whether the machine has a FAT32 EFI System Partition or a legacy active system partition. Use only the matching branch.
5. If the BCD store is accessible, export or image it before changing boot files. Then perform only the demonstrated Bootrec, BCDBoot, or entry correction.

Do not format, clean, convert, mark active, or assign an EFI role to a partition merely because a boot command failed. Restore the appropriate recorded BCD or image backup if the change worsens boot selection.

Microsoft: BCDEdit store, export, and import behavior

Verify a separate backup and the exact target before recovery. Reset with Keep my files still removes apps and settings. A clean installation can remove files, apps, settings, and partitions; an automatic rollback must not be assumed.

1. Copy personal files to verified external storage and record installed applications, activation state, accounts, and required OEM drivers.
2. Create current official Windows installation media on another working PC when the built-in recovery image is damaged or unavailable.
3. Disconnect nonessential drives so the recovery operation cannot place boot files on or erase the wrong disk.
4. For Reset, choose Keep my files only if that outcome is acceptable; applications and settings are still removed. For a clean installation, verify the exact target disk before deleting any partition.
5. Complete Setup, install the exact-model chipset/storage/network drivers, restore files, and classify the result as recovery—not proof of the original cause.

Microsoft: compare recovery options and their effects

Do not combine unrelated fixes in one attempt. Change one material variable and retest. Never guess a partition layout, device identity, firmware value, or package.

Do not disable BitLocker, Secure Boot, Defender, Windows Firewall, or storage-controller features as generic experiments. Do not use registry cleaners, generic driver updaters, or commands copied for a different partition layout.

Do not describe Reset, factory recovery, or a clean installation as nondestructive. Keep my files still removes applications and settings. A reinstall, recovery operation, or hardware replacement can restore operation without proving a component-level cause.

Read the warnings in the operation topic matching the actual Resolution steps before proceeding. They do not authorize additional actions.

• If the exact original symptom stops after one controlled change, preserve the before-and-after evidence and perform the guide's verification.
• If operation is restored but the cause remains unknown, record a successful recovery without claiming a proven root cause.
• If a new symptom or code appears, stop and treat it as a new diagnostic state.
• If the change has no effect, use the documented rollback when available and reassess the diagnosis.
• If the disk disappears, hardware becomes unstable, or recovery stops working, stop repair attempts and protect the data.

Before changing anything, record the exact setting, package, driver, connection, boot store, or firmware value that would need restoration. Confirm that the required backup, previous package, recovery media, or restore point actually exists and can be used.

Use only the rollback that matches the selected action and its operation topic above. Restore recorded settings or known-safe components; reconnect devices or re-enable services one at a time and retest.

A clean installation may have no automatic rollback. If the action was destructive, recovery depends on a verified file backup or complete system image. A restore point does not replace a personal-file backup. Stop when the required recovery material is unavailable.

Repeat the operation that originally failed and check the success condition stated in the selected Resolution steps. A different error is not a successful repair.

When appropriate for a stable system, confirm startup across repeated restarts and a shutdown/start cycle. Test the affected application's or device's actual operation, rather than relying only on the absence of one message.

Record the final build, package or driver version, and changed setting. Retain relevant logs and backups until normal use confirms that the result holds.

A successful source report does not provide a measured success rate for your computer. Unless an article supplies a documented measurement, a confidence label is not a tested probability or guarantee.

Stop when the exact target cannot be identified, a required backup or rollback is missing, a partition or firmware value would have to be guessed, the system becomes less stable, or the result cannot be repeated.

Keep the scope of a single-source report limited to its demonstrated configuration. Independent reproduction and a proven causal mechanism are separate claims and must be supported separately.