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