BSOD issue with fresh install (minidump in attachment)

about a month ago i have build my dad a new PC, now this wasn't my first build, nor my first install so generally i know what i'm doing .

The problem he keeps having is that during normal computer use he gets a (from my point of view) random BSOD on Vista ultimate x64, now sadly i'm no expert on these type of issues, but after googling around abit i haven't managed to fix it yet. At first it seemed to be a problem with NOD32, the virus scanner, but de-installing that didn't fix it.

He doesn't know a thing about computers, so when i try to get out of him what happend before the BSOD i don't get any usefull information, apart from that aparently it was *heavy* use, aka internet open, music and email. Generally that is all he uses it for, allong with some photo viewing and video viewing.
The computer it self contains:
CPU: E8400
mobo: Asus P5Q pro
RAM: 4gb 1000 Mhz cas 5 g.skill
GPU: Ati Radeon 4680
HDD: 1x 320 gb seagate barracude 7200.10
PSU: OCZ 500 watt stealthxtreme

now i've set up the ram accordingly in the BIOS, so i'm quite certain it isn't a stability issue, since it used to be my old PC (apart from the HDD, PSU and GPU). I myself never had any issues with that pc, apart from an old ATI crossfire bugg that has long been resolved.
I hope i gave enough information and if not i hope i can provide more.

4 minidumps with 4 very different issues, at least on the surface. Unfortunately, this one virtually proves the machine has a hardware problem: Mini050109-01.dmp. Hence, troubleshooting the other 3 on the assumption that they're possibly related to software is perhaps a bit overly optimistic. Suggestions:

1) Make sure you're not overclocking and that the cooling is adequate. Run memtest and prime95 for days if necessary. Reseat all connectors and try to (safely) remove as much dust as possible... all the things that are generally done when an unknown hardware problem is suspected.

2) Run CHKDSK /R on the HDD. One of the crashes is in NTFS.

3) Update the video driver. Mini050309-01.dmp ostansibly points to atikmdag.sys

4) Remain methodical and work with the worst/biggest issue as the highest priority - the hardware.



=============================================
To explain why Mini050109-01.dmp virtually proves a hardware problem, here is the code which the machine was executing at the time of the crash:

nt!CmpGetNameControlBlock+0x11d:
fffff800`02304545 0000 add byte ptr [rax],al ds:e390:fffff880`00020000=??

OK, so we were in a function called CmpGetNameControlBlock at an offset of 0x11d. The actual instruction being executed at the time of the crash was 0000 (highlighted in red) which when interpreted maps to the 'add' mnemonic in green.

Let's see what the actual NTOSKRNL code looks like at that location. I'll start the disassembly a few bytes further back - at offset 0x110 instead of 0x11d:

0: kd> u nt!CmpGetNameControlBlock+0x110
nt!CmpGetNameControlBlock+0x110:
fffff800`02304538 00488d add byte ptr [rax-73h],cl
fffff800`0230453b 7ef8 jle nt!CmpGetNameControlBlock+0x10d (fffff800`02304535)
fffff800`0230453d 66443b6718 cmp r12w,word ptr [rdi+18h]
fffff800`02304542 0f859b000000 jne nt!CmpGetNameControlBlock+0x1bb (fffff800`023045e3)
fffff800`02304548 381f cmp byte ptr [rdi],bl
fffff800`0230454a 0f84aaedf8ff je nt! ?? ::NNGAKEGL::`string'+0x8b28 (fffff800`022932fa)

You can see that there is no instruction which corresponds to '0000' in its entirety, but at 0xfffff800`02304542 there's an instruction whose second half is all zeros. Instead of executing this:

jne nt!CmpGetNameControlBlock+0x1bb

...the hardware erroneously tried executing only part of that function because it started 3 bytes too far, and the machine code starting there has an entirely different and inapplicable meaning:

add byte ptr [rax],al

In effect, the hardware was executing code which doesn't exist. Somehow the instruction pointer went astray by a few bytes - a condition known as "instruction pointer misalignment" - and it is almost a definitive smoking gun for a hardware problem.

To use one common analogy, it's like the winder motor of an old film camera exposing the adjacent halves of two frames of film, instead of uniformly advancing the film one whole frame at a time with every winding operation. (Digital photography will soon make this analogy entirely obsolete )

hmm that is quite odd, before i gave the Mobo CPU and RAM to my dad, i had it overclocked, but under safe voltages, and safe temperature limitations. Now i've completely resetted the BIOS to default, and only set the RAM to the needed settings.
The GPU drivers are 9.3, which is about the latest version you can get afaik (maybe 1 or 2 newer versions). I'll indeed do a memtest first, and a stability test later, to see if the machine can still handle the load.
Is it possible, that due to overclocking i have weakend the CPU slightly, such that the automatic Vcore setting in the bios does not give enough volts for the CPU to work on stock settings?

Edit: well i think i might have found the crook, it's a program called Six Engine, that got installed with the Asus install disk.
I never used it because i overclocked my board and cpu, so it disabled it self, but after looking into it, and using CPU-Z to check some settings i found some disturbing things.
It has several *power saving* modes, and one performance mode, which i set to automatic. So it would choose what mode was most suited for the situation.
After downloading and opening CPU-Z i noticed that it was only giving the CPU 0.92 Vcore, which is lower then i have ever even concidered running a CPU, even with speedstep enabled (a feature to reduce the CPU clock drasticly). Then i used intel burn test to check for stability, and realtemp to keep monitor of my temperatures. The system instantly gave the CPU 1.17 Vcore, instead of the 0.92. If it comes out stable i will do a memtest, and if that comes out stable i'll de-install the six engine program to see if the error ever returnes.

Elightos said:

Edit: well i think i might have found the crook, it's a program called Six Engine, that got installed with the Asus install disk.
I never used it because i overclocked my board and cpu, so it disabled it self, but after looking into it, and using CPU-Z to check some settings i found some disturbing things.
It has several *power saving* modes, and one performance mode, which i set to automatic. So it would choose what mode was most suited for the situation.
After downloading and opening CPU-Z i noticed that it was only giving the CPU 0.92 Vcore, which is lower then i have ever even concidered running a CPU, even with speedstep enabled (a feature to reduce the CPU clock drasticly). Then i used intel burn test to check for stability, and realtemp to keep monitor of my temperatures. The system instantly gave the CPU 1.17 Vcore, instead of the 0.92. If it comes out stable i will do a memtest, and if that comes out stable i'll de-install the six engine program to see if the error ever returnes.

Click to expand...

Good luck with it

well after a very long memtest, and a decent CPU stress test, they both came back stable.
I've uninstalled six engine and hope that my dad won't get a BSOD again :D.