Troubleshooting 0xC0000221 STATUS_IMAGE_CHECKSUM_MISMATCH

The Debugging Tools for Windows are required to analyze crash dump files. If you do not have the Debugging Tools for Windows installed or dump files are not being generated on system crash, see this post for installation/configuration instructions:

http://mikemstech.blogspot.com/2011/11/windows-crash-dump-analysis.html

0xC0000221 is a somewhat uncommon blue screen error on the Windows platform (Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, and Windows 8). It is uncommon enough that it is not included in the standard list of bug check codes on MSDN and seems to crop up only when there is corruption in some of the critical system libraries. The actual bug code value is STATUS_IMAGE_CHECKSUM_MISMATCH:

C:\Users\Administrator>err c0000221
# for hex 0xc0000221 / decimal -1073741279 :
  STATUS_IMAGE_CHECKSUM_MISMATCH                         ntstatus.h
# {Bad Image Checksum}
# The image %hs is possibly corrupt. The header checksum does
# not match the computed checksum.
# 1 matches found for "c0000221" 

When I've observed this error, it usually is accompanied by a number of other errors that indicate file system corruption and possible memory issues (MEMORY_MANAGEMENT, NTFS_FILE_SYSTEM, SYSTEM_SERVICE_EXCEPTION [P1=0xc0000005], PAGE_FAULT_IN_NONPAGED_AREA, and SYSTEM_PTE_MISUES that only references the NT kernel). Since it isn't a common bug check that windbg knows how to handle, I had to take some educated guesses when I looked at the debugging output since there is no documentation for the parameters. I started out with a !analyze -v,

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Unknown bugcheck code (c0000221)
Unknown bugcheck description
Arguments:
Arg1: fffff8a0002400e0
Arg2: 0000000000000000
Arg3: 0000000000000000
Arg4: 0000000000000000

Debugging Details:
------------------


BUGCHECK_STR:  0xc0000221

ERROR_CODE: (NTSTATUS) 0xc0000221 - {Bad Image Checksum} The image %hs is 

                                    possibly corrupt. The header checksum 

                                    does not match the computed checksum.

EXCEPTION_CODE: (NTSTATUS) 0xc0000221 - {Bad Image Checksum}  The image %hs is 

                                        possibly corrupt. The header checksum 

                                        does not match the computed checksum.

EXCEPTION_PARAMETER1:  fffff8a0002400e0

EXCEPTION_PARAMETER2:  0000000000000000

EXCEPTION_PARAMETER3:  0000000000000000

EXCEPTION_PARAMETER4: 0

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

PROCESS_NAME:  System

CURRENT_IRQL:  0

LAST_CONTROL_TRANSFER:  from fffff800033112df to fffff800030c7c40

STACK_TEXT: 

... : nt!KeBugCheckEx
... : nt!ExpSystemErrorHandler2+0x5ff
... : nt!ExpSystemErrorHandler+0xdd
... : nt!ExpRaiseHardError+0xe1
... : nt!ExRaiseHardError+0x1d6
... : nt!NtRaiseHardError+0x1e4
... : nt!PspLocateSystemDll+0xbf
... : nt!PsLocateSystemDlls+0x69
... : nt!IoInitSystem+0x85d
... : nt!Phase1InitializationDiscard+0x129a
... : nt!Phase1Initialization+0x9
... : nt!PspSystemThreadStartup+0x5a
... : nt!KxStartSystemThread+0x16


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt!ExpSystemErrorHandler2+5ff
fffff800`033112df cc              int     3

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  nt!ExpSystemErrorHandler2+5ff

FOLLOWUP_NAME:  MachineOwner

DEBUG_FLR_IMAGE_TIMESTAMP:  4e02aaa3

FAILURE_BUCKET_ID:  X64_0xc0000221_nt!ExpSystemErrorHandler2+5ff

BUCKET_ID:  X64_0xc0000221_nt!ExpSystemErrorHandler2+5ff

Followup: MachineOwner
---------
 

Then I took an educated guess with the first parameter. Sometimes these parameters point to plain text strings in memory that tell more about the error (this is similar to 0x000000F4 CRITICAL_OBJECT_TERMINATION). The Windows debuggers have a number of commands prefixed with the letter d that display sections of memory in various ways (ex. dt = display type, da= ASCII Characters, du=Unicode characters, etc). I got lucky on the first try by displaying the ASCII string located at parameter 1,

0: kd> da fffff8a0002400e0
fffff8a0`002400e0  "\SystemRoot\System32\ntdll.dll" 

In this case, the ntdll.dll file is corrupted. Since this is corruption with a critical system file, the file needs to be replaced in some way (backup, etc) and the file system needs to be repaired. A logical first step is to try a file system repair/verification and check the critical system files. Since the system is really unstable at this point, this should be performed in the offline mode. Additionally, this may be the result of various things including viruses, memory failures, and hard drive problems. It is a good idea to check the memory for errors, then check the hard drive, then perform a virus scan if the file is successfully repaired during system verification. If not, most of the Microsoft KBs identify that the system may need to be reinstalled. If the system is too unstable to successfully back up the files, they may need to be rescued using a Linux Live CD. 

See Also,
Windows Crash Dump Analysis
Troubleshooting Memory Errors
How To Detect a Failing Hard Drive
How to Perform an Offline System Integrity Verification