New
#31
Yes, you'll have to create it - it's a DWORD (32bit) value, and it must be called CrashDumpEnabled (no trailing spaces, written as-is).
Yes, you'll have to create it - it's a DWORD (32bit) value, and it must be called CrashDumpEnabled (no trailing spaces, written as-is).
My bad, I assumed that this value/entry was already there, thanks.
So this is what I've done now:
1. Followed your instructions, set pagefile size to 8242mb and added the registry value, didn't touch system control panel afterwards.
2. Restarted computer so settings could be saved. Started verifier.exe again to select the soundcard and USB drivers again (using the settings posted in another thread on here) since those would cause the BSOD.
3.) Restarted, this time no BSOD occured as it used to at this point. So I deleted verifier.exe-settings and restarted. Then I activated verifier.exe again and selected ALL drivers (except microsoft) and restarted. No BSOD on startup this time either.
It's a bit hard to believe that setting that registry value or the pagefile size could have solved the problem (the pagefile size...could it?)
I'm not sure what to do from here on, just let the laptop run for a couple of hours with verifier.exe testing all those drivers and see if the BSOD shows up again? I also already ran memtest with 9 passes and 0 errors.
Given how drivers start under verifier, it could be something that simple. I think at this point you should (if you can) at least leave it running for a short time - if it doesn't repro shortly, disable verifier, reboot, and hopefully it won't happen again. If it does, you'll at least have a crash dump that could be helpful in troubleshooting it this time .
Thanks a lot again, cluberti...hopefully that was it now!
How short is "short" for verifier.exe to run? And I hope there is no kind of bad effect of having the pagefile in a fixed size like that?
Anyway, I'll keep you posted. verifier.exe ran for an hour already with all drivers selected as mentioned above, no BSOD :) THANK YOU!
If verifier doesn't catch anything in about 24 hours, that's good enough considering the symptoms and this thread. As to fixed, for a system with 8GB of RAM what you're doing is something I would suggest.
Sounds good, thank you! I'll let it run for 24hrs and report back on how it went.
Hm, seems I just got lucky yesterday. After running it for several hours, I decided to test it again with restarting (activating verifier.exe, selecting all drivers except microsoft, restart) and the BSOD happened again. Weirdly enough, this time the file is actually smaller (~350mb) than the kernel dump (~380mb) - I hope this is the full one?
Anyway, I've pm'd you the download link. Hopefully this time the error can be tracked down.
Thanks,
John M.
Well, this is a kernel dump (which is odd), but it most certainly has some good information - the BSOD is happening in the kernel, but autochk is also running:
Honestly, I'm not sure how to read this. However, at this point, it does appear likely to be a driver - however, I have my suspicions that neither the USB or soundcard driver is at fault, and more likely your video card/driver or something responsible for power. What happens if you run verifier only on these?Code:16.4: kd> !thread fffffa8006735680 THREAD fffffa8006735680 Cid 0004.002c Teb: 0000000000000000 Win32Thread: 0000000000000000 RUNNING on processor 4 IRP List: fffff98016092ee0: (0006,0118) Flags: 40060000 Mdl: 00000000 Not impersonating DeviceMap fffff8a000007dc0 Owning Process fffffa8006712ae0 Image: System Attached Process N/A Image: N/A Wait Start TickCount 482 Ticks: 1 (0:00:00:00.015) Context Switch Count 775 UserTime 00:00:00.000 KernelTime 00:00:00.312 Win32 Start Address nt!ExpWorkerThread (0xfffff800042ee910) Stack Init fffff8800355bc70 Current fffff8800355a710 Base fffff8800355c000 Limit fffff88003556000 Call 0 Priority 13 BasePriority 12 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5 Child-SP RetAddr : Args to Child : Call Site 00000000`00000000 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x0 16.4: kd> !irp fffff98016092ee0 Irp is active with 1 stacks 3 is current (= 00000000) No Mdl: No System Buffer: Thread fffff800042f9530: Irp is completed. Pending has been returned cmd flg cl Device File Completion-Context [ f, 0] 0 10 fffffa800a473b80 00000000 00000000-00000000 \Driver\DXGKrnl Args: 00000000 00000000 00000000 00000000 16.4: kd> !process 0 0 **** NT ACTIVE PROCESS DUMP **** PROCESS fffffa8006712ae0 SessionId: none Cid: 0004 Peb: 00000000 ParentCid: 0000 DirBase: 00187000 ObjectTable: fffff8a0000018c0 HandleCount: 97. Image: System PROCESS fffffa800a3f8040 SessionId: none Cid: 01b4 Peb: 7fffffdc000 ParentCid: 0004 DirBase: 1c428a000 ObjectTable: fffff8a0007f8700 HandleCount: 26. Image: smss.exe PROCESS fffffa800a3ff630 SessionId: none Cid: 01c0 Peb: 7fffffdb000 ParentCid: 01b4 DirBase: 1ccc72000 ObjectTable: fffff8a000a19f90 HandleCount: 2. Image: autochk.exe 16.4: kd> !thread fffffa800a279b60 THREAD fffffa800a279b60 Cid 01c0.01c4 Teb: 000007fffffde000 Win32Thread: 0000000000000000 WAIT: (Executive) KernelMode Alertable fffff880037b73a0 NotificationEvent Not impersonating DeviceMap fffff8a000007dc0 Owning Process fffffa800a3ff630 Image: autochk.exe Attached Process N/A Image: N/A Wait Start TickCount 459 Ticks: 24 (0:00:00:00.374) Context Switch Count 18 UserTime 00:00:00.000 KernelTime 00:00:00.000 Win32 Start Address 0x00000000ffa80660 Stack Init fffff880037b7c70 Current fffff880037b6fe0 Base fffff880037b8000 Limit fffff880037b2000 Call 0 Priority 9 BasePriority 8 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5 Child-SP RetAddr : Args to Child : Call Site fffff880`037b7020 fffff800`042e9992 : fffffa80`0a279010 fffffa80`0a279b60 00000000`00000000 fffffa80`085ceb70 : nt!KiSwapContext+0x7a fffff880`037b7160 fffff800`042ec1af : fffffa80`08ea4bc0 fffff880`0145bf6d fffff980`00000000 fffff980`16102ce0 : nt!KiCommitThreadWait+0x1d2 fffff880`037b71f0 fffff800`04582266 : 00000000`00000100 fffff800`00000000 fffffa80`0a279000 00000000`00000001 : nt!KeWaitForSingleObject+0x19f fffff880`037b7290 fffff800`045822e7 : fffffa80`083f7840 00000000`00000002 fffffa80`085ceb70 00000000`00000000 : nt!FsRtlCancellableWaitForMultipleObjects+0x5e fffff880`037b72f0 fffff880`01227605 : fffff880`037b73a0 00000000`00000002 fffffa80`085ceb70 fffffa80`08ea4bc0 : nt!FsRtlCancellableWaitForSingleObject+0x27 fffff880`037b7330 fffff880`01222971 : fffffa80`0840c480 fffffa80`085bc900 fffffa80`0a3e5610 fffffa80`085ceb70 : fltmgr!FltpFsControlMountVolume+0x385 fffff880`037b7400 fffff800`04787c16 : fffff980`16102c10 00000000`00000002 fffffa80`0840c480 fffffa80`0696a798 : fltmgr!FltpFsControl+0x101 fffff880`037b7460 fffff800`045502d7 : fffffa80`0840c480 fffff800`044e1250 fffffa80`0a279b60 fffffa80`085bc900 : nt!IovCallDriver+0x566 fffff880`037b74c0 fffff800`042d3a87 : fffff880`037b77e0 fffff880`037b7700 fffffa80`0855e900 fffff800`045e1501 : nt!IopMountVolume+0x28f fffff880`037b7580 fffff800`045e2706 : 00000000`00000005 00000000`00000000 fffff880`037b77e0 fffff880`037b7640 : nt!IopCheckVpbMounted+0x1b7 fffff880`037b75f0 fffff800`045ded38 : fffffa80`0855e940 fffff800`00000000 fffffa80`0a3e5a50 fffff880`00000001 : nt!IopParseDevice+0x816 fffff880`037b7780 fffff800`045dff56 : 00000000`00000000 fffffa80`0a3e5a50 00000000`00100080 fffffa80`06741b40 : nt!ObpLookupObjectName+0x588 fffff880`037b7870 fffff800`045e185c : 00000000`00000000 00000000`00000000 00000000`00000001 00000000`00000000 : nt!ObOpenObjectByName+0x306 fffff880`037b7940 fffff800`045cd134 : 00000000`001cf8b8 00000000`00100080 00000000`001cf930 00000000`001cf960 : nt!IopCreateFile+0x2bc fffff880`037b79e0 fffff800`042e38d3 : fffffa80`0a3ff630 0000007f`ffffffff fffffa80`00000400 00000980`00000000 : nt!NtOpenFile+0x58 fffff880`037b7a70 00000000`7790164a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff880`037b7ae0) 00000000`001cf858 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7790164a
There are other drivers here that could be at fault, so it might make sense to uninstall anything you don't absolutely need, and if the system crashes again, hopefully the next dump is useful. Otherwise, the only other real (viable) option is a rebuild - attaching a live kernel debugger over a null-modem cable from another machine would work for debugging, but that would require a second machine, a specialized null-modem cable, and someone there locally (or remoted it) to debug it when it crashed.Code:16.4: kd:x86> lmivm nvlddmkm start end module name fffff880`0f258000 fffff880`0feb3300 nvlddmkm (deferred) Symbol file: nvlddmkm.sys Image path: \SystemRoot\system32\DRIVERS\nvlddmkm.sys Image name: nvlddmkm.sys Timestamp: Thu Mar 17 04:08:59 2011 (4D81C19B) CheckSum: 00C6915C ImageSize: 00C5B300 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4 16.4: kd:x86> lmivm atkwmiacpi64 start end module name fffff880`02ff7000 fffff880`03000000 atkwmiacpi64 (deferred) Symbol file: atkwmiacpi64.sys Image path: \??\C:\Program Files (x86)\ASUS\ATK Package\ATK WMIACPI\atkwmiacpi64.sys Image name: atkwmiacpi64.sys Timestamp: Mon Jul 26 01:56:49 2010 (4C4D23A1) CheckSum: 00013A7D ImageSize: 00009000 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4
Weird, I followed what you wrote a few posts back to the letter so I'm not sure why it still gives a kernel dump. A full dump would also be MEMORY.DMP in c:\windows\, correct? I looked into regedit again and CrashDumpEnabled is still set to 1 so I'm not sure why it didn't make a full one
I ran verifier on both drivers you gave me above but with no reproducable BSOD after restarting several times with verifier. It would be bad if it's something important as this because the nvidia one is obviously my display/graphics driver and the ATK package is from Asus itself to make the FN buttons work (though I have to admit right now they don't work at all).
What you suggest sounds quite complicated because neither have I heard of a null-modem (though a G search could fix that), nor do I know someone around that could do the debugging. So at this point I'm almost considering to just delete the whole thing with DBAN and completely reinstall, but this sounds like a shot-gun approach and I'm not sure if that would actually fix anything.
Can we safely exclude a hardware error at this point? As I previously said, 9 passes of memtest didn't cause any errors though I haven't run a hard disk checking tool yet except the one from windows.
You can run memtest86+ again, it is possible to not give errors a few times then show the errors on the next test, just a fact of electronics.
I've seen this happen many times, and the occasional RAM error can cause havoc with drivers.
If you don't know the HDD brand, D/L SIW - System Information for Windows, it will tell you.
Go to the manufacturers website and get their HDD diagnostics program.
Here are two,
Seagate SeaTools
Western Digital Lifeguard
For the CPU
CPU - Stress Test with Prime95
Prime95 Torture test
If memtest86+ passes then run Prime95 torture test.
First open Real Temp to monitor CPU temperatures, don't go over 77 degC.
Open Prime95 and stop the test, in Advanced tab select 'Round off checking', in the Options tab select 'Torture Test...', in the window that opens select 'Blend', after 'Number of torture test threads to run' enter 8, then click OK to start the test.