The dump is blaming hardware again - single bit corruption which typically means faulty memory. Does the system ever crash without having first gone through a sleep/wake cycle? I have a Haswell system that used to have such a problem with long times in-between crashes. It was basically why I first started learning how to analyze crash dumps.
Last edited by cwsink; 30 Jan 2020 at 13:08.
Yes it crashed the other day during the middle of my work day while actively using the system for research. And from what ive seen about 60/40 (sleep/wake vs while using) has been the breakdown. Typically the in-use crashes happen while switching between open tabs/programs, opening new browser tabs/programs or attempting a reboot/restart of the system.
This is driving me nuts with the randomness and not being able to actively make it crash by doing X. And my first thoughts were memory as well but like i said ive tested 6 different DIMMs in a variety of slot positions with 2 different brands which to me eliminates the memory and/or DIMM slots on the board as potential causes.
Seems like im down to testing each individual driver (which will probably take forever) to try and figure something out there. Maybe ill get lucky and find out its one of the gigabyte drivers that i can just remove and use whatever default MS drivers work, i dont know.
Thanks again for your help.
Consider the following:
The bugchecks continue to report hardware / memory.
The RAM models were not seen on the QVL.
In an earlier post you were wondering if it were an operating system upgrade.
And in the most recent post you were wondering if it were a driver.
These are some options:
1) Test an earlier Windows version
a) Make a backup image using Macrium
b) Clean install Windows 1709 or 1803
c) Monitor for BSOD
d) Restore the image after evaluating
2) Use safe mode with networking for a week
a) Monitor for BSOD
3) Replace RAM with modules displayed on the QVL
I'm not sure I was clear with my question. Has the system ever crashed after it was Restarted and subsequently never gone through a sleep/wake cycle? My Haswell system would work fine after a Restart for hours or even days if I set it to never go to sleep. It only seemed to crash - at some random point - after it had previously gone through a sleep/wake cycle. It would often work fine for days even after multiple sleep/wake cycles. The problem turned out to be a flaky Seasonic PSU for my system. My guess is memory would get corrupted by a strange power situation but I don't know for sure.
Thanks for the suggestions.
Unfortunately I use this PC for work and cant really take it offline for any extended time frames for #1 and my work software doesn't run in Safe Mode. And considering i am planning on replacing the system come summer time I cant justify buying new memory to test it with.
Currently i am running Driver Verifier on each driver individually (other than the MS drivers) but i am not sure how long verifier should run for each driver before making the decision to move on to the next one. So far its been running on the first driver for the past 24 hours with no BSOD. It has been run through a few sleep modes in that time as well as heavy usage times.
So should i let Verifier run for 24/48/etc hours before moving to the next driver?
Thanks again
- - - Updated - - -
Yes it has crashed after clean restart and not going into sleep mode.
No, not each driver individually, but select multiple drivers, and if crash narrow the selection down.
Hard to tell for how long should you have verifier enabled, this is worse than a which hunt, since you got not BSOD.
It would be great if you can develop some pattern for crash to speed this process up.
For the first run there were 3 drivers listed as 'unknown' which is what i choose for the first run. I figured i would narrow it down by Manufacturer. My next set was going to be the AMD drivers, then intel, qualcomm, realtek and creative, then a final run with Rovi and Cace tech
LOL i would kill for a identifiable pattern to this issue.. at this point im almost resigned to say the hell with it and just deal with the BSODs until it's time for the new system... but i hate to give up on something lol
- - - Updated - - -
Ok so I got a BSOD Crash Dump on the 2nd set of Drivers through verifier (linking below). I will keep narrowing it down from there to see if i can find one specific but wanted to upload the newest dump since it apparantly worked the way it was supposed to this time....lol
BSOD Files - Google Drive
Prior Crash Files - Google Drive
Thanks again.
Hello, not bad!
MBfilt64.sys Audio Driver from Creative Technology Ltd.Code:DRIVER_VERIFIER_DETECTED_VIOLATION (c4) A device driver attempting to corrupt the system has been caught. 0: kd> lmvm MBfilt64 Browse full module list start end module name fffff801`42400000 fffff801`4240e000 MBfilt64 T (no symbols) Loaded symbol image file: MBfilt64.sys Image path: \SystemRoot\system32\drivers\MBfilt64.sys Image name: MBfilt64.sys Browse all global symbols functions data Timestamp: Thu Jul 30 20:40:32 2009 (4A7267B0) CheckSum: 0001634A ImageSize: 0000E000 Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4 Information from resource tables:
Time to update this driver, because it is responsible for bsod.
keep driver verifier enable for this driver even after updating to make sure update works!
I also noted that npf.sys caused 2 BSOD during the Verifier runs... apparantly it is part of WinPCap .. but that is not installed anywhere on my system that i can find so im not sure what is up with that
Crud just realized i didnt upload the Minidumps for the npf.sys crash.. updated on the google drive
BSOD Files - Google Drive
Yes, out of 4 dumps, 2 dumps refer to npf.sys and other 2 to audio driver.
If you continue to get bsods for other drivers, not related to above 2 then pointing a finger
at those drivers may be incorrect, and the real reason could be anything.
WinPCap (npf.sys) may be installed by network monitoring tools such as wireshark, nmap etc..
Quote