Code:
1: kd> .bugcheck
Bugcheck code 0000007F
Arguments 00000000`00000008 00000000`80050031 00000000`000006f8 fffff800`02d6362f
First off, first arg. is 0x8 which implies the reason for the bug check being called was due to an exception occurring while a previous exception had already occurred and is being processed.
Code:
1: kd> knL
# Child-SP RetAddr Call Site
00 fffff880`009eeca8 fffff800`02a77e69 nt!KeBugCheckEx
01 fffff880`009eecb0 fffff800`02a76332 nt!KiBugCheckDispatch+0x69
02 fffff880`009eedf0 fffff800`02d6362f nt!KiDoubleFaultAbort+0xb2
03 fffff880`0a101000 fffff960`00091760 nt!KeUserModeCallback+0x87
04 fffff880`0a101080 fffff880`00000041 win32k+0x71760
05 fffff880`0a101088 fffff880`0a101150 0xfffff880`00000041
06 fffff880`0a101090 fffff880`0a101390 0xfffff880`0a101150
07 fffff880`0a101098 fffff880`0a1013a0 0xfffff880`0a101390
08 fffff880`0a1010a0 fffff880`0a1010b8 0xfffff880`0a1013a0
09 fffff880`0a1010a8 00000000`00000000 0xfffff880`0a1010b8
So it looks like we're trying to run some user-mode code from kernel-mode using
KeUserModeCallback.
We can confirm this by the win32k call coming directly after user-mode code, and then having that function exist thereafter. Although nowadays most of the graphics part of Windows' subsystem exists directly in win32k, a bit of it still requires callbacks from user-mode and needs the kernel component to help out by calling the code. We hit an exception directly after performing the callback, and then call the 0x7F bug check as the double fault is instant death in kernel-mode.
Code:
1: kd> .trap fffff880`009eedf0
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffffa8006b36a10 rbx=0000000000000000 rcx=000000000481e3e0
rdx=0000000000000138 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002d6362f rsp=fffff8800a101000 rbp=000000000000012c
r8=0000000000000010 r9=fffff8800a1010d8 r10=00000000000000a1
r11=fffffa8006b36a10 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na pe nc
nt!KeUserModeCallback+0x87:
fffff800`02d6362f e86cc80200 call nt!ProbeForWrite (fffff800`02d8fea0)
Taking a look at the trapframe regarding the exception that occurred, we can see it was a call instruction regarding the
ProbeForWrite function. This function exists specifically to check whether or not a specified user-mode buffer
actually exists in valid user-mode address space, is properly aligned, and writeable. Since this is merely a small dump, there's not much we can do to check, but my guess is the specified range of memory was not valid, therefore it raised STATUS_ACCESS_VIOLATION, and that's where our exception came from.
Anyway, something interesting is there's always the same process during the time of the crash in every crash dump of yours.
Code:
PROCESS_NAME: avastui.exe
LOL, why am I not surprised. avast! most likely being a reason for blue screens. I've never seen that happen before :r1:
To test whether or not this particular avast! exe is causing this due to most likely bad programming, let's kill the ui process (avastui.exe). To do this, we can't just kill it and that's it. We need to disable active protection, kill it, then re-enable active protection. Right click avast!'s tray icon > program settings >'Troubleshooting' tab > 'Disable avast! self-defense module'.
After killing the process, report back on whether or not the crashes stop.