http://mikemstech.blogspot.com/2011/11/windows-crash-dump-analysis.html
This is a hard error for most users to debug because it requires setting up a live debug session with the system that is experiencing the error. This is a relatively simple process, but it involves 2 systems (one working with the debugging tools for Windows installed, and the broken system) and a serial cable connecting them. The Windows DVD and bcdedit need to be used to enable debug mode for the target system (since it is likely unbootable). I show an example of how this works in Hyper-V, but it should be virtually the same for two physical systems (the difference lies in choosing a serial port in WinDbg instead of a named pipe). The error text states that something is missing: "STOP: c0000135 The program can't start because %hs is missing from your computer. Try reinstalling the program to fix the problem."
This is not a common error on the Windows platform (Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, and Windows 8), but it does occasionally crop up with some antivirus software (AVG is notorious for being connected with this BSOD). What makes this error bad is that the call to the printf like function isn't made (thus %hs isn't substituted for the missing file name) and the blue screen itself does not provide any indication of what is missing. From the error code, we know it is a missing/corrupt dll:
# for hex 0xc0000135 / decimal -1073741515 :
STATUS_DLL_NOT_FOUND ntstatus.h
# {Unable To Locate Component}
# This application has failed to start because %hs was not
# found. Re-installing the application may fix this problem.
# 1 matches found for "0xc0000135"
Attaching to a live debugging session, we can get more information about what went wrong, in this case the missing file is identified in the "Probably caused by" line near the start of the debug session. In my case I deleted gdi32.dll on purpose to recreate the error, the missing file on your system will probably be different:
*** Fatal System Error: 0xc0000135
(0xFFFFF8A00050ED60,0xFFFFF8A002A54B90,
0x0000000000000000,0x0000000000000000) STOP: c0000135 The program can't start because (null) is missing
from your computer. Try reinstalling the program to fix this problem.
Break instruction exception - code 80000003 (first chance)
A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.
A fatal system error has occurred.
Connected to Windows 7 7600 x64 target at (Wed Jan 4 08:30:19.860 2012 (UTC - 7:00)), ptr64 TRUE
Loading Kernel Symbols
...............................................................
............................................
Loading User Symbols
Loading unloaded module list
........
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck C0000135, {fffff8a00050ed60, fffff8a002a54b90, 0, 0}
Probably caused by : GDI32.dll
Followup: MachineOwner
---------
nt!DbgBreakPointWithStatus:
fffff800`0266bf60 cc int 3
We can gain more information by running a !analyze -v:kd> !analyze -v ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* Unknown bugcheck code (c0000135) Unknown bugcheck description Arguments: Arg1: fffff8a00050ed60 Arg2: fffff8a002a54b90 Arg3: 0000000000000000 Arg4: 0000000000000000 Debugging Details: ------------------ ERROR_CODE: (NTSTATUS) 0xc0000135 - The program can't start because %hs
is missing from your computer. Try
reinstalling the program to fix this problem. EXCEPTION_CODE: (NTSTATUS) 0xc0000135 - The program can't start because %hs is
missing from your computer. Try
reinstalling the program to fix
this problem. EXCEPTION_PARAMETER1: fffff8a00050ed60 EXCEPTION_PARAMETER2: fffff8a002a54b90 EXCEPTION_PARAMETER3: 0000000000000000 EXCEPTION_PARAMETER4: 0 BUGCHECK_STR: STATUS_DLL_NOT_FOUND IMAGE_NAME: GDI32.dll DEBUG_FLR_IMAGE_TIMESTAMP: 0 MODULE_NAME: GDI32 FAULTING_MODULE: 0000000000000000 DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT PROCESS_NAME: System CURRENT_IRQL: 2 LAST_CONTROL_TRANSFER: from fffff800027696d2 to fffff8000266bf60 STACK_TEXT: ... : nt!DbgBreakPointWithStatus ... : nt!KiBugCheckDebugBreak+0x12 ... : nt!KeBugCheck2+0x71e ... : nt!KeBugCheckEx+0x104 ... : nt!PopGracefulShutdown+0x257 ... : nt!NtSetSystemPowerState+0x864 ... : nt!KiSystemServiceCopyEnd+0x13 ... : nt!KiServiceLinkage ... : nt!PopIssueActionRequest+0x1d9 ... : nt!PopPolicyWorkerAction+0x4c ... : nt!PopPolicyWorkerThread+0xfd ... : nt!ExpWorkerThread+0x111 ... : nt!PspSystemThreadStartup+0x5a ... : nt!KxStartSystemThread+0x16 STACK_COMMAND: kb FOLLOWUP_NAME: MachineOwner FAILURE_BUCKET_ID: X64_STATUS_DLL_NOT_FOUND_VRF_IMAGE_GDI32.dll BUCKET_ID: X64_STATUS_DLL_NOT_FOUND_VRF_IMAGE_GDI32.dll Followup: MachineOwner ---------
We have an undocumented bugcheck, so we need to make a couple of educated guesses to look at the parameters. I looked at parameter 1 and parameter 2 using the da (Display Memory - ASCII) debugger command.
kd> da fffff8a00050ed60 fffff8a0`0050ed60 "GDI32.dll"
kd> da fffff8a002a54b90 fffff8a0`02a54b90 "C:\Windows\system32;C:\Windows\s" fffff8a0`02a54bb0 "ystem32;C:\Windows;C:\Windows\Sy" fffff8a0`02a54bd0 "stem32\Wbem;C:\Windows\System32\" fffff8a0`02a54bf0 "WindowsPowerShell\v1.0\"
Parameter 1 is clearly the missing DLL and parameter 2 appears to be the DLL search path that was searched to find the DLL. The resolution is fairly straightforward, the missing file needs to be restored in some way. This may be as easy as an offline integrity check, or as hard as needing to copy the files from a working system to a flash drive and copying them into place with a Linux Live CD (basically reversing this procedure to put files onto the system instead of take them off). Some users may find it simplest to rescue their files and reinstall Windows, or at least perform an in place upgrade.
See Also,
Windows Crash Dump Analysis
Live Debugging a Hyper-V Virtual Machine with WinDbg/KD
Rescuing Files From a Damaged System
No comments:
Post a Comment