[SOLVED] BSOD help crashes after ending a game session and occasionally when im surfing

traceurgan

New member
Joined
Feb 16, 2015
Posts
2
· OS - Windows 8.1
· x64 ?
· No OS installed originally
· Age of system - 3 months
· Age of OS installation - 3 months

· CPU- 4th gen intel i7-4710mq(quadcore)
· Video Card-NVIDIA GEFORCE 860M GTX 2GB GDDR5

· System Manufacturer- Aftershock PC
· Exact model number - XG15-V3

Laptop
 

Attachments

This is actually one of the most interesting threads I've looked at in a long time, mainly because you have two problems. One problem is your actual crash problem, and the other is... interesting.

Your actual problem:

Code:
6: kd> .bugcheck
Bugcheck code 0000009F
Arguments 00000000`00000003 ffffe000`06de0670 ffffd001`533a3960 ffffe000`0763dbd0

Code:
6: kd> !Irp ffffe0000763dbd0
Irp is active with 6 stacks 4 is current (= 0xffffe0000763dd78)
 No Mdl: No System Buffer: Thread 00000000:  Irp stack trace.  
     cmd  flg cl Device   File     Completion-Context
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    

            Args: 00000000 00000000 00000000 00000000
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    

            Args: 00000000 00000000 00000000 00000000
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    

            Args: 00000000 00000000 00000000 00000000
>[ 16, 2]   0 e1 ffffe00006de0670 00000000 fffff8002883237c-ffffd001531f1890 Success Error Cancel pending
           \Driver\pci    dxgkrnl!DpiFdoPowerCompletionRoutine
            Args: 00000000 00000001 00000001 00000000
 [ 16, 2]   0 e1 ffffe000073c31f0 00000000 fffff802b2da2efc-ffffe0000895af08 Success Error Cancel pending
           \Driver\nvlddmkm    nt!PopRequestCompletion

I think I need to submit a bug ticket or something to nVidia, because this beta driver is a problem. I dealt with it here. Uninstall it and go with the latest WHQL or whatever worked best for you before to fix the problem.



Your interesting problem (consists of two parts):

Code:
5: kd> .bugcheck
Bugcheck code 000000C4
Arguments 00000000`000000e2 ffffe000`29d78a80 00000000`0220003a 00000000`00000000

Code:
5: kd> !irp ffffe00029d78a80
Irp is active with 11 stacks 11 is current (= 0xffffe00029d78e20)
 No Mdl: System buffer=0220003a: Thread ffffe0002c986080:  Irp stack trace.

 [  5, 0]   0 e0 ffffe00029450df0 ffffe0002abc8f20 fffff800fa21327c-ffffcf82e5594a80 Success Error Cancel 
          ffffe00029450df0: Could not read device object or _DEVICE_OBJECT not found
    fltmgr!FltpPassThroughCompletion
            Args: 00000fc2 00000009 00000000 00000000
>[  5, 0]   0  1 ffffe00029450df0 ffffe0002abc8f20 00000000-00000000    pending
          ffffe00029450df0: Could not read device object or _DEVICE_OBJECT not found

Code:
5: kd> !irp ffffe00029d78a80 1
Irp is active with 11 stacks 11 is current (= 0xffffe00029d78e20)
 No Mdl: System buffer=0220003a: Thread ffffe0002c986080:  Irp stack trace.  
Flags = 00001014
ThreadListEntry.Flink = ffffe0002a9c5d60
ThreadListEntry.Blink = ffffe0002c9866d8
IoStatus.Status = 00000000
IoStatus.Information = 00000000
RequestorMode = 00000000 // Here, 0 = kernel-mode.

Code:
5: kd> !thread ffffe0002c986080
ffffd000`a41fdbd8 fffff802`f649a6b0 : 00000000`000000c4 00000000`000000e2 ffffe000`29d78a80 00000000`0220003a : nt!KeBugCheckEx
ffffd000`a41fdbe0 fffff802`f649a64a : fffff802`f64bb780 fffff802`f5e4bee5 00000000`00000000 ffffe000`2abc8f20 : nt!VerifierBugCheckIfAppropriate+0x3c
ffffd000`a41fdc20 fffff802`f6499c3e : ffffe000`29d78a80 ffffe000`2abc8f20 00000000`00000000 00000000`00000000 : nt!ViIrpCheckKernelAddressForIrp+0x6e
ffffd000`a41fdc60 fffff802`f648e88c : ffffe000`29d78a80 00000000`00000002 fffff802`f5f35b88 00000000`00000178 : nt!VfBeforeCallDriver+0x4a
ffffd000`a41fdc90 fffff800`f9c77989 : ffffe000`29d78a80 fffff800`fa214b1e fffff802`f5f35b88 ffffe000`2ee40300 : nt!IovCallDriver+0x348
ffffd000`a41fdce0 fffff800`fa214b1e : ffffcf82`e5594a80 ffffd000`a41fdd60 00000000`00000001 fffff802`00000158 : VerifierExt!IofCallDriver_internal_wrapper+0x71
ffffd000`a41fdd20 fffff800`fa2130c2 : ffffd000`a41fdde0 ffffe000`29450df0 00000000`00000002 ffffe000`29d78a80 : fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x2ce
ffffd000`a41fddc0 fffff802`f648e911 : ffffe000`29d78a80 00000000`00000002 00000000`00000000 ffffe000`2c986080 : fltmgr!FltpDispatch+0xb2
ffffd000`a41fde20 fffff802`f627cc5f : ffffe000`29d78a80 00000000`0220003a ffffe000`29450df0 ffffe000`2f2164b0 : nt!IovCallDriver+0x3cd
ffffd000`a41fde70 fffff802`f627c825 : 00000000`00000fc2 ffffd000`a41fe390 00000000`00000001 fffff802`f5e841ac : nt!IopGetFileInformation+0xdb
ffffd000`a41fdef0 fffff802`f627c686 : ffffe000`2abc8f20 00000000`77062300 00000020`00001000 00000000`02200000 : nt!IopQueryNameInternal+0x199
ffffd000`a41fdfa0 fffff802`f61bc4aa : ffffd000`a41fe0b8 fffff6fb`7dbed000 fffff6fb`7dbed000 fffff6fb`7da00000 : nt!IopQueryName+0x26
ffffd000`a41fdff0 fffff802`f61b1ad6 : ffffe000`2abc8f20 00000000`02200000 ffffe000`00000ffe ffffd000`a41fe138 : nt!ObQueryNameStringMode+0xb2
ffffd000`a41fe0f0 fffff802`f61b1326 : ffffd000`a41fe2e0 fffff802`f5f6fd57 00000000`00000008 00000000`00000000 : nt!MmQueryVirtualMemory+0x7a6
ffffd000`a41fe250 fffff802`f5f711b3 : 00000000`00002200 00000000`00000002 7fffe000`28239088 ffffe000`28239088 : nt!NtQueryVirtualMemory+0x22
ffffd000`a41fe2a0 fffff802`f5f69600 : fffff800`fae4c915 ffffcf82`615cefc0 ffffc001`00000001 ffffc001`00000001 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ ffffd000`a41fe310)
ffffd000`a41fe4a8 fffff800`fae4c915 : ffffcf82`615cefc0 ffffc001`00000001 ffffc001`00000001 00000000`02200000 : nt!KiServiceLinkage
ffffd000`a41fe4b0 ffffcf82`615cefc0 : ffffc001`00000001 ffffc001`00000001 00000000`02200000 00000000`00000ffe : aswSP+0x4c915
ffffd000`a41fe4b8 ffffc001`00000001 : ffffc001`00000001 00000000`02200000 00000000`00000ffe 00000000`00000000 : 0xffffcf82`615cefc0
ffffd000`a41fe4c0 ffffc001`00000001 : 00000000`02200000 00000000`00000ffe 00000000`00000000 00000000`00000000 : 0xffffc001`00000001
ffffd000`a41fe4c8 00000000`02200000 : 00000000`00000ffe 00000000`00000000 00000000`00000000 fffff800`fae0e722 : 0xffffc001`00000001
ffffd000`a41fe4d0 00000000`00000ffe : 00000000`00000000 00000000`00000000 fffff800`fae0e722 00000000`00820000 : 0x2200000
ffffd000`a41fe4d8 00000000`00000000 : 00000000`00000000 fffff800`fae0e722 00000000`00820000 ffffc001`ee354000 : 0xffe

From the looks of it (only a small memory dump, not much we can explore), avast's self-protection driver is doing some IRP stuff (see calls to the function nt!IovCallDriver+0x348 for example throughout the stack to prove this). Drivers doing IRP stuff, who cares, that's normal behavior. What's actually interesting here is avast's self-protection driver calls the Filter Manager's FltpDispatch function to likely read into something user-mode (possibly a buffer) and this is where the IRP issue comes in. We have a user-mode IRP field but the execution mode of the original requester is kernel-mode.

To sum it up, this is poor programming on avast's part. I am actually willing to bet that if you didn't enable verifier, you would have never crashed if this occurred with it disabled. Driver Verifier however 7> is really strict when certain flags are set. So with that said, avast's poor programming practice here may never had rendered a real-world crash scenario for you, but verifier caught it in action and therefore bug checked the system because it knows that it's not the correct way to go about things. After all, verifier is a device driver developer's debugging tool first before anything else.



Code:
2: kd> .bugcheck
Bugcheck code 000000D5
Arguments ffffcf80`8d330f80 00000000`00000000 fffff801`0d9e4241 00000000`00000000

Relatively straightforward crash here, in that you once again had verifier enabled and it caught a driver referencing memory after it was already previously freed. I'll let you take a guess as to what the driver is part of.

....Guessed it yet?


Surprise! It's avast!

Code:
2: kd> k
Child-SP          RetAddr           Call Site
ffffd000`227f06d8 fffff801`4f39e5a8 nt!KeBugCheckEx
ffffd000`227f06e0 fffff801`4f283d29 nt! ?? ::FNODOBFM::`string'+0x246f8
ffffd000`227f0780 fffff801`4f373c2f nt!MmAccessFault+0x769
ffffd000`227f0940 fffff801`0d9e4241 nt!KiPageFault+0x12f
ffffd000`227f0ad0 fffff801`4f6d102f aswHwid+0x1241 // Here the driver references the already freed memory.
ffffd000`227f0ad8 ffffd000`238d6680 nt!IopOpenRegistryKey+0x4b
ffffd000`227f0ae0 ffffcf80`9e5d0880 0xffffd000`238d6680
ffffd000`227f0ae8 fffff801`4f7aef63 0xffffcf80`9e5d0880
ffffd000`227f0af0 00000000`00280026 nt! ?? ::NNGAKEGL::`string'+0x68cf3
ffffd000`227f0af8 fffff801`0d9e4d50 0x280026
ffffd000`227f0b00 ffffd000`227f0b10 aswHwid+0x1d50
ffffd000`227f0b08 fffff801`4f7aef6a 0xffffd000`227f0b10
ffffd000`227f0b10 fffff801`4f2c43ac nt! ?? ::NNGAKEGL::`string'+0x68cfa
ffffd000`227f0b50 fffff801`4f2f1280 nt!ExpWorkerThread+0x28c
ffffd000`227f0c00 fffff801`4f36ffc6 nt!PspSystemThreadStartup+0x58
ffffd000`227f0c60 00000000`00000000 nt!KiStartSystemThread+0x16

avast's hardware identification service driver was the culprit here. I have no idea what this driver does because I'm not working for avast, but if I had to take a guess, it's probably something to do with licensing or initilization depending on the originally installed device/OS. There's interestingly a lot of user-mode stuff going on here as well.

Code:
2: kd> .trap ffffd000`227f0940
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=ffffcf808d330ef0
rdx=00000000002f7bef rsi=0000000000000000 rdi=0000000000000000
rip=fffff8010d9e4241 rsp=ffffd000227f0ad0 rbp=ffffd000238d6680
 r8=00000000003e4fe9  r9=ffffd001d6a80180 r10=0000000000000100
r11=0000000000000100 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz na po nc
aswHwid+0x1241:
fffff801`0d9e4241 488b8190000000  mov     rax,qword ptr [rcx+90h] ds:ffffcf80`8d330f80=????????????????

Here's the instruction regarding the referenced to the previously freed memory.

Code:
2: kd> !pte ffffcf808d330ef0
                                           VA ffffcf808d330ef0
PXE at FFFFF6FB7DBEDCF8    PPE at FFFFF6FB7DB9F010    PDE at FFFFF6FB73E02348    PTE at FFFFF6E7C0469980
contains 0000000000B65863  contains 000000010F55E863  contains 0000000134CA1863  contains 4F81079280000000
GetUlongFromAddress: unable to read from fffff8014f57c104
pfn b65       ---DA--KWEV  pfn 10f55e    ---DA--KWEV  pfn 134ca1    ---DA--KWEV  not valid
                                                                                  PageFile:  0
                                                                                  Offset: 4f810792
                                                                                  Protect: 0

We can see it's not resident in physical memory anymore, likely because it was already freed.

Again, all summed up to poor programming on avast's part.



So if you couldn't find the solutions amidst all of the stuff:

1. To fix your immediate crashing problem, uninstall your current beta nVidia driver and install latest official WHQL for your GPU or just go back to last working version.

2. Get rid of avast. Get rid of it and run far far away.

avast! removal - http://www.avast.com/uninstall-utility
 
Last edited:
Code:
5: kd> .bugcheck
Bugcheck code 000000C4
Arguments 00000000`000000e2 ffffe000`29d78a80 00000000`0220003a 00000000`00000000

[COLOR="#800080"]//IRP called in user mode, but the RequesterMode field was a Kernel address[/COLOR]

5: kd> k
Child-SP          RetAddr           Call Site
ffffd000`a41fdbd8 fffff802`f649a6b0 nt!KeBugCheckEx [COLOR="#800080"]//Bugcheck[/COLOR]
ffffd000`a41fdbe0 fffff802`f649a64a nt!VerifierBugCheckIfAppropriate+0x3c [COLOR="#800080"]//Verifier, bugcheck if required[/COLOR]
ffffd000`a41fdc20 fffff802`f6499c3e nt!ViIrpCheckKernelAddressForIrp+0x6e [COLOR="#800080"]//Check the Kernel address on IRP[/COLOR]
ffffd000`a41fdc60 fffff802`f648e88c nt!VfBeforeCallDriver+0x4a //Verifier hooked function, check the IRP information[/COLOR]
ffffd000`a41fdc90 fffff800`f9c77989 nt!IovCallDriver+0x348 [COLOR="#800080"]//Call driver using IRP[/COLOR]
ffffd000`a41fdce0 fffff800`fa214b1e VerifierExt!IofCallDriver_internal_wrapper+0x71 [COLOR="#800080"]//Verifier hooked internal driver function[/COLOR]
ffffd000`a41fdd20 fffff800`fa2130c2 fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x2ce
ffffd000`a41fddc0 fffff802`f648e911 fltmgr!FltpDispatch+0xb2 [COLOR="#800080"]//Filter driver functions[/COLOR]
ffffd000`a41fde20 fffff802`f627cc5f nt!IovCallDriver+0x3cd [COLOR="#800080"]//Call driver[/COLOR]
ffffd000`a41fde70 fffff802`f627c825 nt!IopGetFileInformation+0xdb [COLOR="#800080"]//Get file information[/COLOR]
ffffd000`a41fdef0 fffff802`f627c686 nt!IopQueryNameInternal+0x199
ffffd000`a41fdfa0 fffff802`f61bc4aa nt!IopQueryName+0x26
ffffd000`a41fdff0 fffff802`f61b1ad6 nt!ObQueryNameStringMode+0xb2 [COLOR="#800080"]//Query object name[/COLOR]
ffffd000`a41fe0f0 fffff802`f61b1326 nt!MmQueryVirtualMemory+0x7a6 [COLOR="#800080"]//MM control[/COLOR]
ffffd000`a41fe250 fffff802`f5f711b3 nt!NtQueryVirtualMemory+0x22 [COLOR="#800080"]//Query virtual memory[/COLOR]
ffffd000`a41fe2a0 fffff802`f5f69600 nt!KiSystemServiceCopyEnd+0x13 [COLOR="#800080"]//Switch to Kernel mode[/COLOR]
ffffd000`a41fe4a8 fffff800`fae4c915 nt!KiServiceLinkage [COLOR="#800080"]//Switch to user mode[/COLOR]
ffffd000`a41fe4b0 ffffcf82`615cefc0 aswSP+0x4c915 [COLOR="#800080"]//Avast! driver[/COLOR]
ffffd000`a41fe4b8 ffffc001`00000001 0xffffcf82`615cefc0
ffffd000`a41fe4c0 ffffc001`00000001 0xffffc001`00000001
ffffd000`a41fe4c8 00000000`02200000 0xffffc001`00000001
ffffd000`a41fe4d0 00000000`00000ffe 0x2200000
ffffd000`a41fe4d8 00000000`00000000 0xffe

5: kd> !irp ffffe00029d78a80
Irp is active with 11 stacks 11 is current (= 0xffffe00029d78e20)
 No Mdl: System buffer=0220003a: Thread ffffe0002c986080:  Irp stack trace.  
     cmd  flg cl Device   File     Completion-Context
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    

			Args: 00000000 00000000 00000000 00000000
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    

			Args: 00000000 00000000 00000000 00000000
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    

			Args: 00000000 00000000 00000000 00000000
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    

			Args: 00000000 00000000 00000000 00000000
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    

			Args: 00000000 00000000 00000000 00000000
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    

			Args: 00000000 00000000 00000000 00000000
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    

			Args: 00000000 00000000 00000000 00000000
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    

			Args: 00000000 00000000 00000000 00000000
 [  0, 0]   0  0 00000000 00000000 00000000-00000000    

			Args: 00000000 00000000 00000000 00000000
 [  5, 0]   0 e0 ffffe00029450df0 ffffe0002abc8f20 fffff800fa21327c-ffffcf82e5594a80 Success Error Cancel 
	      ffffe00029450df0: Could not read device object or _DEVICE_OBJECT not found
	fltmgr!FltpPassThroughCompletion
			Args: 00000fc2 00000009 00000000 00000000
>[  5, 0]   0  1 ffffe00029450df0 ffffe0002abc8f20 00000000-00000000    pending
	      ffffe00029450df0: Could not read device object or _DEVICE_OBJECT not found

			Args: 00000fc2 00000009 00000000 00000000

Irp Extension present at 0xffffe00029d78e68:

[COLOR="#800080"]//Disk related IRP, context not saved[/COLOR]

5: kd> dt nt!_IRP ffffe00029d78a80
   +0x000 Type             : 0n6
   +0x002 Size             : 0x430
   +0x004 AllocationProcessorNumber : 5
   +0x006 Reserved         : 0
   +0x008 MdlAddress       : (null) 
   +0x010 Flags            : 0x1014
   +0x018 AssociatedIrp    : <unnamed-tag>
   +0x020 ThreadListEntry  : _LIST_ENTRY [ 0xffffe000`2a9c5d60 - 0xffffe000`2c9866d8 ]
   +0x030 IoStatus         : _IO_STATUS_BLOCK
   +0x040 RequestorMode    : 0 '' [COLOR="#800080"]//Context not saved, or value for Kernel mode?[/COLOR]
   +0x041 PendingReturned  : 0 ''
   +0x042 StackCount       : 11 ''
   +0x043 CurrentLocation  : 11 ''
   +0x044 Cancel           : 0 ''
   +0x045 CancelIrql       : 0 ''
   +0x046 ApcEnvironment   : 0 ''
   +0x047 AllocationFlags  : 0x4 ''
   +0x048 UserIosb         : 0xffffd000`a41fdea0 _IO_STATUS_BLOCK
   +0x050 UserEvent        : 0xffffd000`a41fdeb0 _KEVENT
   +0x058 Overlay          : <unnamed-tag>
   +0x068 CancelRoutine    : (null) 
   +0x070 UserBuffer       : (null) 
   +0x078 Tail             : <unnamed-tag>


5: kd> vertarget
Windows 8 Kernel Version 9600 MP (8 procs) Free x64 [COLOR="#800080"]//Windows 8[/COLOR]
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 9600.17630.amd64fre.winblue_r7.150109-2022
Machine Name:
Kernel base = 0xfffff802`f5e15000 PsLoadedModuleList = 0xfffff802`f60ee250
Debug session time: Mon Feb 16 12:10:22.624 2015 (UTC + 0:00)
System Uptime: 0 days 1:15:10.367

Avast, no surprise, is causing problems. Buggy code has caused it to either use a bad IRP or it is presuming the address was user mode, yet it was Kernel mode.
I recommend you uninstall Avast and use Windows Defender. Post any new crashes after you've removed Avast.

EDIT: Patrick beat me to it!
I'm on a different machine to my home computer, I'm on a machine at college (during break) which doesn't let me set up crash dumps in a way that sets Windbg as the default. It's tedious to go through and open them one by one.
 
Last edited:

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

Back
Top