[SOLVED] BSOD 0x7f UNEXPECTED_KERNEL_MODE_TRAP caused by ntoskrnl.exe - Windows 7 x64

X

xOrrangee

Member
Joined
Jul 15, 2015
Posts
5
Hey there, I have been getting this BSOD which just started about 2 days ago. I have tried Reseting BIOS to default settings, to updating the BIOS, SFC scans, driver updates, and updating windows. I get this BSOD very randomly when only playing games. I have also done stresstests on CPU and GPU. These BSOD's happend very randomly when playing games.

Here is the crash list.
There is nothing I know to do from here Im banging my head against my desk every BSOD. Please help
Dump FileCrash TimeBug Check StringBug Check CodeParameter 1Parameter 2Parameter 3Parameter 4Caused By DriverCaused By AddressFile DescriptionProduct NameCompanyFile VersionProcessorCrash AddressStack Address 1Stack Address 2Stack Address 3Computer NameFull PathProcessors CountMajor VersionMinor VersionDump File SizeDump File Time

[TD="bgcolor: #FFFFFF"]071315-18189-01.dmp[/TD]
[TD="bgcolor: #FFFFFF"]7/13/2015 7:55:35 PM[/TD]
[TD="bgcolor: #FFFFFF"]UNEXPECTED_KERNEL_MODE_TRAP[/TD]
[TD="bgcolor: #FFFFFF"]0x0000007f[/TD]
[TD="bgcolor: #FFFFFF"]00000000`00000008[/TD]
[TD="bgcolor: #FFFFFF"]00000000`80050031[/TD]
[TD="bgcolor: #FFFFFF"]00000000`000006f8[/TD]
[TD="bgcolor: #FFFFFF"]fffff800`02db462f[/TD]
[TD="bgcolor: #FFFFFF"]ntoskrnl.exe[/TD]
[TD="bgcolor: #FFFFFF"]ntoskrnl.exe+748c0[/TD]
[TD="bgcolor: #FFFFFF"]NT Kernel & System[/TD]
[TD="bgcolor: #FFFFFF"]Microsoft® Windows® Operating System[/TD]
[TD="bgcolor: #FFFFFF"]Microsoft Corporation[/TD]
[TD="bgcolor: #FFFFFF"]6.1.7601.18869 (win7sp1_gdr.150525-0603)[/TD]
[TD="bgcolor: #FFFFFF"]x64[/TD]
[TD="bgcolor: #FFFFFF"]ntoskrnl.exe+748c0[/TD]
[TD="bgcolor: #FFFFFF"] [/TD]
[TD="bgcolor: #FFFFFF"] [/TD]
[TD="bgcolor: #FFFFFF"] [/TD]
[TD="bgcolor: #FFFFFF"] [/TD]
[TD="bgcolor: #FFFFFF"]C:\Windows\Minidump\071315-18189-01.dmp[/TD]
[TD="bgcolor: #FFFFFF"]3[/TD]
[TD="bgcolor: #FFFFFF"]15[/TD]
[TD="bgcolor: #FFFFFF"]7601[/TD]
[TD="bgcolor: #FFFFFF"]405,944[/TD]
[TD="bgcolor: #FFFFFF"]7/13/2015 7:56:23 PM[/TD]
 
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.
 
Well It has been a week without the BSOD. It just so odd that Avast was causing them, Well who cares i guess. :P
Thank you so much for the help.
 

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

Back
Top