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