Any genius types here able to read and understand windows dump files?

My brothers built a pc with win7 loaded on it and it keeps getting stuck in an endless loop of blue screens from cold boot until it warms up, then it seems to run fine until you knock it off long enough to cool down again.

Anyhow, he’s got a windows dump file or .dmp file, any genius here able to do me a favor and open it up and see if they can find a clue as to what’s causing it please?

Any help would be much appreciated. Thanks.

Here’s a link to the dump file. Dump file

Thanks for taking a look, much appreciated.
I actually downloaded the windows debug tools myself last night, wasn’t as rediculous to use as I feared it might be. I got the impression it was memory trouble, how did you come to the conclusion that it was a graphics driver? I’m not doubting your judgement, just wondering if the info I extracted is different to yours somehow or I simply have mis-read it. He’s updated all drivers and bios several times over the last few months since he built it and achieved nothing unfortunately. This is what I got:

Microsoft Windows Debugger Version 6.12.0002.633 AMD64
Copyright Microsoft Corporation. All rights reserved.

Loading Dump File [C:\091810-20810-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRVc:\symbolshttp://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7600 MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16617.amd64fre.win7_gdr.100618-1621
Machine Name:
Kernel base = 0xfffff80002c1e000 PsLoadedModuleList = 0xfffff80002e5be50
Debug session time: Sat Sep 18 21:51:46.416 2010 (UTC + 1:00)
System Uptime: 0 days 0:08:25.431
Loading Kernel Symbols
……
…
…
Loading User Symbols
Loading unloaded module list
…

• Bugcheck Analysis *

Use !analyze -v to get detailed debugging information.

BugCheck 109, {a3a039d8956e2513, b3b7465ee7eaf719, fffff80002d78840, 1}

*** WARNING: Unable to verify timestamp for win32k.sys
*** ERROR: Module load completed but symbols could not be loaded for win32k.sys
Probably caused by : memory_corruption

Followup: memory_corruption

4: kd> !analyze -v

• Bugcheck Analysis *

CRITICAL_STRUCTURE_CORRUPTION (109)
This bugcheck is generated when the kernel detects that critical kernel code or
data have been corrupted. There are generally three causes for a corruption:

1. A driver has inadvertently or deliberately modified critical kernel code
   or data. See http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx
2. A developer attempted to set a normal kernel breakpoint using a kernel
   debugger that was not attached when the system was booted. Normal breakpoints,
   “bp”, can only be set if the debugger is attached at boot time. Hardware
   breakpoints, “ba”, can be set at any time.
3. A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
   Arguments:
   Arg1: a3a039d8956e2513, Reserved
   Arg2: b3b7465ee7eaf719, Reserved
   Arg3: fffff80002d78840, Failure type dependent information
   Arg4: 0000000000000001, Type of corrupted region, can be
   0 : A generic data region
   1 : Modification of a function or .pdata
   2 : A processor IDT
   3 : A processor GDT
   4 : Type 1 process list corruption
   5 : Type 2 process list corruption
   6 : Debug routine modification
   7 : Critical MSR modification

Debugging Details:

BUGCHECK_STR: 0x109

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: CODE_CORRUPTION

PROCESS_NAME: System

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 0000000000000000 to fffff80002c8e740

STACK_TEXT:
fffff880033695d8 0000000000000000 : 0000000000000109 a3a039d8956e2513 b3b7465ee7eaf719 fffff80002d78840 : nt!KeBugCheckEx

STACK_COMMAND: kb

CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
fffff80002d78997 - nt!B_TREE<_SM_PAGE_KEY,ST_STORE<sm_traits>::_ST_PAGE_ENTRY,4096,NP_CONTEXT>::BTreeSplitChild+157
[ 2b:2a ]
1 error : !nt (fffff80002d78997)

MODULE_NAME: memory_corruption

IMAGE_NAME: memory_corruption

FOLLOWUP_NAME: memory_corruption

DEBUG_FLR_IMAGE_TIMESTAMP: 0

MEMORY_CORRUPTOR: ONE_BIT

FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT

BUCKET_ID: X64_MEMORY_CORRUPTION_ONE_BIT

Followup: memory_corruption</sm_traits>

Many thanks. I’ll drop him a mail to clean out his graphics drivers properly and install a new set.

Already run through memory compatibility with him, looks good to me, they’re listed. I’ll get him to run memtest x86 if updating the graphics drivers doesn’t work.

What’s weird about this, once the machine is up to temperature it will run fine, no crashes, no bsod, totally stable, he ran it for over a month letting it hibernate rather than shut down and not one problem. As soon as he switched it off again, the problem returned from a cold boot.

Thanks for your input guys, once again, it’s all appreciated. He’s a PAT tester by trade so he knows what he’s doing electrically, it’s just the business of pinning the fault down that’s a pain in the behind as usual.

He’s pulled the graphics card and switched it for another first to see if that solves the problem, we think as Lancer does that it’s most likely hardware due to the cold start issue. I agree with you FF that it would be unwise to open anything up seeing as all the parts are only a couple of months old so are under warranty.

It’s looking good so far, with any luck that might be it, but best not speak too soon

Thanks.

Well, he switched graphics cards and drivers, didn’t help unfortunately. So he switched power supplies, that seems to have done the job. Cold boot it again tomorrow and see what happens, if it boots fine again chances are that’s the culprit.

Brand new Enermax, not some cheap garbage either, really surprised as I’ve always sworn by them for my own builds and my old alienwares came fitted with them to. What’s the bet they’ve switched over to some cheap arse supplier for their lower range units just to save a few bucks.