Code:
0: kd> knL
# Child-SP RetAddr Call Site
00 fffff880`082a0888 fffff800`03cde429 nt!KeBugCheckEx
01 fffff880`082a0890 fffff800`03cdd0a0 nt!KiBugCheckDispatch+0x69
02 fffff880`082a09d0 fffff800`03d08532 nt!KiPageFault+0x260
03 fffff880`082a0b60 fffff800`03d197b1 nt!RtlDispatchException+0x122
04 fffff880`082a1240 fffff800`03cde502 nt!KiDispatchException+0x135
05 fffff880`082a18e0 fffff800`03cdc334 nt!KiExceptionDispatch+0xc2
06 fffff880`082a1ac0 fffff800`03cd6c91 nt!KiBreakpointTrap+0xf4
07 fffff880`082a1c58 fffff880`0122e060 nt!DbgBreakPoint+0x1
08 fffff880`082a1c60 fffff880`02fdf0c8 mv91xx+0x5060
09 fffff880`082a1c68 fffff880`02fdf0c8 0xfffff880`02fdf0c8
0a fffff880`082a1c70 00000000`00000200 0xfffff880`02fdf0c8
0b fffff880`082a1c78 00000000`00000000 0x200
The Marvell MV91xx AHCI/RAID driver called the nt!DbgBreakPoint+0x1 function to set a breakpoint (why????). It wasn't handled properly/something went wrong because the exception per the break caused a bugcheck and your system crashed.
Code:
Loaded symbol image file: mv91xx.sys
Image path: mv91xx.sys
Image name: mv91xx.sys
Browse all global symbols functions data
Timestamp: Thu Dec 24 22:45:39 2009
It's *really* old. Look for any updates for your Marvell AHCI/RAID driver(s) or get rid of it completely. It's obviously old and buggy as hell because it's setting breakpoints in kernel mode and not handling the exceptions.
Just to explain why you're getting 0x3B as well:
Code:
Bugcheck code 0000003B
Arguments 00000000`80000003 fffff800`03c8ac90 fffff880`0570c510 00000000`00000000
0x3B is raised per Windows when there's an exception while executing a system service routine. Exceptions are totally normal parts of Windows and occur in both user/kernel mode all the time, but it's when they aren't supposed to happen and when they are supposed to but something goes wrong is when it's bad/when systems crash. With the 0x3B crashes, the 1st parameter tells us what kind of exception occured:
The 1st parameter per the code block above is '00000000`80000003', which is a breakpoint exception. Something set a breakpoint and an exception occurred. If we want to find out more, we check the context record of the exception which is in the 3rd parameter.
Code:
rax=0000000000000001 rbx=fffff880030100e8 rcx=3cf7991241fb0000
rdx=000000000000003b rsi=0000000000000000 rdi=0000000000000100
rip=fffff80003c8ac90 rsp=fffff8800570cef8 rbp=0000000000000100
r8=0000000000000065 r9=0000000000000000 r10=0000000000000000
r11=fffff8800570cab0 r12=fffffa800aea1a00 r13=fffffa800a9bb8c0
r14=fffffa800a9cc890 r15=0000000000000020
iopl=0 nv up ei ng nz na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00000286
nt!DbgBreakPoint:
fffff800`03c8ac90 cc int 3
int 3 is the opcode of the breakpoint instruction (nt!DbgBreakPoint).. so we know a driver set a breakpoint and we can also see it here. We can dump the stack from the context:
Code:
0: kd> k
*** Stack trace for last set context - .thread/.cxr resets it
# Child-SP RetAddr Call Site
00 fffff880`0570cef8 fffff880`01005060 nt!DbgBreakPoint
01 fffff880`0570cf00 fffff880`030100e8 mv91xx+0x5060
02 fffff880`0570cf08 fffff880`030100e8 0xfffff880`030100e8
03 fffff880`0570cf10 00000000`00000200 0xfffff880`030100e8
04 fffff880`0570cf18 00000000`00000000 0x200
There's our Marvell driver again, doing what it does best (setting breakpoints that are never handled????)