memory.dmp vista will not boot - even safe mode

First off, thanks for looking at my dilemma.

This computer was on during a storm and the attached monitor died. Memory tests showed errors so I replaced the RAM. Memory tests show no issues now.

Upon boot the system gives STOP 0xc000008e error
win32k.sys

With Windows PE, I was able to use chkdsk to repair errors on the hard drive. chkdsk reports no errors now. I also flashed the BIOS successfully with the latest.

Hardware tests seem to run fine now but I'm still not sure if it is a Windows corruption issue or a hardware issue.

I did add a graphics card and changed the BIOS to use that card instead of the on-board graphics.

Feel free to move this to software as needed.

The zipped memory.dmp file is about 18 mb so I cannot attach it. I'm just now trying to run windbg.

Thanks for your time and any suggestions.

-w1

 

Checking the memory.dmp file produces this:

BugCheck 8E, {c0000005, 921e2738, 8896a898, 0}

Page 2b987 not present in the dump file. Type ".hh dbgerr004" for details
Page 2bbee not present in the dump file. Type ".hh dbgerr004" for details
Page 2bbee not present in the dump file. Type ".hh dbgerr004" for details
Probably caused by : win32k.sys ( win32k!MAPPER::vEmergency+a5 )

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

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

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: 921e2738, The address that the exception occurred at
Arg3: 8896a898, Trap Frame
Arg4: 00000000

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

Page 2b987 not present in the dump file. Type ".hh dbgerr004" for details
Page 2bbee not present in the dump file. Type ".hh dbgerr004" for details
Page 2bbee not present in the dump file. Type ".hh dbgerr004" for details

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

FAULTING_IP:
win32k!MAPPER::vEmergency+a5
921e2738 8b4034 mov eax,dword ptr [eax+34h]

TRAP_FRAME: 8896a898 -- (.trap 0xffffffff8896a898)
ErrCode = 00000000
eax=00000000 ebx=ffffff7f ecx=00000000 edx=00000000 esi=8896a970 edi=00000000
eip=921e2738 esp=8896a90c ebp=8896a930 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
win32k!MAPPER::vEmergency+0xa5:
921e2738 8b4034 mov eax,dword ptr [eax+34h] ds:0023:00000034=????????
Resetting default scope

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x8E

PROCESS_NAME: csrss.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 82478968 to 8251eb8d

STACK_TEXT:
8896a458 82478968 0000008e c0000005 921e2738 nt!KeBugCheckEx+0x1e
8896a828 8249c83a 8896a844 00000000 8896a898 nt!KiDispatchException+0x1a9
8896a890 8249c7ee 8896a930 921e2738 badb0d00 nt!CommonDispatchException+0x4a
8896a8b8 8267ef77 8896a8d8 00000000 00000000 nt!Kei386EoiHelper+0x186
8896a930 921904df 8896ab84 ffa20718 8896ab78 nt!ObpRemoveObjectRoutine+0x145
8896aa70 9218e43a 8896abac ffa0d12c ffa0d0e8 win32k!ppfeGetAMatch+0x294
8896aae8 921b0314 8896abac 8896ab78 8896ab50 win32k!LFONTOBJ:pfeMapFont+0x2a5
8896ab7c 921b017e ffa0d008 00000000 00000002 win32k!RFONTOBJ::bInit+0x17b
8896ab94 92132c01 8896abac 00000000 00000002 win32k!RFONTOBJ::vInit+0x16
8896abb8 9210407e 00000000 8896abd0 ff9d164c win32k!GreGetTextMetricsW+0x2a
8896ac14 920f7746 03010034 8896ac2c ff9d164c win32k!_GetTextMetricsW+0x16
8896ac70 920f8c86 03010034 8896ac90 ff9d0fd8 win32k!GetCharDimensions+0x16
8896ace4 920ea25e 00000002 00000001 00000000 win32k!UpdateUserScreen+0x5e2
8896ad0c 920e7b13 00000000 00000001 00000001 win32k!InitUserScreen+0x11b
8896ad24 920e70e5 ffa02a30 00000000 00000058 win32k!InitVideo+0xd3
8896ad48 920e47fa 0029fb74 8896ad64 8249bc7a win32k!UserInitialize+0x120
8896ad54 8249bc7a 00000058 0000005c 0029fb90 win32k!NtUserInitialize+0x9f
8896ad54 77675e74 00000058 0000005c 0029fb90 nt!KiFastCallEntry+0x12a
WARNING: Frame IP not in any known module. Following frames may be wrong.
0029fb90 00000000 00000000 00000000 00000000 0x77675e74


STACK_COMMAND: kb

FOLLOWUP_IP:
win32k!MAPPER::vEmergency+a5
921e2738 8b4034 mov eax,dword ptr [eax+34h]

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: win32k!MAPPER::vEmergency+a5

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: win32k

IMAGE_NAME: win32k.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4c1f6af2

FAILURE_BUCKET_ID: 0x8E_win32k!MAPPER::vEmergency+a5

BUCKET_ID: 0x8E_win32k!MAPPER::vEmergency+a5

Followup: MachineOwner

 

Electrical storms cause havoc with both hardware and software this may take a while to sort out, do you have Recovery or Vista discs?

If you set Windows to save small memory dumps, it'll make it faster to reboot and allow you to upload the dmps easier.