Hi,
It's
_M, therefore it's 0x1000008E.
KERNEL_MODE_EXCEPTION_NOT_HANDLED_M
This indicates that a kernel-mode program generated an exception which the error handler did not catch.
Code:
1: kd> kv
ChildEBP RetAddr Args to Child
f7532a58 80618061 e10196b8 0053005c e10196b8 nt!HvpGetCellMapped+0x5f (FPO: [Non-Fpo])
f7532a74 805db75d e10196b8 e1231624 e10196b8 nt!CmpMarkValueDataDirty+0x44 (FPO: [Non-Fpo])
f7532a90 805db790 e10196b8 00291e80 e1230adc nt!CmpMarkKeyValuesDirty+0xcc (FPO: [Non-Fpo])
f7532aac 805db2bb e10196b8 00291e80 e12b6e84 nt!CmpFreeKeyValues+0x17 (FPO: [Non-Fpo])
f7532ae8 805db405 e10196b8 00274a28 e1299a2c nt!CmpSyncKeyValues+0x26 (FPO: [Non-Fpo])
f7532b2c 805db84d e1c6c000 00000400 00000004 nt!CmpCopySyncTree2+0x1f4 (FPO: [Non-Fpo])
f7532b5c 805dba52 e10196b8 000001b8 e10196b8 nt!CmpCopySyncTree+0x4f (FPO: [Non-Fpo])
f7532ccc 805b062e 00010002 f7532d64 f7532ce8 nt!CmpSaveBootControlSet+0x2b0 (FPO: [Non-Fpo])
f7532cdc 804dd9ab 00000004 f7532d64 804e3933 nt!NtInitializeRegistry+0x5e (FPO: [Non-Fpo])
f7532cdc 804e3933 00000004 f7532d64 804e3933 nt!KiSystemServicePostCall (FPO: [0,0] TrapFrame @ f7532ce8)
f7532d58 804dd9ab 00000004 0007fe8c 7c91e514 nt!ZwInitializeRegistry+0x11 (FPO: [1,0,0])
f7532d58 7c91e514 00000004 0007fe8c 7c91e514 nt!KiSystemServicePostCall (FPO: [0,0] TrapFrame @ f7532d64)
0007fe8c 00000000 00000000 00000000 00000000 0x7c91e514
This stack is of relatively no use considering frame pointer omission + small dump. We're just going from user-mode > right into the registry with a Zw prefix on the registry call. Given we're dealing with Zw directly from user-mode, this tells us an application from user-mode that isn't in trusted space called it.
Code:
1: kd> .bugcheck
Bugcheck code 1000008E
Arguments c0000005 80578812 f753299c 00000000
Code:
1: kd> .trap f753299c
ErrCode = 00000000
eax=00001300 ebx=00001300 ecx=84fbe7d8 edx=00000002 esi=e10196b8 edi=0000005c
eip=80578812 esp=f7532a10 ebp=f7532a58 iopl=0 nv up ei pl zr na pe nc
cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010246
nt!HvpGetCellMapped+0x5f:
80578812 8b4304 mov eax,dword ptr [ebx+4] ds:0023:00001304=????????
We crashed setting eax to the value at address ebx+4. We cannot investigate as it's a small dump, but if we look, eax and ebx are the same - 00001300 ???
Looks and sounds like a buggy driver so far to me that called from user-mode.
Since the actual stack from the thread at the time of the crash is no help, we'll need to dump the raw stack. First off, we have a lot of NTFS calls in the raw stack, such as:
So we know NTFS is being accessed by the driver/software that ultimately caused the bug check, specifically causing it to write to the LFS/transaction journal. If we go up the stack more we can see:
Code:
f7532080 f78f0deeUnable to load image dump_ViPrt.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for dump_ViPrt.sys
*** ERROR: Module load completed but symbols could not be loaded for dump_ViPrt.sys
ViPrt.sys:
Code:
1: kd> lmvm ViPrt
start end module name
f7849000 f7859000 ViPrt (deferred)
Image path: ViPrt.sys
Image name: ViPrt.sys
Timestamp: Mon Mar 26 03:26:47 2007
VIA SATA/IDE, appears to be from Taiwan?
VIA Drivers Download - VIA Technologies, Inc.
Anyway, either the driver itself is problematic or the drive(s) connected to it are. You'll have to do some troubleshooting to find which. If it's not the drives, uninstall the driver and use the default SATA/IDE Windows driver.
