Random Crashes (still)

dangfx

Gawd
Joined
May 2, 2001
Messages
707
I have just put together a brand new system (specs below) with a fresh install of WinXP Pro, SP2. but i keep getting one of two things: this BSOD, or just lock-ups. Both happen at completely random points. Sometimes after the machine has been on for hours, or days, sometimes when it just gets past the "welcome" screen after boot.

Here is the BSOD when it gives me one:
Code:
MACHINE_CHECK_EXCEPTION
........
.............
..................
STOP: 0x0000009C

I've checked around, but no real solutions can be found. MS's KB article doesn't say much on how to fix it.

any ideas? thanks in advance...
:(

Specs:
Asus A8N-E revision 2, bios 1008. (I have also tried with all other BIOSs. Drivers are 6.55. I have also tried the 6.66 drivers and they were very unstable)
AMD X2 4400+
2GB (1GB stick x 2) Corsair Value Select VS1GB400C3 (in first and third DIMM slots, A1 and B1)
BFG 7800GTX PCI-E (78.03 drivers from nvidia)
Antec TruePower 550 EPS12V SSI Server-rated PSU
Maxtor DiamondMax 10 SATA 200gb (on 1st SATA channel; have also tried on the other 3 channels)
Creative 52x CD-ROM (IDE Primary master)
Plextor 716AL DVD/CD burner (IDE, Secondary master)
Plextor 16/10/40A CD burner (IDE, Secondary slave)
Floppy drive
2 case fans + 1 CPU fan (AMD retail box HSF)
Windows XP Pro, SP2 (have also tried it with XP x64 Edition for a bit; problem persists)

-everything is running at stock speeds, no overclocking.
-Windows is completely updated (w/ SP2).
-I have not installed the nvidia IDE drivers, as people report more/other problems when using them.
-temps according to the bios are between 35-39 degrees (celcius).
-everything on auto in the bios except for ram which i bumped up to 2.75v.
-ran memtest86+ for about 2 hours, found no erros. i also switched out the ram for 2 other brands, problem didnt' go away.
-ran the diagnostic util for my Maxtor hdd, found no errors
 
SYMPTOMS
You may receive the following Stop error message:
STOP: 0x0000009C (0x00000004, 0x00000000, 0xb2000000, 0x00020151)
"MACHINE_CHECK_EXCEPTION"
The four parameters inside the parentheses may vary.
CAUSE
This behavior occurs because your computer processor detected and reported an unrecoverable hardware error to Windows XP. To do this, the processor used the Machine Check Exception (MCE) feature of Pentium processors or the Machine Check Architecture (MCA) feature of some Pentium Pro processors. The following factors may cause this error message: • System bus errors
• Memory errors that may include parity or Error Correction Code (ECC) problems
• Cache errors in the processor or hardware
• Translation Lookaside Buffers (TLB) errors in the processor
• Other CPU-vendor specific detected hardware problems
• Vendor-specific detected hardware problems

STATUS
This behavior is by design.
MORE INFORMATION
A machine check exception occurs when Windows XP and your hardware platform cannot recover from a hardware error so that the system can continue to run successfully and reliably. More specific diagnosis of machine check exceptions is difficult, and there is no general solution. Contact your hardware manufacturer or a computer hardware technician for help with troubleshooting this issue.

Machine check exceptions are frequently caused by one of the following conditions: • You are running the processor or mainboard beyond its specifications. For example, you are overclocking the processor or bus. We recommend that you run your hardware at the manufacturer-rated speeds.
• Noisy power, overstressed power strips, outmatched power supplies and failing power supplies can destabilize your computer. Make sure that you have a stable, reliable power supply to your computer.
• Extreme thermal conditions caused by the failure of cooling devices such as fans may damage your computer. Make sure that your cooling devices are all working.
• You have damaged memory or memory that is not the correct type for your computer. If you recently changed the memory configuration, revert to the previous configuration to determine what is wrong. Make sure that you are using the correct memory for your computer.
 
Understanding and Troubleshooting Reboots and Blue Screens[/URL]

Is there a "louder" way to get an idea accross, besides a sticky? I'm surprised at how often I have to post a pointer.
 
Javelin3o4-
what you just copied and pasted is exactly what I linked to in MY post. If you had read what you yourself pasted, you'd see it doesnt give much (any) specific help.


mikeblas-
take a look at your link/that sticky, and please report back to me what in there solves/indicates my problem.

forgot to mention as well....
**No errors ever reported in the event viewer
**Hard disk has been chckdsk'd and degfrag'd
 
dangfx said:
mikeblas-
take a look at your link/that sticky, and please report back to me what in there solves/indicates my problem.

forgot to mention as well....
**No errors ever reported in the event viewer

The sticky explains how to get errors reported in the event viewer, and points out that you can capture a dump file. There's a link to a thread in the sticky where a couple of us have been reading through dumps and trying to offer help. It also explains how to read the bluescreen, and why complete information (eg, more than you've offered here) is required to make any sort of diagnosis.

Was it that the sticky wasn't clear enough on these points, or that it was too long for you to read completely? Please let me know how it might be improved.
 
mikeblas,
The sticky is clear enough, and the sticky was not too long.

However (as I mentioned) it doesnt really pertain to the problem posed above. Only, if you'd like the dump file (the sticky itself only expressed that a vendor would like this -- please tell me if you are experienced with anylizing dump files. but yes, a good idea would be to take it to Ranma_Sao), please let me know, and I will give it to you.

Also as I mentioned, there is nothing coming up in the event viewer, even though my Startup and Recovery box looks (and has always looked) exactly as it does in the sticky. (My assumption is that the crash/lockup happens before anything can be written to the log).

As for the BSOD, I provided what I thought was all the nessasary info. The parts I have ommited were the wordage (which is the same as every other BSOD) and the other parameters following the initial stop code, which indicate memory addresses. I ommitted these becuase I have never seen memory addresses helping in solving such a problem, especially like the one posed above. If you'd like these parameters, please let me know, and post 'em. (also, please tell me how you knowing these specific memory address will help you solve the problem. Now THAT would be a great thing to put in the sticky :) )
Regardless, your own sticky says:
"The number we are most interested in here is the first one:"
And that is what I posted. If there is more info from the BSOD that you need, please let me know.

lithium726,
I have tried running prime, but nothing out of the ordinary that I could see came up. Should I be looking for something specific?
 
In the sticky, I make the same offer to help as Ranma does:

mikeblas said:
Ranma_Sao has graciously offered to help debug dump files. In his post, he asks for very specific diagnostic information about the problem, and requsts that you understand his time limitations and ability to respond. I can make a simiar offer; if you can send along the same information that Ranma_Sao asks for, I'll be happy to take a look at the problem -- as my schedule allows.
The sticky also points out the importance of the rest of the parameters, several times. Like here:
mikeblas said:
Any driver can raise any stop code, so an article describing code 0x0000007E only pertains to your problem if it has the same parameters (the numbers after the stop code in the report), and the stop code was reported by the same module as mentioned in the article.
I guess I'll try to find the time to make those sections clearer.

The documentation on MSDN for your MACHINE_CHECK_EXCEPTION explains what each of the parameters means. The sticky links to the TOC entry which has all these check codes in numerical order.

The parameters for this check mostly pertain to registers in the Pentium Machine-Check Architecture, MCA. The involved registers and their flags are described in the IA-32 Intel Architecture Software Developer's Manual, Volume 3: System Programming Guide in chapter 14 and Appendix E. You can download this book in PDF form from the Intel website, or request it from the Intel literature center (sometimes -- the printed manuals seem to go in and out of availability).

Maybe, when you provide the parameters to the bugcheck error you received, we can figure out that the check was raised by access to a particular port or caused by a certain range of memory. Or, given a debug dump, we'll find evidence of a bad or mismatched device driver. Without either of those clues, we can only get as far as thinking you've either got bad RAM, a bad processor, a bad motherboard, or a driver problem.
 
ok, next time the BSOD happens, I will write down the parameters. I THINK (although not 100% sure) that these parameters are the same every time. Keep in mind, however, that the BSOD does not happen always. I'd say more often, the comp just locks up instantly. that MSDN article, while it gives a general explanation, doesnt offer how to fix the problem. Nor do similar MSDN/MSKB articles i've read. Really, the "MACHINE_CHECK_EXCEPTION" error seems to be Microsoft-ese for "something is wrong, but we cant tell you what."

In the meantime, would you mind if I emailed you the most recent .dmp file? Or is there a better way?

(btw, do you IM at all? i am on ICQ @ 101061167)
 
This is a HARDWARE problem. A Machine Check exception is where your CPU screamed and windows bugchecked the machine. It can be caused by:

Bad CPU/Bad Power Supply/Bad Mobo/etc... This is not a windows or software problem.

Having a dump file would do almost zero good in diagnosing this. I suggest you take each part out, and test it in isolation.

This posting is provided "AS IS" with no warranties, and confers no rights.
 
since this is a hardware issue and the CPU/RAM are testing out fine, im gonna put my money on a bum motherboard, unless you are severly underpowering this system.

is your videocard behaving normally? i had a bum card causing lots of crashes, but only when i would play FEAR for extended periods of time. it passed ATItool with flying colors. since this is happening randomly, im gonna say bad motherboard.
 
dangfx said:
that MSDN article, while it gives a general explanation, doesnt offer how to fix the problem. Nor do similar MSDN/MSKB articles i've read. Really, the "MACHINE_CHECK_EXCEPTION" error seems to be Microsoft-ese for "something is wrong, but we cant tell you what."

The parameters to the message tell you pretty specifically what's wrong. You can use the docs I referenced to decode what happened. Why it happened is a different issue, entirely.

Say we get the codes from you. They might indicate that on-processor cache failed a parity check. With a pretty good degree of certainty, I think we can decide that the processor itself is bad.

Perhaps the flags in the code indicate that there's a memory problem. That's a little harder. Like the bullet items in the KB article and MSDN suggest, such memory errors might becaused by any or multiples of a variety of problems. Perhaps you've got a bad module. Perhaps there's a capacitive load (from dust or other deturitis) on your motherboard that's affecting the signal -- sometimes. Perhaps you've got an iffy power supply that's injecting noise, or poor mains wiring that's doing the same.

Really, there's no way to tell. The processor has noticed the problem and halting, but it's not offering a diagnosis; it just describes the symptoms it observed. The OS can't fabricate data that it wasn't given.

dangfx said:
In the meantime, would you mind if I emailed you the most recent .dmp file? Or is there a better way?
Sure, send it along. Like Ranma says in that next note, the dump file is not as useful as it is for other kinds of bug checks. I'm expecting that the dump for this bug check will show me the codes that we need to look at what the processor reported. (And it looks like I'll need to know your processor's family and stepping and so on. I thought those were encoded in one of the parameters, but it looks like they're not.)

Since the processor can trip the exception at any time, it's not a software problem. However, if we can see that the processor is tossing the exception every time code writes data to a particular device, we might deduce that particular device is faulty because it is hurting the bus in response to the commands or data it received. Certainly not a software problem, but it does suggest the device is bad.
 
Ranma_Sao,
Yes, i think there was never a doubt that it was a hardware problem. unfortunately, there is no specific pointer as to WHICH piece of hardware is bad. I'm pretty sure the memory is fine, since i've tried sticking in 3 other kinds of ram, and the comp still produced the same error. That, and memtest86 reports zero errors for hours and hours of running. And yes, as i assumed, the .dmp file would seem to help little, if at all.
Unfortunately, I dont have another system to test out the parts in.

lithium726,
This is my second A8N-E. The first one had a bad network controller. Now, this one could also be bad, but I'd hate to switch it out again. I dont THINK i'm underpowering it. the Antec TruePower 550 is a very good PSU, it is EPS12V and is SSI-rated for server motherboards (i chose it just in case i get like a dual xeon later on). So unless it is outright bad, it should be more than fine. Other than my 7800GTX, nothing else in the system is too power-hungry. Is there a way to test my PSU via software? or another way?

mikeblas,
like i said, next time i get a BSOD, i will take note of the parameters. But also like i said, they happen less frequently than the instant lockups. I am pretty sure its not bad ram (see above) so lets hope the codes indicate something else.
Oh, what's your email?? ;)

here is my CPU info:

cpuz_shot.jpg
 
hmm.... does anyone think installing the new 6.70 chipset drivers from nvidia would help?

:confused:
 
well, still no BSOD, (but a few lockups). So, i decided to run prime95 again, even though i have done it before for hours and no errors found. but, i just run it today, and here's what i get.

does this mean:
A) My CPU is definately bad. i should of course get it replaced immediately.
B) This could mean my CPU is bad, but doesn't really confirm it. I shouldn't go crying to AMD right away.
C) These kind of errors are somewhat common. Its unlikely that my CPU is bad.

prime_shot.jpg



EDIT:
i also then ran the benchmark.... here's what i got (i do have background processes running):

prime_shot2.jpg
 
Certainly not C. I think the best way to get a definitive answer would be to ask the Prime95 folks themselves.
 
hmm..... are there any other good CPU tests? I've tried sisoft sandra, but that never gives me any errors.

also, anyone have any contacts for Prime95? i've checked http://www.mersenne.org, but they really only seem to be math guys, not computer guys....
 
Back
Top