Crash dump - Windows 7 x64

Deek

Well-known member
Joined
Apr 9, 2013
Posts
152
Location
Sacramento, Ca
Win 7 x64, 16gb PC2133, Samsung SSD, WD Black 500gb, AMD A10, Gigabyte MB

Fresh install, fully updated, not infected!

Here is the windbg, anyone want to take a shot at deciphering it?

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

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault).  The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a [B]*portion* of those codes:
If kv shows a taskGate
        use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
        use .trap on that value
Else
        .trap on the appropriate frame will show where the trap was taken
        (on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000000000008, EXCEPTION_DOUBLE_FAULT
Arg2: 0000000080050031
Arg3: 00000000000406f8
Arg4: fffff80002ea614e

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


BUGCHECK_STR:  0x7f_8

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

PROCESS_NAME:  mscorsvw.exe

CURRENT_IRQL:  2

EXCEPTION_RECORD:  fffff88008469ba8 -- (.exr 0xfffff88008469ba8)
ExceptionAddress: fffff80002ea07fe (nt!MiRemoveAnyPage+0x000000000000013e)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 0000000000000000
   Parameter[1]: ffffffffffffffff
Attempt to read from address ffffffffffffffff

TRAP_FRAME:  fffff88008469c50 -- (.trap 0xfffff88008469c50)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000002 rbx=0000000000000000 rcx=0000000000000000
rdx=0000000000000000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002ea07fe rsp=fffff88008469de0 rbp=fffff8800846e658
 r8=0000000000000000  r9=0000000000000002 r10=0000000000000000
r11=0000000000000001 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
nt!MiRemoveAnyPage+0x13e:
fffff800`02ea07fe f0410fba6c241000 lock bts dword ptr [r12+10h],0 
ds:00000000`00000010=????????
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff80002e7c169 to fffff80002e7cbc0

STACK_TEXT:  
fffff880`009c6ce8 fffff800`02e7c169 : 00000000`0000007f 00000000`00000008 
00000000`80050031 00000000`000406f8 : nt!KeBugCheckEx
fffff880`009c6cf0 fffff800`02e7a632 : 00000000`00000000 00000000`00000000 
00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69
fffff880`009c6e30 fffff800`02ea614e : 00000000`00000000 00000000`00000000 
00000000`00000000 00000000`00000000 : nt!KiDoubleFaultAbort+0xb2
fffff880`08468cf0 fffff800`02eb74c1 : fffff880`08469ba8 fffff880`08469900 
fffff880`08469c50 fffff880`0846e660 : nt!RtlDispatchException+0x2e
fffff880`084693d0 fffff800`02e7c242 : fffff880`08469ba8 00000000`00000017 
fffff880`08469c50 fffff800`02e07000 : nt!KiDispatchException+0x135
fffff880`08469a70 fffff800`02e7ab4a : 00000000`00000000 00000000`00000000 
00000000`00000000 00000000`00000000 : nt!KiExceptionDispatch+0xc2
fffff880`08469c50 fffff800`02ea07fe : 00000000`00000000 00000000`00000000 
00000000`00000000 00000000`00000000 : nt!KiGeneralProtectionFault+0x10a
fffff880`08469de0 00000000`00000000 : 00000000`00000000 00000000`00000000 
00000000`00000000 00000000`00000000 : nt!MiRemoveAnyPage+0x13e


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt!KiDoubleFaultAbort+b2
fffff800`02e7a632 90              nop

SYMBOL_STACK_INDEX:  2

SYMBOL_NAME:  nt!KiDoubleFaultAbort+b2

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  521ea035

FAILURE_BUCKET_ID:  X64_0x7f_8_nt!KiDoubleFaultAbort+b2

BUCKET_ID:  X64_0x7f_8_nt!KiDoubleFaultAbort+b2

Followup: MachineOwner
[/B]
 
Last edited by a moderator:
Re: Crash dump

I see that mscorsvw.exe is a background .net compiler of some sort, and I did just finish the final round of updates... All that was happening on the machine at the time was a format of the secondary HDD. It was just sitting and it BSOD'd and rebooted.
 
Re: Crash dump

Do you have a Kernel-Dump that you can upload and link here, Deek?

Regards,

Patrick
 
Re: Crash dump

I do not, and windbg on mini dumps is about the extent of what I have had to learn at this point...Is the kernel dump something I can generate? It's a brand new machine, and it only did that once...but the machine is going to an important CEO...so my reasons are obvious for wanting the box to be stable. Got a cheat sheet?
 
Re: Crash dump

Thanks!

Right, so the bug check itself is UNEXPECTED_KERNEL_MODE_TRAP (7f)

This bug check indicates that the Intel CPU generated a trap and the kernel failed to catch this trap.

BugCheck 7F, {8, 80050031, 406f8, fffff80002ea614e}

The 1st parameter of the bug check is 0x00000008, or Double Fault, indicates that an exception occurs during a call to the handler for a prior exception. Typically, the two exceptions are handled serially. However, there are several exceptions that cannot be handled serially, and in this situation the processor signals a double fault. There are two common causes of a double fault:
  • A kernel stack overflow. This overflow occurs when a guard page is hit, and the kernel tries to push a trap frame. Because there is no stack left, a stack overflow results, causing the double fault.
  • A hardware problem.

As you already noted, the process at the time of the crash is worth noting - PROCESS_NAME: mscorsvw.exe

mscorsvw.exe is used to precompile .NET assemblies in the background. When you install the .NET redistributable, it handles all of the high priority assemblies for 5-10 minutes, finishes them, and then waits for the system to be at an idle-state to handle the low priority assemblies.You can force all of the low priorities to finish and not wait for idle-state, also. Once all of that's said & done, the process will kill and you won't see mscorsvw.exe.

So, why did the system crash when this was occurring? It's noted that this process at times can cause 100% CPU usage, however the compilation itself happens in a process with low priority so your CPU is still handling other important tasks, calls, etc, much more frequently than it is the compilation process. With this said, no crash based off of CPU usage should occur.

Code:
1: kd> !thread
GetPointerFromAddress: unable to read from fffff800030b4000
THREAD fffffa8010685060  Cid 0e7c.11e8  Teb: 000007fffffdd000 Win32Thread: 0000000000000000 RUNNING on processor 1
Not impersonating
GetUlongFromAddress: unable to read from fffff80002ff3ba4
Owning Process            fffffa8050725730       Image:         mscorsvw.exe
Attached Process          N/A            Image:         N/A
fffff78000000000: Unable to get shared data
Wait Start TickCount      122578       
Context Switch Count      5             
ReadMemory error: Cannot get nt!KeMaximumIncrement value.
UserTime                  00:00:00.000
KernelTime                00:00:00.000
Win32 Start Address 0x000000013fe71f80
Stack Init fffff8800846ec70 Current fffff8800846e460
Base [COLOR=#006400]fffff8800846f000 [/COLOR]Limit [COLOR=#4b0082]fffff88008469000 [/COLOR]Call 0
Priority 9 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
Child-SP          RetAddr           : Args to Child                                                           : Call Site
fffff880`009c6ce8 fffff800`02e7c169 : 00000000`0000007f 00000000`00000008 00000000`80050031 00000000`000406f8 : nt!KeBugCheckEx
fffff880`009c6cf0 fffff800`02e7a632 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69
fffff880`009c6e30 fffff800`02ea614e : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDoubleFaultAbort+0xb2 (TrapFrame @ fffff880`009c6e30)
fffff880`08468cf0 fffff800`02eb74c1 : fffff880`08469ba8 fffff880`08469900 fffff880`08469c50 fffff880`0846e660 : nt!RtlDispatchException+0x2e
fffff880`084693d0 fffff800`02e7c242 : fffff880`08469ba8 00000000`00000017 fffff880`08469c50 fffff800`02e07000 : nt!KiDispatchException+0x135
fffff880`08469a70 fffff800`02e7ab4a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiExceptionDispatch+0xc2
fffff880`08469c50 fffff800`02ea07fe : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiGeneralProtectionFault+0x10a (TrapFrame @ fffff880`08469c50)
fffff880`08469de0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!MiRemoveAnyPage+0x13e

Looking at an excerpt from the raw stack:

Code:
fffff880`08469a68  fffff800`02e7c242 nt!KiExceptionDispatch+0xc2
fffff880`08469a70  fffff880`08469ba8
fffff880`08469a78  00000000`00000017
fffff880`08469a80  fffff880`08469c50
fffff880`08469a88  fffff800`02e07000 nt!KiSelectNextThread <PERF> (nt+0x0)
fffff880`08469a90  00000000`00000001
fffff880`08469a98  00000000`00000000
fffff880`08469aa0  00000000`00000000
fffff880`08469aa8  00000000`00000000
fffff880`08469ab0  00000000`00000000
fffff880`08469ab8  00000000`00000000
fffff880`08469ac0  00000000`00000000
fffff880`08469ac8  00000000`00000000
fffff880`08469ad0  00000000`00000000
fffff880`08469ad8  00000000`00000000
fffff880`08469ae0  00000000`00000000
fffff880`08469ae8  00000000`00000000
fffff880`08469af0  00000000`00000000
fffff880`08469af8  00000000`00000000
fffff880`08469b00  00000000`00000000
fffff880`08469b08  00000000`00000000
fffff880`08469b10  00000000`00000000
fffff880`08469b18  00000000`00000000
fffff880`08469b20  00000000`00000000
fffff880`08469b28  00000000`00000000
fffff880`08469b30  00000000`00000000
fffff880`08469b38  00000000`00000000
fffff880`08469b40  00000000`00000000
fffff880`08469b48  00000000`00000000
fffff880`08469b50  00000000`00000000
fffff880`08469b58  00000000`00000000
fffff880`08469b60  00000000`00000000
fffff880`08469b68  00000000`00000000
fffff880`08469b70  00000000`00000017
fffff880`08469b78  fffff880`0846e660
fffff880`08469b80  fffff800`02e07000 nt!KiSelectNextThread <PERF> (nt+0x0)
fffff880`08469b88  fffe9281`8d4b3200
fffff880`08469b90  00000000`00000000
fffff880`08469b98  00000000`0000001f
fffff880`08469ba0  00000000`00000017
fffff880`08469ba8  00000000`c0000005
fffff880`08469bb0  00000000`00000000
fffff880`08469bb8  fffff800`02ea07fe nt!MiRemoveAnyPage+0x13e
fffff880`08469bc0  00000000`00000002
fffff880`08469bc8  00000000`00000000
fffff880`08469bd0  ffffffff`ffffffff
fffff880`08469bd8  00000000`00000001
fffff880`08469be0  00000000`00000000
fffff880`08469be8  00000000`00000000
fffff880`08469bf0  00000000`00000000
fffff880`08469bf8  00000000`00000000
fffff880`08469c00  00000000`00000000
fffff880`08469c08  00000000`00000000
fffff880`08469c10  00000000`00000000
fffff880`08469c18  00000000`00000000
fffff880`08469c20  00000000`00000000
fffff880`08469c28  00000000`00000000
fffff880`08469c30  00000000`00000000
fffff880`08469c38  00000000`00000000
fffff880`08469c40  00000000`00000000
fffff880`08469c48  fffff800`02e7ab4a nt!KiGeneralProtectionFault+0x10a

We can see nt!KiGeneralProtectionFault, which is a routine then eventually leads to the execution of the exception handler that is associated with the routine that triggered the fault. I didn't paste what the routine was before it, because it's a huge gap, but it was nt!MiRemoveAnyPage.

We then have a nt!MiRemoveAnyPage call, a next thread select call, again, and then the exception itself is dispatched.

I don't like the fact that we're seeing memory related routines causing exceptions.



If you crash again, run Memtest on the RAM for no less than ~8 passes.

Regards,

Patrick
 

Has Sysnative Forums helped you? Please consider donating to help us support the site!

Back
Top