Repair STATUS_IMAGE_CHECKSUM_MISMATCH for a boot-critical Windows file

Windows stops with 0xc0000221 and names a driver, system DLL, kernel image, file-system driver, or boot loader whose checksum does not match. The file may be corrupt, but the same symptom can result from faulty RAM or an unreliable disk/I/O path.

Searchable Windows error codes and exact messages

Search the exact code and complete File: path together, for example 0xc0000221 ntfs.sys, 0xc0000221 ntoskrnl.exe, or 0xc0000221 winload.efi. Do not treat ntoskrnl.exe as the cause merely because it is named; it may be the file whose bytes could not be read correctly.

Use this procedure when the screen or dump names a specific Microsoft boot-critical file and the Windows volume is readable.

Do not use it as a generic repair for changing file names, failing memory tests, recurring disk I/O errors, or a named third-party driver. A third-party driver requires removal or replacement of its package, not substitution from Windows installation media.

The exact build may remain unknown for initial disk checks and SFC. It becomes required before using DISM with external repair content. The named file and its full path may not remain unknown.

• Windows Recovery Environment or installation media
• Command Prompt
• Readable Windows volume
• Matching Windows 10/11 installation media if SFC cannot repair the file
• Storage and memory diagnostics when file names change or corruption recurs

Open Repair your computer > Troubleshoot > Advanced options > Command Prompt. Record the exact named file before running repairs.

1. Photograph or transcribe the complete screen, including code, file, and message.

2. Detect and map the Windows volume:

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

3. Confirm the named file exists. Replace the example path with the actual displayed path:

   dir W:\Windows\System32\drivers\ntfs.sys
   

4. Check the file system without repairs:

   chkdsk W:
   

5. Stop if the disk is unstable, CHKDSK reports I/O failures, or the named file changes across boots. Image the storage and test RAM before writing replacement data.

6. If the file belongs to Microsoft and the volume is stable, proceed to offline SFC.

7. If the file is a third-party driver, record its path and package/provider details. Use the dedicated boot-start-driver procedure rather than replacing it with Microsoft media.

Branch A — Repair with offline System File Checker

1. Run:

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

2. Record the final SFC message.

3. If SFC reports successful repair, restart and test.

4. If SFC reports no corruption despite the same checksum screen, test storage and RAM before assuming SFC is wrong.

5. If SFC finds corruption but cannot repair it, continue to Branch B.

Branch B — Repair the component store from matching Windows media

1. Obtain installation media matching the installed architecture, language, edition, and Windows release/build closely enough to service the offline installation.

2. Detect the media volume and assign M: if needed:

   diskpart
   list volume
   select volume <installation-media-volume-number>
   assign letter=M
   exit
   

3. Determine whether the media contains install.wim or install.esd:

   dir M:\sources\install.*
   

4. List image indexes for WIM media:

   dism /Get-WimInfo /WimFile:M:\sources\install.wim
   

5. For ESD media, use:

   dism /Get-WimInfo /WimFile:M:\sources\install.esd
   

6. Select the index matching the installed edition. Do not assume index 1.

7. Repair from WIM media:

   dism /Image:W:\ /Cleanup-Image /RestoreHealth /Source:wim:M:\sources\install.wim:<index> /LimitAccess
   

8. Or repair from ESD media:

   dism /Image:W:\ /Cleanup-Image /RestoreHealth /Source:esd:M:\sources\install.esd:<index> /LimitAccess
   

9. Record the DISM result. If DISM reports source files could not be found, stop and obtain correctly matched media rather than trying random indexes or builds.

10. After successful DISM repair, run offline SFC again:

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

11. Restart and test twice.

Branch C — Repair demonstrated logical disk errors first

1. If the initial read-only CHKDSK found ordinary logical errors and the drive is stable, back up required data.

2. Run:

   chkdsk W: /f
   

3. Repeat offline SFC after CHKDSK completes.

4. If file corruption returns, stop and investigate storage or RAM.

• SFC repairs the named Microsoft file and Windows starts: The protected file or its component-store copy was damaged.
• DISM with a matching source succeeds, then SFC succeeds: The component store required external repair content.
• DISM reports source mismatch or missing source: Exact version/source information is now required.
• The next boot names a different file: Stop file replacement and test RAM and storage.
• The same checksum error occurs while booting known-good Windows media: Hardware or firmware-path testing takes priority over repairing the installed image.
• The named file is third-party: Remove or replace its verified driver package; do not use DISM to invent a Microsoft replacement.

• Do not download DLL, SYS, EXE, or EFI files from file-replacement sites.
• Do not copy a system file from a different computer or arbitrary build.
• Do not disable signature enforcement permanently to hide a checksum or signature failure.
• Do not use an installation-image index without matching the installed edition.
• Do not continue repairing files when the failed filename changes or hardware tests fail.
• Do not assume the kernel file named on screen caused its own corruption.

SFC and DISM do not provide a simple one-file undo. Use System Restore or the pre-repair system image if a repair makes the condition worse. Preserve CBS.log and DISM.log so the files and packages changed can be audited.

• Windows starts normally three times.
• Online DISM /Online /Cleanup-Image /ScanHealth reports no remaining component-store corruption.
• Online sfc /scannow reports no unresolved integrity violations.
• The named file no longer appears in a checksum or signature failure.
• Storage and memory checks remain stable, particularly when the original corruption was unexplained.

Confidence is approximately 85% when one Microsoft file is consistently named, storage and RAM are stable, and SFC or matched-source DISM repairs it. Stop when file names change, recovery media also fails, hardware tests report errors, the named file is third-party, or correctly matched repair content is unavailable.