1. #1
    Deek's Avatar
    Join Date
    Apr 2013
    Location
    Sacramento, Ca
    Posts
    137

    Crash dump - Windows 7 x64

    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 *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
    
    Last edited by jcgriff2; 03-15-2014 at 04:50 AM. Reason: code box

    Come on, give me a hard one! I can fix anything ;-)


    • Ad Bot

      advertising
      Beep.

        
       

  2. #2
    Deek's Avatar
    Join Date
    Apr 2013
    Location
    Sacramento, Ca
    Posts
    137

    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.

    Come on, give me a hard one! I can fix anything ;-)

  3. #3

    Re: Crash dump

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

    Regards,

    Patrick

  4. #4
    Deek's Avatar
    Join Date
    Apr 2013
    Location
    Sacramento, Ca
    Posts
    137

    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?

    Come on, give me a hard one! I can fix anything ;-)

  5. #5

    Re: Crash dump

    If you can make it crash again - Creating a Kernel-Mode Dump File (Windows Debuggers)

    If not, attaching the minidump(s) are fine.

    Regards,

    Patrick

  6. #6
    Deek's Avatar
    Join Date
    Apr 2013
    Location
    Sacramento, Ca
    Posts
    137

    Re: Crash dump

    Quote Originally Posted by Patrick View Post
    If you can make it crash again - Creating a Kernel-Mode Dump File (Windows Debuggers)

    If not, attaching the minidump(s) are fine.

    Regards,

    Patrick

    It hasn't crashed again, but here is the minidmp:
    031114-7924-01.zip

    Come on, give me a hard one! I can fix anything ;-)

  7. #7

    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 fffff8800846f000 Limit fffff88008469000 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

  8. #8
    jcgriff2's Avatar
    Join Date
    Feb 2012
    Location
    New Jersey Shore
    Posts
    16,591
    • specs System Specs
      • Manufacturer:
        HP
      • Model Number:
        HP ENVY TouchSmart 17-j130us Notebook - E8A04UA
      • Motherboard:
        HP Insyde 720265-501 6050A2549501-MB-A02
      • CPU:
        Intel Core i7-4700MQ Processor with Turbo Boost up to 3.4GHz.
      • Memory:
        12GB DDR3L SDRAM (2 DIMM)
      • Graphics:
        Intel HD graphics 4600 with up to 1792MB total graphics memory
      • Sound Card:
        Beats Audio quad speakers and two subwoofers
      • Hard Drives:
        1TB 5400RPM hard drive with HP ProtectSmart Hard Drive Protection
      • Disk Drives:
        Hitachi 500 GB SSD; 7 TB USB External
      • Power Supply:
        90w
      • Case:
        Laptop
      • Display:
        17.3-inch diagonal HD+ BrightView LED-backlit touchscreen display (1600 x 900)
      • Operating System:
        Windows 8.1

    Re: Crash dump - Windows 7 x64

    Be sure to check for a firmware upgrade for your SSD.

Similar Threads

  1. blue screen crash dump file everytime computer freezes when i log on
    By vvelez89 in forum BSOD, Crashes, Kernel Debugging
    Replies: 1
    Last Post: 12-11-2013, 05:39 PM
  2. [SOLVED] atikmpag.sys crash
    By mnmsvista in forum BSOD, Crashes, Kernel Debugging
    Replies: 32
    Last Post: 09-18-2013, 12:31 PM
  3. OSR Online - Instant Online Crash Dump Analyzer
    By jcgriff2 in forum BSOD Kernel Dump Analysis Debugging Information
    Replies: 0
    Last Post: 11-16-2012, 09:41 PM
  4. Hello, here to help with crash dump analysis!
    By Patrick in forum Introductions - New Members
    Replies: 13
    Last Post: 07-04-2012, 04:30 PM

Log in

Log in