Okay, never mind, it fixed itself much earlier this time.
The latest crash dump is of the
UNEXPECTED_KERNEL_MODE_TRAP (7f) bug check.
This bug check indicates that the Intel CPU generated a trap and the kernel failed to catch this trap.
BugCheck 7F, {
8, 80050031, 6f8, fffff80002ee4064}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.
Code:
1: kd> !thread
GetPointerFromAddress: unable to read from fffff8000310f000
THREAD fffffa800729a060 Cid 0f88.0f8c Teb: 000000007efdb000 Win32Thread: fffff900c30cac20 RUNNING on processor 1
Not impersonating
GetUlongFromAddress: unable to read from fffff8000304eba4
Owning Process fffffa8007280b30 Image: Skype.exe
Attached Process N/A Image: N/A
fffff78000000000: Unable to get shared data
Wait Start TickCount 11244013
Context Switch Count 29001741 LargeStack
ReadMemory error: Cannot get nt!KeMaximumIncrement value.
UserTime 00:00:00.000
KernelTime 00:00:00.000
Win32 Start Address 0x0000000001189758
Stack Init fffff88009d2ddb0 Current fffff88009d2d830
[COLOR=#4b0082]Base[/COLOR] [COLOR=#ff0000]fffff88009d2e000[/COLOR] Limit fffff88009d24000 Call 0
Priority 10 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
Child-SP RetAddr : Args to Child : Call Site
fffff880`009efce8 fffff800`02ed7169 : 00000000`0000007f 00000000`00000008 00000000`80050031 00000000`000006f8 : nt!KeBugCheckEx
fffff880`009efcf0 fffff800`02ed5632 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69
fffff880`009efe30 fffff800`02ee4064 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDoubleFaultAbort+0xb2 (TrapFrame @ fffff880`009efe30)
fffff880`09d23ff0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!MmAccessFault+0x244
I've never attempted to 'rebuild' a stack from an 0x7F crash on 64-bit architecture, so I could be wrong, but AFAIK the stack base =
0xfffff88009d24000 (even though
base itself equals another address).
Code:
1: kd> dd fffff88009d2e000
fffff880`09d2e000 ???????? ???????? ???????? ????????
fffff880`09d2e010 ???????? ???????? ???????? ????????
fffff880`09d2e020 ???????? ???????? ???????? ????????
fffff880`09d2e030 ???????? ???????? ???????? ????????
fffff880`09d2e040 ???????? ???????? ???????? ????????
fffff880`09d2e050 ???????? ???????? ???????? ????????
fffff880`09d2e060 ???????? ???????? ???????? ????????
fffff880`09d2e070 ???????? ???????? ???????? ????????
Not having much luck. I may be wrong in my attempt to rebuild given it's x64 and it may differ from x86, or it may be because it's not a kernel-dump.
In any case, we can try taking a look at the trapframe from the !thread dump above:
Code:
1: kd> .trap fffff880`009efe30
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=000000000a719915
rdx=fffff88009d240a8 rsi=0000000000000000 rdi=0000000000000000
[COLOR=#ff0000]rip=fffff80002ee4064[/COLOR] rsp=fffff88009d23ff0 rbp=fffff88009d24040
r8=fffff88009d24098 r9=fffff6fb40000298 r10=fffff680000538c8
r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
[COLOR=#4b0082]nt!MmAccessFault+0x244[/COLOR]:
[COLOR=#ff0000]fffff800`02ee4064[/COLOR] e8771d0100 call nt!MiCheckVirtualAddress (fffff800`02ef5de0)
Code:
1: kd> u @rip
nt!MmAccessFault+0x244:
fffff800`02ee4064 e8771d0100 call [COLOR=#4b0082]nt!MiCheckVirtualAddress[/COLOR] (fffff800`02ef5de0)
fffff800`02ee4069 448b7d68 mov r15d,dword ptr [rbp+68h]
fffff800`02ee406d 4183ff18 cmp r15d,18h
fffff800`02ee4071 0f84cc1d0000 je [COLOR=#ff0000]nt!MmAccessFault+0x2023[/COLOR] (fffff800`02ee5e43)
fffff800`02ee4077 4c8b5520 mov r10,qword ptr [rbp+20h]
fffff800`02ee407b 418bd7 mov edx,r15d
fffff800`02ee407e 48894548 mov qword ptr [rbp+48h],rax
fffff800`02ee4082 c1ea03 shr edx,3
MmAccessFault is Windows' memory management fault handler, and is designed primarily to handle page faults. Page faults themselves despite 'fault' are not always errors and are common and necessary to increase the amount of memory available to programs in the OS. Essentially however, page faults occur when a program accesses a page that is mapped in the virtual address space, but not quite yet loaded in physical memory.
We then call into
nt!MiCheckVirtualAddress which is another memory related function.
I'm getting range errors trying to disassemble any further, likely because it's a minidump.
Could you please do two things?
1. Set up generation of kernel-dumps:
Creating a Kernel-Mode Dump File (Windows Debuggers)
2. Enable Driver Verifier:
Driver Verifier:
What is Driver Verifier?
Driver Verifier is included in Windows 8/8.1, 7, Windows Server 2008 R2, Windows Vista, Windows Server 2008, Windows 2000, Windows XP, and Windows Server 2003 to promote stability and reliability; you can use this tool to troubleshoot driver issues. Windows kernel-mode components can cause system corruption or system failures as a result of an improperly written driver, such as an earlier version of a Windows Driver Model (WDM) driver.
Essentially, if there's a 3rd party driver believed to be at issue, enabling Driver Verifier will help flush out the rogue driver if it detects a violation.
Before enabling Driver Verifier, it is recommended to create a System Restore Point:
Vista - START | type rstrui - create a restore point
Windows 7 - START | type create | select "Create a Restore Point"
Windows 8 -
Restore Point - Create in Windows 8
How to enable Driver Verifier:
Start > type "verifier" without the quotes > Select the following options -
1. Select - "Create custom settings (for code developers)"
2. Select - "Select individual settings from a full list"
3. Check the following boxes -
- Special Pool
- Pool Tracking
- Force IRQL Checking
- Deadlock Detection
- Security Checks (Windows 7 & 8)
- DDI compliance checking (Windows 8)
- Miscellaneous Checks
4. Select - "Select driver names from a list"
5. Click on the "Provider" tab. This will sort all of the drivers by the provider.
6. Check EVERY box that is
NOT provided by Microsoft / Microsoft Corporation.
7. Click on Finish.
8. Restart.
Important information regarding Driver Verifier:
- If Driver Verifier finds a violation, the system will BSOD. To expand on this a bit more for the interested, specifically what Driver Verifier actually does is it looks for any driver making illegal function calls. When and/if this happens, system corruption occurs if allowed to continue. When Driver Verifier is enabled, it is monitoring
all 3rd party drivers (as we have it set that way) and when it catches a driver attempting to do this, it will quickly flag that driver as being a troublemaker, and bring down the system safely before any corruption can occur.
- After enabling Driver Verifier and restarting the system, depending on the culprit, if for example the driver is on start-up, you may not be able to get back into normal Windows because Driver Verifier will detect it in violation almost straight away, and as stated above, that will cause / force a BSOD.
If this happens, do
not panic, do the following:
- Boot into Safe Mode by repeatedly tapping the F8 key during boot-up.
- Once in Safe Mode - Start > Search > type "cmd" without the quotes.
- To turn off Driver Verifier, type in cmd "verifier /reset" without the quotes.
・ Restart and boot into normal Windows.
If your OS became corrupt or you cannot boot into Windows after disabling verifier via Safe Mode:
- Boot into Safe Mode by repeatedly tapping the F8 key during boot-up.
- Once in Safe Mode - Start > type "system restore" without the quotes.
- Choose the restore point you created earlier.
-- Note that Safe Mode for Windows 8 is a bit different, and you may need to try different methods:
5 Ways to Boot into Safe Mode in Windows 8 & Windows 8.1
How long should I keep Driver Verifier enabled for?
I recommend keeping it enabled for at least 24 hours. If you don't BSOD by then, disable Driver Verifier. I will usually say whether or not I'd like for you to keep it enabled any longer.
My system BSOD'd with Driver Verifier enabled, where can I find the crash dumps?
They will be located in %systemroot%\Minidump
Any other questions can most likely be answered by this article:
Using Driver Verifier to identify issues with Windows drivers for advanced users
After the system crashes with both #1 and #2 done, navigate to C:\Windows and upload MEMORY.DMP to any 3rd party hosting site such as Onedrive, Dropbox, etc, and link it here.
Regards,
Patrick
