Partilhar via

Debugging the mystery of the crashing desktop - Part 2

  • Artigo

Continued from Part 1:

I enabled Driver verifier for Win32k.Sys and the video driver and then reproduce the crash by remotely logging in first and the logging via the main console. After a reboot, I looked at the dump and this time the bugcheck was of different error code.

KERNEL_MODE_EXCEPTION_NOT_HANDLED (8e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: 950030b2, The address that the exception occurred at
Arg3: 9f8f75bc, Trap Frame
Arg4: 00000000

STACK_TEXT:
9f8f717c 81c232b3 0000008e c0000005 950030b2 nt!KeBugCheckEx+0x1e
9f8f754c 81c8d52a 9f8f7568 00000000 9f8f75bc nt!KiDispatchException+0x1a9
9f8f75b4 81c8d4de f0000201 950030b2 badb0d00 nt!CommonDispatchException+0x4a
9f8f75d0 81ecf9eb 00000021 00000134 72626447 nt!Kei386EoiHelper+0x186
9f8f7650 81fa4f3d 81c77607 ff808f68 950282f7 nt!VerifierExAllocatePoolWithTag+0x59
9f8f7654 81c77607 ff808f68 950282f7 00000004 hal!KeReleaseQueuedSpinLock+0x2d
9f8f7680 8f394466 fee90e60 ff0e4d00 00000000 nt!ExpReleaseResourceForThreadLite+0x14a
95028308 cc0018c2 24748b56 90868b0c 57000009 win32k!WatchdogDrvRealizeBrush+0x45
WARNING: Frame IP not in any known module. Following frames may be wrong.

MODULE_NAME: vtdisp

IMAGE_NAME: vtdisp.dll

SYMBOL_NAME: vtdisp+30b2

FAILURE_BUCKET_ID: 0x8E_VRF_vtdisp+30b2

BUCKET_ID: 0x8E_VRF_vtdisp+30b2

As you can see the DriverVerifier's VerifierExAllocatePoolWithTag method threw the bugcheck as it didnt like what the code was asking it to do. The module name it reported was vtdisp.dll and getting the information on that module confirmed what I had suspected. The video driver from S3 was the culprit.

kd> lmvm vtdisp
start end module name
95000000 95356400 vtdisp (no symbols)
Loaded symbol image file: vtdisp.dll
Image path: \SystemRoot\System32\vtdisp.dll
Image name: vtdisp.dll
Timestamp: Thu Oct 06 02:20:01 2005 (4344EC41)
CheckSum: 00360BC5
ImageSize: 00356400
File version: 6.14.10.250
Product version: 6.14.10.250
File flags: 8 (Mask 3F) Private
File OS: 40004 NT Win32
File type: 3.4 Driver
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: VIA/S3 Graphics Co, Ltd.
ProductName: UniChrome(Pro) IGP Driver
InternalName: vtdisp.dll
OriginalFilename: vtdisp.dll
ProductVersion: 6.14.10.0250-16.94.44.29
FileVersion: 6.14.10.0250-16.94.44.29
FileDescription: VIA/S3G Graphics Driver
LegalCopyright: Copyright (C) VIA Technologies, Inc. and S3 Graphics Co, Ltd.2005

The analysis mentioned that the error was at address 950030b2 and unassembling that part of code produced the following output.

kd> u 950030b2
vtdisp+0x30b2:
950030b2 890a mov dword ptr [edx],ecx

Its trying to copy ECX register value to the address pointed by EDX register and when I dumped the registers, the values were listed as

kd> r
eax=81cf483c ebx=950030b2 ecx=00000321 edx=00001000 esi=81cf4820 edi=9f8f75bc
eip=81cd85c9 esp=9f8f7160 ebp=9f8f717c iopl=0 nv up ei ng nz na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000286

As you can see EDX is not a valid address and hence the bugcheck. Well I guess I have to wait for an updated driver or go for a new video card.

Maheshwar Jayaraman

Comments