Recover an Automatic Repair loop caused by disk or file-system errors

Windows repeatedly enters Preparing Automatic Repair, Diagnosing your PC, or Automatic Repair couldn't repair your PC, and independent evidence points to storage I/O or file-system corruption. The important decision is whether the failure is limited to repairable NTFS metadata on a stable device or whether the HDD, SSD, cable, connector, slot, controller path, or power path is unreliable.

This procedure applies to both HDDs and SSDs. A SATA controller or cable path can affect either. CHKDSK repairs a volume's file-system metadata; it does not repair a failing drive, cable, connector, controller, or NAND/platter media. A drive reporting Healthy through one Windows interface is not automatically healthy, and an Event 129 path containing \Device\RaidPort... does not prove that the consumer computer has a RAID array.

Searchable Windows error codes and exact messages

Automatic Repair has no dedicated storage error code. Search the exact screen text together with the separately displayed code, stop name, CHKDSK result, event source/ID, device model, or SrtTrail.txt line.

Relevant System-log events are searchable only when the provider, disk number, device path, and timestamp match the Windows disk:

CHKDSK itself returns searchable command exit codes: 0 means no errors were found; 1 means errors were found and fixed; 2 means cleanup was performed or was not performed because /f was omitted; and 3 means the disk could not be checked, errors could not be fixed, or errors were left unfixed because /f was omitted. Also record exact text such as The type of the file system is RAW. CHKDSK is not available for RAW drives or Cannot open volume for direct access. Neither message authorizes formatting.

Use this procedure when Windows 10 or Windows 11 is in a repeatable Automatic Repair loop and at least one independent storage/file-system signal applies to the verified Windows disk:

• read-only CHKDSK reports NTFS metadata errors;
• the Windows volume appears RAW or cannot be read consistently;
• Windows displays an I/O, CRC, corrupt-disk, or corrupt-file status listed above;
• a time-correlated System-log event maps to the Windows disk;
• the disk disappears, resets, freezes during reads, or changes detection state; or
• the manufacturer diagnostic reports a storage failure code.

The procedure is intentionally storage-first. It determines whether a repair write is defensible before running chkdsk /f.

Do not use this as a generic Automatic Repair checklist when CHKDSK is clean, the storage device is stable, and the evidence instead identifies an update, driver, service, BCD object, registry hive, Secure Boot policy, or boot file. Use the corresponding focused writeup.

Do not use it as the primary fix for a controller mode that was just changed, an absent firmware boot entry, a deleted system partition, a locked volume, a recovery USB that is itself corrupt, or an installation that has not been identified. BitLocker is assumed unlocked for this project.

If the disk is not detected consistently, this becomes data recovery and hardware diagnosis, not a CHKDSK exercise.

The exact Windows build, whether the device is marketed as an SSD or HDD, and the event that first damaged the file system may remain unknown during initial triage. Media type affects scan duration and follow-up health tests, not whether logical errors should be repaired on an unstable source.

The following may not remain unknown before a repair write:

• the verified Windows volume and physical disk number/model;
• whether the disk stays detected and readable;
• whether important data has a verified backup or image;
• the exact CHKDSK read-only result and exit code;
• whether errors are logical metadata errors or I/O/read failures;
• whether logged events actually map to the Windows disk; and
• whether the manufacturer diagnostic passed, failed, or could not access the device.

• Windows Recovery Environment or current Windows 10/11 installation media
• Stable AC power
• Administrative Command Prompt
• A healthy external disk or USB volume for evidence and critical-file copies
• Enough healthy destination capacity for a full image or clone when failure is suspected
• A verified backup before chkdsk /f, chkdsk /r, SFC repair, restore, reset, or reinstallation
• Access to the computer or drive manufacturer's preboot/storage diagnostic when available
• A replacement drive and restore path when diagnostics fail
• A data-recovery specialist when the data is irreplaceable and the drive is mechanically noisy, intermittently absent, or returning increasing read errors

For an ordinary SATA HDD or SSD, connection checks focus on the same data and power path. NVMe devices use a slot rather than a SATA cable. RAID, SCSI, SAN, and VMD/IRST configurations remain valid catalog branches but are not the consumer-first path here; use the hardware/controller vendor's health view when Windows exposes only a virtual disk.

Stop the restart loop and do not run Startup Repair repeatedly. From Advanced options, open Command Prompt. If Advanced options never appears, boot current installation media and select Repair your computer.

Disconnect unrelated external storage after WinRE has started. Keep only the recovery medium and the deliberately selected healthy evidence/backup destination. Do not change storage-controller mode, update firmware, initialize a disk, format a RAW volume, recreate partitions, or run a write-mode diagnostic before preserving needed data.

Treat HDD and SSD evidence the same at this stage: repeated timeouts, CRC failures, bad blocks, disappearances, or uncorrected read errors make the source unsafe for routine repair writes.

1. Photograph the complete Automatic Repair screen and every displayed code. Record the last successful boot, whether the failure followed a hard power loss or freeze, and how many repair attempts have run.

2. Open DiskPart and identify the Windows volume and physical disk without changing either:

   diskpart
   list disk
   list volume
   select volume <Windows-volume-number>
   detail volume
   

3. If W: is unused, assign it and verify the result:

   assign letter=W
   detail volume
   select disk <Windows-disk-number>
   detail disk
   exit
   

   Record the disk number, model when displayed, size, status, read-only state, volume file system, and whether the same disk remains present throughout the session. Stop if the assignment or read fails repeatedly.

4. Verify the installation only when the file system is readable:

   dir W:\Windows\System32\Config\SYSTEM
   dir W:\Windows\System32\LogFiles\Srt\SrtTrail.txt
   

   If the volume is RAW or the directory read returns an I/O/CRC error, do not format it and do not run SFC. Use the unstable/RAW branch.

5. Detect the healthy evidence volume and assign U: only after confirming that letter is unused:

   diskpart
   list volume
   select volume <evidence-USB-volume-number>
   detail volume
   assign letter=U
   detail volume
   exit
   

   Verify that U: is the intended healthy destination:

   dir U:\
   md U:\BP020-Evidence
   

6. If the Windows disk is stable enough for ordinary reads, preserve logs before another repair attempt changes them:

   copy W:\Windows\System32\LogFiles\Srt\SrtTrail.txt U:\BP020-Evidence\SrtTrail-before-disk-repair.txt
   copy W:\Windows\System32\winevt\Logs\System.evtx U:\BP020-Evidence\System-before-disk-repair.evtx
   

   If either copy freezes, slows abnormally, or returns an I/O/CRC error, stop. Do not keep rereading the same failing area merely to collect logs.

7. Display the Startup Repair report when readable:

   type W:\Windows\System32\LogFiles\Srt\SrtTrail.txt | more
   

   Record any disk test, volume test, file-system test, named file, and root-cause line. Treat it as a lead, not proof.

8. Run CHKDSK once without a repair switch only when the disk is consistently detected and ordinary directory/log reads complete normally. If the disk clicks or scrapes, disappears, resets, freezes during a read, or has already returned a recurring I/O/CRC failure, skip CHKDSK and go directly to Branch A:

   chkdsk W:
   echo CHKDSK exit code: %errorlevel%
   

   Interpret the result:

   • A clean result with exit code 0 weakens the file-system-corruption diagnosis but does not rule out intermittent hardware.
   • Index, security-descriptor, bitmap, MFT, or free-space errors with stable reads support the logical-corruption branch.
   • Bad clusters, unreadable segments, CRC/I/O errors, resets, a hang, exit code 3, or changing errors support the unstable-device/path branch.
   • CHKDSK is not available for RAW drives means CHKDSK cannot interpret the file system. Do not answer it with /f, /r, formatting, or partition creation.

9. Query the offline System log for relevant event IDs when wevtutil can read it. This command writes only to the healthy evidence volume:

   wevtutil qe W:\Windows\System32\winevt\Logs\System.evtx /lf:true /q:"*[System[(EventID=7 or EventID=51 or EventID=55 or EventID=98 or EventID=129 or EventID=153 or EventID=157)]]" /f:text > U:\BP020-Evidence\storage-events.txt
   

   Open the saved text and verify provider, timestamp, device path, and disk number. Ignore an event that belongs to the recovery USB, optical drive, unrelated data disk, or a different time period.

10. Run the computer manufacturer's short preboot storage diagnostic once, if available. Record the exact disk model/serial, test name, result, and failure/validation code. Do not begin a long destructive or write-mode test. A failed short test, a disk that the test cannot see, or changing detection is enough to enter the hardware-risk branch.

11. If Windows or Safe Mode can be started once and the Storage PowerShell module exposes the physical disk, record its view from elevated PowerShell:

    Get-PhysicalDisk | Format-Table FriendlyName,SerialNumber,MediaType,HealthStatus,OperationalStatus,Size -Auto
    Get-PhysicalDisk | Get-StorageReliabilityCounter | Format-List DeviceId,Temperature,PowerOnHours,Wear,ReadErrorsTotal,ReadErrorsUncorrected,WriteErrorsTotal,WriteErrorsUncorrected
    

    Unsupported or blank counters are not a pass. HealthStatus = Healthy is one signal, not proof, especially when events or diagnostics disagree.

12. Classify the evidence before repairing:

    Hardware/path risk is established when the disk disappears, a manufacturer diagnostic fails, an internal disk produces Event 157, uncorrected errors increase, Event 7 maps to the OS disk, I/O/CRC statuses recur, or CHKDSK cannot complete because reads fail.

    Logical NTFS corruption on a reasonably stable device is established when the disk is consistently detected, the short diagnostic passes, no time-correlated path resets or read failures appear, and read-only CHKDSK reports repeatable metadata errors after an abrupt power loss or interrupted write.

    The cause remains unproven when only SrtTrail.txt or Automatic Repair couldn't repair your PC is present and storage checks are otherwise clean. Use the general Automatic Repair/SrtTrail decision path instead of forcing a disk repair.

Branch A — The disk or connection path is unstable, failing, RAW, or returning I/O errors

1. Stop Startup Repair, CHKDSK repair, SFC, DISM, System Restore, reset, and reinstall attempts. Each adds reads or writes without repairing the underlying path.

2. If the data is irreplaceable and no current backup exists, shut the computer down. A clicking/scraping HDD, an SSD or HDD that repeatedly disappears, or rapidly increasing read failures should go to a qualified data-recovery specialist before another boot.

3. If the device is a serviceable desktop with ordinary SATA cabling, and the data is already protected, a qualified person can power off, disconnect AC, use antistatic precautions, and inspect/reseat or replace the SATA data cable and check the power connector. This applies to SATA HDDs and SATA SSDs. Do not open a sealed drive, repeatedly power-cycle a failing disk, or open a device whose service/warranty procedure forbids it.

4. For an NVMe device, use the computer manufacturer's service procedure for its slot, heatsink, retaining screw, and firmware. Do not repeatedly remove it or assume that a slot reseat repairs worn flash media.

5. After one connection correction, confirm that firmware and the short diagnostic see the same model and capacity. If the disk remains absent, resets, or fails the diagnostic, replace the device/path rather than running CHKDSK.

6. Create a sector-aware image or clone before logical repair when the disk can still be read:

   • Use a healthy destination at least as large as the source or a raw-image container with adequate space.
   • Identify source and destination by model, serial number, and capacity; never by a guessed drive letter.
   • Keep the failing source read-only when the imaging environment permits it.
   • Make the first pass favor readable areas with minimal retries, while saving a resume/map log.
   • Attempt bounded retries only after the first pass has captured the readily readable data.
   • Save the imaging log and a hash when the tool supports it.
   • Perform CHKDSK and file recovery on the clone or a copy of the image, not on the only failing source.

7. If imaging cannot progress or the data value exceeds the acceptable risk, stop and escalate. Do not “prepare” the source by initializing, formatting, converting, trimming, secure-erasing, or running chkdsk /r.

8. Replace a disk that fails diagnostics, reports uncorrected errors, repeatedly disappears, or continues to reset after a proven connection correction. Restore the verified image/backup to the healthy replacement, then repair boot files only if the restored layout requires it.

9. On the clone or restored replacement, continue with Branch B for demonstrated logical errors. Keep the original source unchanged until files and bootability have been verified.

Branch B — The device is stable and read-only CHKDSK demonstrates logical NTFS errors

1. Confirm that critical data or a full image is verified. CHKDSK changes file-system metadata and has no per-change undo.

2. Reconfirm that W: is the offline Windows volume and that no I/O, CRC, disappearance, or hardware diagnostic failure occurred.

3. Run one corrective metadata pass:

   chkdsk W: /f
   echo CHKDSK exit code: %errorlevel%
   

4. Allow it to complete. Record every correction and the final summary. Do not force a shutdown merely because progress pauses during a large index or security-descriptor stage.

5. Run one read-only verification pass:

   chkdsk W:
   echo CHKDSK verification exit code: %errorlevel%
   

6. Interpret the verification:

   • If it is clean, continue.
   • If the same metadata errors immediately return, stop and reassess hardware, RAM, filter drivers, and the image/backup.
   • If new I/O or unreadable-sector errors appear, move to Branch A and do not run /f again.

7. After the file system is clean and stable, verify protected Windows files offline:

   sfc /scannow /offbootdir=W:\ /offwindir=W:\Windows
   

8. Record SFC's exact result. If SFC cannot perform the requested operation or cannot repair files, preserve W:\Windows\Logs\CBS\CBS.log and use the system-file/component-store procedure with a compatible source. Do not copy individual files from an arbitrary computer.

9. Before restarting, remove only the W: and U: letters that this procedure assigned temporarily. Reidentify each volume by its recorded number and detail volume; do not remove a pre-existing letter:

   diskpart
   list volume
   select volume <Windows-volume-number>
   detail volume
   remove letter=W
   select volume <evidence-USB-volume-number>
   detail volume
   remove letter=U
   exit
   

10. Restart once with recovery media removed. If Automatic Repair returns, photograph the new screen and compare its code/log with the preserved evidence. Do not disable Automatic Repair to hide the loop.

11. If Windows starts, open an elevated Command Prompt, confirm echo %SystemDrive%, and run an online NTFS scan against that detected live Windows volume:

    chkdsk %SystemDrive% /scan
    

    Then run elevated sfc /scannow and review the System log for new Disk, Ntfs, storage-miniport, or Storport events.

Branch C — A surface read is justified after imaging

1. Do not make /r the first repair. /r locates bad sectors, tries to recover readable data, and includes /f; it reads far more of the volume than a metadata repair.

2. Prefer running it on the clone or restored replacement:

   chkdsk <clone-volume-letter>: /r
   

3. Use it on the original only when all needed data has a verified backup/image, the device is stable, the consequence of further failure is accepted, and a physical-read assessment is specifically required.

4. Run one pass and save the complete result. On an HDD it can take many hours because every sector must be read. On an SSD it can be faster, but it still reads every cluster and is not a substitute for controller/flash health diagnostics. Repeated /r scans are not a maintenance practice for either medium.

5. If bad clusters, unreadable data, I/O errors, or resets appear, retire/replace the source device. A CHKDSK report that moved data away from a bad cluster does not repair the physical medium.

Branch D — Storage and file-system evidence do not verify

1. Make no CHKDSK repair write.

2. Use the preserved SrtTrail.txt and displayed code to select the update, driver, BCD, registry, file-integrity, Secure Boot, or other startup branch.

3. If no branch verifies, use System Restore or the general Automatic Repair procedure before considering reset/reinstall.

Before leaving Branch A, C, D, or any early stop path, remove only drive letters assigned temporarily by this procedure after reidentifying their recorded volumes. Do not remove letters that existed before WinRE or make any partition-layout change.

Branch E — Specialist RAID, SCSI, SAN, VMD, or controller abstraction is actually present

1. Keep this branch secondary to the consumer paths above.

2. Map the Windows volume to the virtual/physical device using the controller or computer manufacturer's supported management and preboot diagnostic.

3. Preserve array/controller configuration and health logs before changing a driver, firmware, member disk, cache policy, or mode.

4. Do not infer a RAID array solely from \Device\RaidPort... in Event 129. Do not switch controller mode to make a disk appear.

5. If the abstraction cannot expose the failing member or path safely, escalate to the hardware/controller vendor before CHKDSK writes to the virtual volume.

• chkdsk /f repairs logical errors, the verification pass is clean, and Windows starts: The practical resolution is successful. Continue monitoring because the original cause can still be power loss or emerging hardware.
• Errors immediately recur after a clean repair: Logical corruption is a symptom, not the resolved cause. Investigate the device/path, RAM, and storage filters; do not schedule repeated CHKDSK runs.
• The disk disappears, resets, or fails the short diagnostic: Replace/recover the hardware path. No Windows boot command can make an intermittently absent disk reliable.
• The volume is RAW: Preserve/image it and recover from the copy. Do not format it as a troubleshooting step.
• 0x000000ed remains: Use the dedicated UNMOUNTABLE_BOOT_VOLUME branch after storage risk is addressed.
• 0x0000007b began after a controller-mode change: Restore the documented prior mode or follow the controller-mode writeup; file-system repair is not the primary fix.
• CHKDSK is clean and events do not map to the OS disk: Return to the general Automatic Repair/SrtTrail decision path.
• The replacement/clone boots but the original does not: Keep the original offline until data and image integrity are verified. Do not reuse it as a boot drive.

• Do not initialize, format, convert, repartition, secure-erase, sanitize, or trim a RAW or failing source as a “repair.”
• Do not run chkdsk /f or /r before protecting important data when hardware failure is possible.
• Do not repeat /r on either an HDD or SSD.
• Do not run Startup Repair in an endless loop or disable Automatic Repair to hide the symptom.
• Do not run BCD repair, SFC, DISM, registry replacement, update rollback, and CHKDSK in one undifferentiated sequence.
• Do not declare a disk healthy from one green SMART/PowerShell status when I/O events, uncorrected errors, or manufacturer diagnostics disagree.
• Do not interpret Event 129's RaidPort text as proof that RAID is configured.
• Do not change AHCI/RAID/VMD/legacy controller mode while diagnosing a file-system loop.
• Do not reinstall Windows onto a disk that is failing diagnostics or disappearing.
• Do not copy a random ntfs.sys, boot file, or registry hive from another computer.
• Do not open a sealed HDD or repeatedly power-cycle a mechanically failing drive.

Read-only CHKDSK and evidence collection need no rollback. chkdsk /f, chkdsk /r, and SFC make changes that do not have a reliable per-file or per-record undo. The verified pre-repair image or clone is the rollback.

If a cable, connector, or slot change worsens detection, power down and return only that documented hardware change to its original state, unless the original part is physically damaged. Preserve both the original and replacement part information.

When repair is performed on a clone, keep the original source offline and unchanged. If the clone's file-system repair loses needed files, discard that working copy and create another copy from the preserved image; do not experiment further on the original.

System Restore can reverse supported system-file, driver, registry, and application state. It does not restore arbitrary file-system metadata changed by CHKDSK and is not the rollback for a failing disk.

• Windows starts normally three times and completes one full shutdown/cold start without Automatic Repair.
• A read-only chkdsk reports a clean Windows volume; from running Windows, chkdsk %SystemDrive% /scan reports no remaining NTFS problem.
• SFC reports no integrity violations or documents the exact repaired files.
• The Windows disk remains visible with the same model, serial, size, and partition layout.
• The manufacturer's short storage diagnostic passes on the retained device. A pass supplements, but does not replace, the other checks.
• No new time-correlated Disk 7, 51, 153, or 157; Ntfs 55 or 98; or storage-path 129 event appears for the Windows disk during the verification boots.
• No new 0xc00000e9, 0xc0000185, 0x8007045d, 0x80070017, 0x00000024, 0x0000007a, 0x0000007b, or 0x000000ed occurs.
• A large, noncritical file can be read and copied without CRC/I/O errors after the system is stable; do not use an irreplaceable file as a stress test.
• The backup or image can be opened and a sample of critical files can be restored.
• If a drive was replaced, the original remains offline until the replacement and restored data are verified.

Attribution confidence is approximately 85% when two independent signals agree—for example, CHKDSK metadata errors plus Ntfs Event 55 on a consistently detected disk, or recurring I/O statuses plus a failed manufacturer diagnostic. Confidence that the fault is limited to logical NTFS corruption is approximately 75–80% when the device is stable, diagnostics pass, no path/reset events recur, and one chkdsk /f pass produces a clean, durable result. A dirty bit, one SrtTrail line, or one unrelated removable-media event alone is below the intended threshold.

Stop immediately when the disk disappears, becomes RAW unexpectedly, clicks or scrapes, a copy/read freezes, uncorrected errors increase, the short diagnostic fails, Event 157 names the internal Windows disk, CHKDSK cannot complete because of I/O failure, or the data is irreplaceable and not backed up. Also stop when the physical disk cannot be mapped confidently, a storage abstraction hides the real device, compatible imaging capacity is unavailable, or the next proposed step would initialize, format, convert, delete, repartition, secure-erase, or reinstall onto the suspect source.