Debugging my BSOD

[Derrn]

I've been trying to play Assassins Creed: Revelations lately but every time I open I get a BSOD. As far as I can tell I only get it with this program. Debugged with WinDbg and got:

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 124, {0, fffffa8008085038, 0, 0}

Probably caused by : hardware

Followup: MachineOwner

---------

1: kd> !analyze -v

*******************************************************************************

* *

* Bugcheck Analysis *

* *

*******************************************************************************

WHEA_UNCORRECTABLE_ERROR (124)

A fatal hardware error has occurred. Parameter 1 identifies the type of error

source that reported the error. Parameter 2 holds the address of the

WHEA_ERROR_RECORD structure that describes the error conditon.

Arguments:

Arg1: 0000000000000000, Machine Check Exception

Arg2: fffffa8008085038, Address of the WHEA_ERROR_RECORD structure.

Arg3: 0000000000000000, High order 32-bits of the MCi_STATUS value.

Arg4: 0000000000000000, Low order 32-bits of the MCi_STATUS value.

Debugging Details:

------------------

BUGCHECK_STR: 0x124_GenuineIntel

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 0

STACK_TEXT:

fffff880`031a86f0 fffff800`03128c59 : fffffa80`08085010 fffffa80`06a31680 00000000`0000000a 00000000`00000000 : nt!WheapCreateLiveTriageDump+0x6c

fffff880`031a8c10 fffff800`03008f57 : fffffa80`08085010 fffff800`030832b8 fffffa80`06a31680 00000000`00000000 : nt!WheapCreateTriageDumpFromPreviousSession+0x49

fffff880`031a8c40 fffff800`02f705d5 : fffff800`030e4ae0 00000000`00000001 fffffa80`0795e840 fffffa80`06a31680 : nt!WheapProcessWorkQueueItem+0x57

fffff880`031a8c80 fffff800`02eed001 : fffff880`0109ae00 fffff800`02f705b0 fffffa80`06a31600 00000000`00000000 : nt!WheapWorkQueueWorkerRoutine+0x25

fffff880`031a8cb0 fffff800`0317dfee : 00000000`00000000 fffffa80`06a31680 00000000`00000080 fffffa80`06a1f040 : nt!ExpWorkerThread+0x111

fffff880`031a8d40 fffff800`02ed45e6 : fffff880`02f64180 fffffa80`06a31680 fffff880`02f6efc0 00000000`00000000 : nt!PspSystemThreadStartup+0x5a

fffff880`031a8d80 00000000`00000000 : fffff880`031a9000 fffff880`031a3000 fffff880`031a7d90 00000000`00000000 : nt!KxStartSystemThread+0x16

STACK_COMMAND: kb

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: hardware

IMAGE_NAME: hardware

DEBUG_FLR_IMAGE_TIMESTAMP: 0

FAILURE_BUCKET_ID: X64_0x124_GenuineIntel_PROCESSOR_BUS_PRV

BUCKET_ID: X64_0x124_GenuineIntel_PROCESSOR_BUS_PRV

Followup: MachineOwner

---------

1: kd> !cpuinfo

CP F/M/S Manufacturer MHz PRCB Signature MSR 8B Signature Features

1 6,15,11 GenuineIntel 2399 000000b600000000 211b3ffe

1: kd> !errrec fffffa8008085038

===============================================================================

Common Platform Error Record @ fffffa8008085038

-------------------------------------------------------------------------------

Record Id : 01ccd40c37bf26c4

Severity : Fatal (1)

Length : 928

Creator : Microsoft

Notify Type : Machine Check Exception

Timestamp : 1/16/2012 5:03:50

Flags : 0x00000002 PreviousError

===============================================================================

Section 0 : Processor Generic

-------------------------------------------------------------------------------

Descriptor @ fffffa80080850b8

Section @ fffffa8008085190

Offset : 344

Length : 192

Flags : 0x00000001 Primary

Severity : Fatal

Proc. Type : x86/x64

Instr. Set : x64

Error Type : BUS error

Operation : Generic

Flags : 0x00

Level : 0

CPU Version : 0x00000000000006fb

Processor ID : 0x0000000000000000

===============================================================================

Section 1 : x86/x64 Processor Specific

-------------------------------------------------------------------------------

Descriptor @ fffffa8008085100

Section @ fffffa8008085250

Offset : 536

Length : 128

Flags : 0x00000000

Severity : Fatal

Local APIC Id : 0x0000000000000000

CPU Id : fb 06 00 00 00 08 04 00 - bd e3 00 00 ff fb eb bf

00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00

00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00

Proc. Info 0 @ fffffa8008085250

===============================================================================

Section 2 : x86/x64 MCA

-------------------------------------------------------------------------------

Descriptor @ fffffa8008085148

Section @ fffffa80080852d0

Offset : 664

Length : 264

Flags : 0x00000000

Severity : Fatal

Error : BUSL0_SRC_ERR_M_NOTIMEOUT_ERR (Proc 0 Bank 0)

Status : 0xf200084000000800

As far as I can tell it seems to be a CPU problem(?) but that's about all I know. I've been running Prime95 for about 2 hours now and all four cores are at 75-80ºC at 100% load and haven't come across any issues as far as I can tell (so far). Can anyone tell me what the problem is? I'd very much appreciate it.

My System:

Intel Core 2 Quad Q6600

2x4GB 1333mhz DDR3 RAM

ASUS P5G41T-M LX

ATI HD 5970

650W Corsair PSU

Win7 64-bit

I'm aware I'm probably bottlenecking my video card pretty badly, I've been planning to update the rest of it but haven't had the funds.

EDIT: Sorry in advance if this is in the wrong forums, wasn't sure where to post.

[MANEMAN]

Use BlueScreen View for a better analysis.

http://www.nirsoft.net/utils/blue_screen_view.html

John.

[AceInfinity]

Blue screen view is notorious for pointing towards the NT Kernel module, which is virtually never the case, so it's a harder program to debug with in my opinion because of that reason. If you try to dissasemble the instructions in the stack trace with a program like WinDbg, it's a lot better in my opinion. Speaking from personal preference, but the only reason NT Kernel shows up as the culprit is becuase it gets sent all the bad data before the crash gets initiated, and the actual problem is based on the last few referenced items in the stack. So if the exception was raised by the kernel itself trying to utilize that bad data, it's going to be the last thing known before the crash.

[MANEMAN]

Blue screen view is notorious for pointing towards the NT Kernel module

Can you point us towards any written evidence of this notoriety ?

John.

[AceInfinity]

Evidence? It's been mentioned by lots of other reputable BSOD analysts as well as myself for quite a while. Take a look at some of the BSOD's analyzed on SevenForums by some of the most recognized BSOD analysts. It's not the cause though, I can guarantee that.

I've seen it been mentioned as the "cause" by countless BSOD crash dumps that i've personally analyzed too.

Here's a few:

http://www.sevenforu...krnlmp-exe.html

http://www.sevenforu...lated-bsod.html

The NT Kernel handles everything, so it deals with lots of the bad data it's sent, and the way debuggers work is by analysis of the stack trace. So if found that the NT Kernel symbol is the last item in the stack, it's going to point to that as the cause.

http://www.techsupportforum.com/forums/f299/solved-driver-power-state-failure-bsod-592946.html#post3395463

I had a great link showing blue screen view blaming the NT kernel more than most other debuggers....

[MANEMAN]

Blue screen view is notorious for pointing towards the NT Kernel module

It's been mentioned by lots of other reputable BSOD analysts as well as myself for quite a while

Which reputable BSOD analysts ? Where is the evidence that says Blue Screen view is notorious for pointing towards the NT Kernel module ?

Show us ! Not just a load of links ! - A specific piece of proof.

[MANEMAN]

I had a great link showing blue screen view blaming the NT kernel more than most other debuggers....

You 'had', - or you 'have' a great link ?

When you find the link or any proof that "BlueScreenView" blames the NT Kernel more than most other debuggers, please post it here for us. I am quite sure that "Nir Sofer" of the IT company "Nirsoft" would also be interested to hear of your findings.

Most Microsoft MVP's speak highly of Nir Sofers work, Even Mark Russinovich "Technical Fellow" in the Platform and Services Division at Microsoft has toasted Nir's work both in his present position and as co-founder of "Winternals."

." Both have packaged their collections into suites. Nir Sofer has also created a way to package both his and Russinovich’s utilities together."

I cannot really believe someone of such high standing as Russinovich at Microsoft would allow, or be allowed to package & associate with something as bad as you describe. Also suprised that you as a "Microsoft MVP" seem to be singing from a different hymn sheet than Microsoft are.

Can you state as a Microsoft MVP exactly what your standing on this subject is after reading what I have had to say please.

John.

[AceInfinity]

I never said BlueScreenView is bad, i'm just saying that a real debugger like WinDbg is a LOT better for analyzing dumps, and used by very reputable BSOD analysts like usama, and jcgriff, as well as Captain J. Sparrow. All of which are MVP's like myself.

I HAD, a link though, which was a discussion between usama and jcgriff (Admin of TechSupportForum) about BlueScreenView showing the NT Kernel often as the cause.

[MANEMAN]

No. That is not in essence what you said.

To refresh your memory, you said:

"Blue screen view is notorious for pointing towards the NT Kernel module."

Is that statement true or false ? Is this noteriety of "BlueScreenView" worrying enough to tell people not to use it ?

There is really no point in naming Capt.Jack Sparrow, and the whole crew of "Pirates of the Carribean" if you cannot answer questions for yourself.

My question still hangs there awaiting an answer:

which was:

Can you state as a Microsoft MVP exactly what your standing on this subject is after reading what I have had to say please.

I HAD, a link though, which was a discussion between usama and jcgriff (Admin of TechSupportForum) about BlueScreenView showing the NT Kernel often as the cause.

BlueScreenView does not purport to show "Cause", so that cannot be the case. It offers events, and probabilities and suggests to the operator what he/she may find to be the "Cause", albeit in quite a simple way that even the layman can be given some understanding of the inner workings. The onus of "Cause" can only lie with the operator.

[AceInfinity]

Is that statement true or false ? Is this noteriety of "BlueScreenView" worrying enough to tell people not to use it ?

No no, I never mentioned don't use it. All debuggers name NT Kernel as the culprit, I was more stating a statement out there. As it may be fact, and maybe not. It all depends on your experience. You can have 1 red marble in a bag and have 1 blue marble in a bag. But say you were lucky enough to pick one, and place it back in the bag, and repeat that 10 times, and you only came out with a red marble 1 time out of all those trials. You could now assume that it's more "likely" to get a blue marble because of your experience. But someone else may have had an entirely different experience. All i'm saying is that i've heard it been mentioned by two of the most prolific BSOD analysts out there who had litterally handled more than 1000 different crash dumps in their lifetime i'm sure.

lol :) Capt.Jack Sparrow is an MVP not the one from the movie, unless you're just trying to joke around

I have ONLY used WinDbg to analyze a BSOD and actually try to solve it. I HAVE BlueScreenView, and i've taken a look, but based on my comparison, whether I find WinDbg more navigational or for any other reason, I just believe that it's better suited for the job as it was designed specifically by a team of developers that virtually created the errors and exceptions that get called upon in a BSOD based on kernel-mode events that happen in a users machine.

That's my opinion so far.

[MANEMAN]

No no, I never mentioned don't use it.

You surely implied as much when you said: "If you do anything that I have not asked you to do, you are only puting your own system at risk, because now you're just on your own doing trial and error."

So you are saying that anyone who has a BSOD should not use "BlueScreenView" as they are putting their system at risk, because they are working on their own, and should not do so without your guidance. Your words not mine.

Barnes Wallis invented, and developed the bouncing bomb by means of trial and error, Alan Turin broke the Enigma Code partly by means of trial and error. Trial and error has it's place in the quest for knowledge.

You said originally that "Blue screen view is notorious for pointing towards the NT Kernel module."

You now say "All debuggers name NT Kernel as the culprit" So we can now assume that the noteriety which earlier you so heavily placed solely on the shoulders of "BlueScreenView" has had a change of balance in your perception. The change it seems running in Parallel with whatever viewpoint suits you at the time. (Shifting the goalposts to suit yourself.)

I will analyse this BSOD for you if you post your crash dump in the forum here.

Very generous of you. It is a good thing to give up ones time to help others.

There are of course times within the confines of a forum,or fellow forum members that we must all move outside of it's boundaries to seek answers and solve problems. And I for one would be pleased to suggest using "Shyam Sasandrin's" excellent "SF Diag Tool" and having it's output diagnosed by someone else.

"don't do ANYTHING while i'm in the review process as solving BSOD's requires patience, and a logical order of operations."

And back in the real world Auntie Mabel has little or no patience, her world as far as the computer is concerned has no logical order, and she just wants her computer working again. So we reinstall the operating system just to shut her up.

93% of computer users browse the web and write a letter now and again. The other 7% have some knowledge of computers. When Tablet PC's grab a real strong hold of the market 1% of them will still have a job in the IT industry, the other 6% will be viewed by the general public in much the same way as we now view Garage Mechanics. Computers as a hobby will fall by the wayside much the same way as electronics has.

Everyone will still go on spouting Cr**

All together now.

There's no business like sh......................

John.

[AceInfinity]

You surely implied as much when you said: "If you do anything that I have not asked you to do, you are only puting your own system at risk, because now you're just on your own doing trial and error."

This quote is somewhat irrelevant as that was meaning towards him doing anything from what I suggested after viewing his BSOD crash dump. I did not suggest for him not to do anything up until what he's done so far, nor did I say that he has done anything that I did not ask him to do because I arrived on this forum itself much after the time he posted his thread here.

And I for one would be pleased to suggest using "Shyam Sasandrin's" excellent "SF Diag Tool" and having it's output diagnosed by someone else.

I myself created a tool much more advanced than SF Diag Tool however it's specific to Windows 7 system analysis only.

Edit: Take a look..

Edit2: Added the program to the attachments below.

Note: Pressing the "Windows" button on my application generates the BIGGEST log, so it may take some time depending on how many windows updates and hotfixes you have on your machine...

And back in the real world Auntie Mabel has little or no patience, her world as far as the computer is concerned has no logical order, and she just wants her computer working again. So we reinstall the operating system just to shut her up.

Some BSOD's don't occur and are solved simply by reinstalling the OS though :lol:

So that poses the question, would you rather find out what's wrong with your system, or hope and pray that something like a System Recovery does the fix for you? If it doesn't, then you're back to square one.

W7 Diag Tool.zip

[AceInfinity]

Can't edit my post anymore, so i'm forced to write a new one, but the program I made currently has a lot more features in the to-be-released version specific for retrieving information that may be useful for troubleshooting crashes.

[bludgard]

I'd like to get the dump files. There could be a comparison. The BSOD wars. Sounds exiting....

I'll grab the popcorn and beer fo eryboody.