BSOD - any ideas to solve it?

Hi,

I built my Core2 machine about 4-5 months ago and Vista64 Ultimate has been no problem. All of a sudden the other morning I found it idling with no O/S running. I rebooted and all day it kept cutting out every 30-60 minutes. I can't find any rhyme or reason or isolate to any specific actions. I looked in device manage and it had a ! by the display adapters icon and something else that's now gone from the list UBS, SMU or something (not USB adapters). I reinstalled the video card adapter driver from CD and pulled out the card and plugged it back in and thought I was fixed. After about 8 hours it happened again so I uninstalled AVG free because it said it was corrupted (probably just the definitions). This morning I found the machine idling again.

I can't read the blue screen fast enough other than to read SYSTEM_SERVICE_EXCEPTION. Windows update had been doing updates (I was unaware 'til yesterday) and other than AVG nightly updates, there is nothing new on the machine recently.

The hardware is straightforward and the video card is the only card on the system. I have 4 matched 1 GB sticks of RAM and a great set of fans. The video card is an Asus EAH3450 - rather simple card w/only a heat sink though.

How can I even go about tackling this isuue? Is there software that does diagnostics or is it endless guessing?

Thanks guys.

Every time the OS crashes it creates a DMP file in the \Windows\minidump directory. That "dump" file is a summary of the software conditions at the time of the crash. Analysis of the dump(s) can frequently help to pinpoint the cause of software-related crashes.

If you copy the latest few DMP files from that folder to a different location, then zip them up and upload the zip file, someone may be able to tell you why the machine is crashing.

Thanks H2SO4!

Attached is a zip with the first and last three dump files. Is there a program to view them in or how do you understand the info they offer?

Also, on restart (just before) I found that the message window provided this info:

Is there a nugget of useful info in any of that?

Thanks guys!

This is how to analyse the dumps:

http://www.vistax64.com/tutorials/221510-crash-dumps-analyse-bugcheck-process.html

However, I'd suggest not bothering with these particular dumps as the situation they depict is quite complex. The same memory is being corrupted over and over, except I'm not sure whether it's because your RAM (or other hardware) is unreliable, or because of a wild write from an errant driver.

To test the second theory, try running this from an elevated (run as admin) CMD prompt every time after the machine boots:

What that will do is enable some additional scrutiny of drivers' actions and perhaps make the next minidump more informative. (The /volatile switch makes the command take hold straight away, but it'll go away after a reboot unless it's manually invoked again.)

Thanks again.

I ran the verifier /volatile /flags 0x80 /driver * command and am waiting.

I also installed dbg_amd64_6.11.1.404.msi and carefully followed your directions, but I get the attached 32 bit error mssg.

My machine is running a Core2 Duo and Vista64 Ultimate, so I believe I have the right debugger.

Am I doing something else wrong?

smarsh said:

Thanks again.

I ran the verifier /volatile /flags 0x80 /driver * command and am waiting.

I also installed dbg_amd64_6.11.1.404.msi and carefully followed your directions, but I get the attached 32 bit error mssg.

My machine is running a Core2 Duo and Vista64 Ultimate, so I believe I have the right debugger.

Am I doing something else wrong?

Click to expand...

Just punch in that verifier command every time the machine reboots. The next crash that happens after that may result in a more useful minidump.

Re your debugger issues, I'm guessing the error you get when you try to run WinDBG is accompanied by a WinSxS error in the event log. Something that's needed may be missing from your machine's \windows\WinSxS folder. Otherwise, the download may have been truncated somehow and the windbg executable itself is corrupted. That's very unlikely, though, because the installer package is verified during installation.

In any case, these dumps are not good for practising. The situation they describe is relatively complex.

H2SO4 said:

In any case, these dumps are not good for practising. The situation they describe is relatively complex.

Click to expand...

THANK YOU SO MUCH H2SO4 for your support!

I have been typing that command prompt line in almost every time it reboots and have some dump files since. But I don't understand your last post. Are you saying that despite collecting the files they are of no use or that w/o that program running they are of no use or what?

I'm just very stuck on this because I have no place to turn for help that I trust other than here. I built the machine easily with my limited knowledge and it ran fine. I don't trust any local repair place to have the skills to find the issue, so any direction you can provide is truly appreciated.

smarsh said:

H2SO4 said:

In any case, these dumps are not good for practising. The situation they describe is relatively complex.

Click to expand...

THANK YOU SO MUCH H2SO4 for your support!

Click to expand...

No problem at all

smarsh said:

I have been typing that command prompt line in almost every time it reboots and have some dump files since.

Click to expand...

OK, can you zip up and upload the latest dumps?

smarsh said:

But I don't understand your last post. Are you saying that despite collecting the files they are of no use or that w/o that program running they are of no use or what?

Click to expand...

There is more than one topic in that thread of conversation:

- The first set of minidumps you uploaded does not allow me to definitively pinpoint a cause for the BSoDs even though all of them suggest the same pattern. The "verifier" command makes the OS pay closer attention to what drivers are doing which can result in more useful memory dumps (sometimes). Hence, I'm most interested to see any minidumps generated from crashes after verifier was activated.

- Your inability to run WinDBG may not be important in this instance unless you want to make a hobby out of dump analysis in the future. With respect, your crash patterns suggest an error condition whose complexity is beyond analysis by those new to memory dumps.

smarsh said:

I'm just very stuck on this because I have no place to turn for help that I trust other than here. I built the machine easily with my limited knowledge and it ran fine. I don't trust any local repair place to have the skills to find the issue, so any direction you can provide is truly appreciated.

Click to expand...

I understand. The critical first objective is to try to figure out - based on the minidumps - whether the crashes are likely caused by hardware or software. The information in the first batch of minidumps is inconclusive on that score, which is why I'd like to see whether enabling (driver) verifier provides additional insight.

Thanks again - hopefully most of the dumps in this were created after running the command line command...

smarsh said:

Thanks again - hopefully most of the dumps in this were created after running the command line command...

Click to expand...

Gimme a couple of days with this one, OK? It requires mental cycles that I can't spare in the short term

In the meantime, you should try updating as many of these drivers as you can, especially the older ones, and remove any of them that you don't absolutely need:

fffffa60`00a05000 fffffa60`00a49000 mv61xx Tue Jun 10 20:25:06 2008
fffffa60`02f5b000 fffffa60`02f6e000 L1E60x64 Tue Jul 01 18:28:40 2008
fffffa60`02f90000 fffffa60`02f98000 ASACPI Tue Oct 31 13:09:12 2006
fffffa60`0300d000 fffffa60`035d8000 atikmdag Tue Jun 03 13:50:43 2008
fffffa60`04603000 fffffa60`04765580 RTKVHD64 Tue May 20 20:00:27 2008
fffffa60`049a4000 fffffa60`049ab000 AsIO Mon Dec 17 20:11:49 2007