Windows Vista x64 Sudden Shutdowns

[watling]

Hey peeps, i was advised to write a thread here as my friend said you are great with help out people with problems )

Basically i could be doing anything on my PC (games,word anything) and i can get shutdowns, the shutdown basically then goes into a blue screen and says "system service exception" it also says something about memory dump at the bottom of the page.

After all of that it restarts itself.

Once windows has come back onto the desktop i get this windows message:

Problem signature:

Problem Event Name: BlueScreen

OS Version: 6.0.6000.2.0.0.768.3

Locale ID: 2057

Additional information about the problem:

BCCode: 3b

BCP1: 00000000C0000005

BCP2: FFFFF80001EABD8B

BCP3: FFFFF9801566C8D0

BCP4: 0000000000000000

OS Version: 6_0_6000

Service Pack: 0_0

Product: 768_1

Files that help describe the problem:

C:\Windows\Minidump\Mini083008-01.dmp

C:\Users\Watling\AppData\Local\Temp\WER-57127-0.sysdata.xml

C:\Users\Watling\AppData\Local\Temp\WERBC2.tmp.version.txt

Read our privacy statement:

http://go.microsoft.com/fwlink/?linkid=501...mp;clcid=0x0409

Hope anyone has some advice on my issue thanks in advance

[Mr Snrub]

Do you have a memory dump file with today's date saved as C:\Windows\MEMORY.DMP ?

(I think the default for Vista is to produce kernel memory dumps, which was the "beginning dump of physical memory" message you saw at the bottom of the blue screen, but I might be wrong.)

If you have that file, copy & zip it up, then upload it somewhere like http://skydrive.live.com as a public file and give us the URL.

If not, then zip & upload any minidump*.dmp files in C:\Windows\Minidump instead - also prepare the system to create complete dumps in the future by following steps 2-3 under "Memory dump of the entire system" in the following post:

http://www.msfn.org/board/Creating-memory-dumps-t90244.html

[watling]

Do you have a memory dump file with today's date saved as C:\Windows\MEMORY.DMP ?

(I think the default for Vista is to produce kernel memory dumps, which was the "beginning dump of physical memory" message you saw at the bottom of the blue screen, but I might be wrong.)

If you have that file, copy & zip it up, then upload it somewhere like http://spaces.live.com as a public file and give us the URL.

If not, then zip & upload any minidump*.dmp files in C:\Windows\Minidump instead - also prepare the system to create complete dumps in the future by following steps 2-3 under "Memory dump of the entire system" in the following post:

http://www.msfn.org/board/Creating-memory-dumps-t90244.html

Hey thanks for your speedy response, ive looked in windows and i have a folder called "minidump" . The log file has todays date on it and ofc course the time it rebooted so ill upload that file for you so you can have a ganders at it )

EDIT**** Hmm actually when i try to zip it up it says "access is denied :S"

Edited August 30, 2008 by watling

[Mr Snrub]

You might need to copy the files somewhere first before you can zip them - I tend to use my desktop as a scratchpad for things like this, then delete them once done.

[watling]

You might need to copy the files somewhere first before you can zip them - I tend to use my desktop as a scratchpad for things like this, then delete them once done.

Hmm still no luck im afraid all i get is this message :

its also saying i cannot open it as i mnot an admin ?:SSS

Edited August 30, 2008 by watling

[Mr Snrub]

Strange, I just copied a minidump to my desktop and 7-zip was able to archive it from there... I did the following:

Start / Computer

Browse to C:\Windows\Mindump - click OK on prompt to get access

Select multiple minidump*.dmp files, right-click and select Copy

Show desktop, right-click and select Paste - files are now copied

With desktop copies of files selected, right-click and go to "7-zip / Add to archive..."

Did you MOVE the files by mistake, instead of COPYING?

If I try to create an archive of the minidumps in the C:\Windows\Minidump folder, then 7-zip reports an access denied error similar to your screenshot.

[watling]

Strange, I just copied a minidump to my desktop and 7-zip was able to archive it from there... I did the following:

Start / Computer

Browse to C:\Windows\Mindump - click OK on prompt to get access

Select multiple minidump*.dmp files, right-click and select Copy

Show desktop, right-click and select Paste - files are now copied

With desktop copies of files selected, right-click and go to "7-zip / Add to archive..."

Did you MOVE the files by mistake, instead of COPYING?

If I try to create an archive of the minidumps in the C:\Windows\Minidump folder, then 7-zip reports an access denied error similar to your screenshot.

YEY the copying and pasting thing was the trick, i was just dragging and dropping

Here is the link:

http://www.uploading.com/files/G5HM7KYH/Mi...008-02.zip.html

http://rapidshare.com/files/141355840/Mini083008-02.zip.html

And thanks again for your speedy responses

[Mr Snrub]

This is just a minidump, so maybe not enough to make a useful analysis - have you followed the procedure for generating complele memory dumps for future crashes?

Has the system been stable for a while, and this problem just started, or was it recently built (or upgraded maybe)?

Any overlocking in place at all?

Windows Updates installed up to date?

I notice SP1 is not installed - any reason?

Am I right in assuming the mainboard is an Asus P5E?

I see the BIOS version is 0203, but I can't get much joy from the Asus website to see what the most recent is - often the BIOS updates relate to CPU support and I see you have a quad-core which is guaranteed to be "kinda recent".

Windows Vista Kernel Version 6000 MP (4 procs) Free x64

Product: WinNt, suite: TerminalServer SingleUserTS Personal

Built by: 6000.16584.amd64fre.vista_gdr.071023-1545

Kernel base = 0xfffff800`01c00000 PsLoadedModuleList = 0xfffff800`01d9af70

Debug session time: Sat Aug 30 17:59:19.878 2008 (GMT+2)

System Uptime: 0 days 0:25:55.624

3: kd> !sysinfo machineid

Machine ID Information [From Smbios 2.4, DMIVersion 36, Size=2655]

BiosMajorRelease = 8

BiosMinorRelease = 12

BiosVendor = American Megatrends Inc.

BiosVersion = 0203

BiosReleaseDate = 10/11/2007

SystemManufacturer = System manufacturer

SystemProductName = P5E

SystemFamily = To Be Filled By O.E.M.

SystemVersion = System Version

SystemSKU = To Be Filled By O.E.M.

BaseBoardManufacturer = ASUSTeK Computer INC.

BaseBoardProduct = P5E

BaseBoardVersion = Rev 1.xx

3: kd> !sysinfo cpuinfo

[CPU Information]

~MHz = REG_DWORD 2405

Component Information = REG_BINARY 0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0

Configuration Data = REG_FULL_RESOURCE_DESCRIPTOR ff,ff,ff,ff,ff,ff,ff,ff,0,0,0,0,0,0,0,0

Identifier = REG_SZ EM64T Family 6 Model 15 Stepping 11

ProcessorNameString = REG_SZ Intel® Core2 Quad CPU Q6600 @ 2.40GHz

Update Signature = REG_BINARY 0,0,0,0,b3,0,0,0

Update Status = REG_DWORD 6

VendorIdentifier = REG_SZ GenuineIntel

MSR8B = REG_QWORD b300000000

IRQL_NOT_LESS_OR_EQUAL (a)

An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high.

This is usually caused by drivers using improper addresses.

If a kernel debugger is available get the stack backtrace.

Arguments:

Arg1: 0000000000000028, memory referenced

Arg2: 0000000000000002, IRQL

Arg3: 0000000000000000, bitfield :

bit 0 : value 0 = read operation, 1 = write operation

bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)

Arg4: fffff80001c8e3b0, address which referenced memory

TRAP_FRAME: fffff980113dc5e0 -- (.trap 0xfffff980113dc5e0)

3: kd> .trap 0xfffff980113dc5e0

3: kd> r

Last set context:

rax=0000000000000000 rbx=fffff80001c00000 rcx=0000000000000000

rdx=0000000000000000 rsi=fffff80001d69200 rdi=000000000000000a

rip=fffff80001c8e3b0 rsp=fffff980113dc778 rbp=0000000000000000

r8=fffff980113dc7c0 r9=fffff88003aef600 r10=fffffa80079661f0

r11=fffffa8007966120 r12=0000000000000000 r13=0000000000000000

r14=0000000000000000 r15=0000000000000000

iopl=0 nv up ei ng nz na pe nc

cs=0010 ss=0018 ds=0000 es=0000 fs=0000 gs=0000 efl=00010282

nt!MiFindNodeOrParent:

fffff800`01c8e3b0 48f7412800ffffff test qword ptr [rcx+28h],0FFFFFFFFFFFFFF00h ds:00000000`00000028=????????????????

3: kd> kv

*** Stack trace for last set context - .thread/.cxr resets it

Child-SP RetAddr : Args to Child : Call Site

fffff980`113dc778 fffff800`01c7cfe7 : 00000000`00000000 fffff800`01cd503a 42506650`01c00000 fffffa80`04ded000 : nt!MiFindNodeOrParent

fffff980`113dc780 fffff800`01cd576e : 00000000`00000000 00000000`000007ff 00000000`000018c0 fffff800`01d3d2a4 : nt!MiLocateAddressInTree+0x17

fffff980`113dc7b0 fffff800`01ce44fe : 00000000`00054ad8 fffffa80`04dedbc8 fffffa80`0785d060 00000000`00000000 : nt!MiIdentifyPfn+0x77b

fffff980`113dc850 fffff800`01fb3965 : fffffa80`04ded000 fffff980`113dcca0 fffff980`113dc918 00000000`00000000 : nt!MmQueryPfnList+0x13e

fffff980`113dc890 fffff800`01e38c9c : 00000000`00000000 00000000`00000000 fffffa80`04ded000 00000000`00000001 : nt!PfpPfnPrioRequest+0x115

fffff980`113dc8e0 fffff800`01ec06ac : 00000000`00000000 00000000`00000000 00000000`0222e940 fffff980`047d7501 : nt!PfQuerySuperfetchInformation+0x1db

fffff980`113dc950 fffff800`01c4d733 : fffffa80`0785d060 00000000`042faff0 00000000`03d023e0 00000000`00000000 : nt!NtQuerySystemInformation+0x11aa

fffff980`113dcc20 00000000`770d05da : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff980`113dcc20)

00000000`0222e898 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x770d05da

Crash occurred because CPU register RCX contained zero when it was meant to point to a memory address.

RCX was populated by RAX, which is also zero, if we scan back a little bit - but once we've jumped into a couple of functions it's not reliable to make assumptions on the register contents.

The STOP code here was 0xA, not 0x3B - which might indicate the bugchecks are different (possibly random) which could imply a hardware (or overheating/overclocking) problem.

If you take a look in the System event log are there a bunch of BugCheck event 1001 entries corresponding with each crash?

(Tip: Click on the column heading Source and wait until the "Sorting..." indicator has gone, then the events are sorted in alphabetical order.)

If you find there are a collection of these, what does it say the bugcheck code was for each? (No need to record the parameters, just the single main code like 0xA for the one above.)

[watling]

This is just a minidump, so maybe not enough to make a useful analysis - have you followed the procedure for generating complele memory dumps for future crashes?

Has the system been stable for a while, and this problem just started, or was it recently built (or upgraded maybe)?

Any overlocking in place at all?

Windows Updates installed up to date?

I notice SP1 is not installed - any reason?

Am I right in assuming the mainboard is an Asus P5E?

I see the BIOS version is 0203, but I can't get much joy from the Asus website to see what the most recent is - often the BIOS updates relate to CPU support and I see you have a quad-core which is guaranteed to be "kinda recent".

Windows Vista Kernel Version 6000 MP (4 procs) Free x64

Product: WinNt, suite: TerminalServer SingleUserTS Personal

Built by: 6000.16584.amd64fre.vista_gdr.071023-1545

Kernel base = 0xfffff800`01c00000 PsLoadedModuleList = 0xfffff800`01d9af70

Debug session time: Sat Aug 30 17:59:19.878 2008 (GMT+2)

System Uptime: 0 days 0:25:55.624

3: kd> !sysinfo machineid

Machine ID Information [From Smbios 2.4, DMIVersion 36, Size=2655]

BiosMajorRelease = 8

BiosMinorRelease = 12

BiosVendor = American Megatrends Inc.

BiosVersion = 0203

BiosReleaseDate = 10/11/2007

SystemManufacturer = System manufacturer

SystemProductName = P5E

SystemFamily = To Be Filled By O.E.M.

SystemVersion = System Version

SystemSKU = To Be Filled By O.E.M.

BaseBoardManufacturer = ASUSTeK Computer INC.

BaseBoardProduct = P5E

BaseBoardVersion = Rev 1.xx

3: kd> !sysinfo cpuinfo

[CPU Information]

~MHz = REG_DWORD 2405

Component Information = REG_BINARY 0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0

Configuration Data = REG_FULL_RESOURCE_DESCRIPTOR ff,ff,ff,ff,ff,ff,ff,ff,0,0,0,0,0,0,0,0

Identifier = REG_SZ EM64T Family 6 Model 15 Stepping 11

ProcessorNameString = REG_SZ Intel® Core2 Quad CPU Q6600 @ 2.40GHz

Update Signature = REG_BINARY 0,0,0,0,b3,0,0,0

Update Status = REG_DWORD 6

VendorIdentifier = REG_SZ GenuineIntel

MSR8B = REG_QWORD b300000000

IRQL_NOT_LESS_OR_EQUAL (a)

An attempt was made to access a pageable (or completely invalid) address at an interrupt request level (IRQL) that is too high.

This is usually caused by drivers using improper addresses.

If a kernel debugger is available get the stack backtrace.

Arguments:

Arg1: 0000000000000028, memory referenced

Arg2: 0000000000000002, IRQL

Arg3: 0000000000000000, bitfield :

bit 0 : value 0 = read operation, 1 = write operation

bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)

Arg4: fffff80001c8e3b0, address which referenced memory

TRAP_FRAME: fffff980113dc5e0 -- (.trap 0xfffff980113dc5e0)

3: kd> .trap 0xfffff980113dc5e0

3: kd> r

Last set context:

rax=0000000000000000 rbx=fffff80001c00000 rcx=0000000000000000

rdx=0000000000000000 rsi=fffff80001d69200 rdi=000000000000000a

rip=fffff80001c8e3b0 rsp=fffff980113dc778 rbp=0000000000000000

r8=fffff980113dc7c0 r9=fffff88003aef600 r10=fffffa80079661f0

r11=fffffa8007966120 r12=0000000000000000 r13=0000000000000000

r14=0000000000000000 r15=0000000000000000

iopl=0 nv up ei ng nz na pe nc

cs=0010 ss=0018 ds=0000 es=0000 fs=0000 gs=0000 efl=00010282

nt!MiFindNodeOrParent:

fffff800`01c8e3b0 48f7412800ffffff test qword ptr [rcx+28h],0FFFFFFFFFFFFFF00h ds:00000000`00000028=????????????????

3: kd> kv

*** Stack trace for last set context - .thread/.cxr resets it

Child-SP RetAddr : Args to Child : Call Site

fffff980`113dc778 fffff800`01c7cfe7 : 00000000`00000000 fffff800`01cd503a 42506650`01c00000 fffffa80`04ded000 : nt!MiFindNodeOrParent

fffff980`113dc780 fffff800`01cd576e : 00000000`00000000 00000000`000007ff 00000000`000018c0 fffff800`01d3d2a4 : nt!MiLocateAddressInTree+0x17

fffff980`113dc7b0 fffff800`01ce44fe : 00000000`00054ad8 fffffa80`04dedbc8 fffffa80`0785d060 00000000`00000000 : nt!MiIdentifyPfn+0x77b

fffff980`113dc850 fffff800`01fb3965 : fffffa80`04ded000 fffff980`113dcca0 fffff980`113dc918 00000000`00000000 : nt!MmQueryPfnList+0x13e

fffff980`113dc890 fffff800`01e38c9c : 00000000`00000000 00000000`00000000 fffffa80`04ded000 00000000`00000001 : nt!PfpPfnPrioRequest+0x115

fffff980`113dc8e0 fffff800`01ec06ac : 00000000`00000000 00000000`00000000 00000000`0222e940 fffff980`047d7501 : nt!PfQuerySuperfetchInformation+0x1db

fffff980`113dc950 fffff800`01c4d733 : fffffa80`0785d060 00000000`042faff0 00000000`03d023e0 00000000`00000000 : nt!NtQuerySystemInformation+0x11aa

fffff980`113dcc20 00000000`770d05da : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff980`113dcc20)

00000000`0222e898 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x770d05da

Crash occurred because CPU register RCX contained zero when it was meant to point to a memory address.

RCX was populated by RAX, which is also zero, if we scan back a little bit - but once we've jumped into a couple of functions it's not reliable to make assumptions on the register contents.

The STOP code here was 0xA, not 0x3B - which might indicate the bugchecks are different (possibly random) which could imply a hardware (or overheating/overclocking) problem.

If you take a look in the System event log are there a bunch of BugCheck event 1001 entries corresponding with each crash?

(Tip: Click on the column heading Source and wait until the "Sorting..." indicator has gone, then the events are sorted in alphabetical order.)

If you find there are a collection of these, what does it say the bugcheck code was for each? (No need to record the parameters, just the single main code like 0xA for the one above.)

Hi again, im sorry im not very bright with computers, but what i did find in the event log was this:

Which imho looks extremely wrong, what are your thoughts please

[Mr Snrub]

Not necessarily a problem - the startup & shutdown times are monitored for consistency, if it takes "longer than normal" then it might trigger these kind of diagnostic events - but for situations where hotfixes are installed or hardware is added, for example, the times may extend quite a bit for a one-off: the OS doesn't check for such exceptions and so reports it.

The easiest logs to look at are under Event Viewer / Windows Logs : Application & System

Any answers to the questions I posed?

This might provide a bit of background to the root cause, or at least flesh out the problem a little...

[cluberti]

I actually noticed something very interesting on the stack:

3: kd> k
Child-SP		  RetAddr		   Call Site
fffff980`113dc498 fffff800`01c4da33 nt!KeBugCheckEx
fffff980`113dc4a0 fffff800`01c4c90b nt!KiBugCheckDispatch+0x73
fffff980`113dc5e0 fffff800`01c8e3b0 nt!KiPageFault+0x20b
fffff980`113dc778 fffff800`01c7cfe7 nt!MiFindNodeOrParent
fffff980`113dc780 fffff800`01cd576e nt!MiLocateAddressInTree+0x17
fffff980`113dc7b0 fffff800`01ce44fe nt!MiIdentifyPfn+0x77b
fffff980`113dc850 fffff800`01fb3965 nt!MmQueryPfnList+0x13e
fffff980`113dc890 fffff800`01e38c9c nt!PfpPfnPrioRequest+0x115
fffff980`113dc8e0 fffff800`01ec06ac nt!PfQuerySuperfetchInformation+0x1db
fffff980`113dc950 fffff800`01c4d733 nt!NtQuerySystemInformation+0x11aa
fffff980`113dcc20 00000000`770d05da nt!KiSystemServiceCopyEnd+0x13
00000000`0222e898 00000000`00000000 0x770d05da

That last address - that looks like a 32bit kernel address. I've actually seen this exact stack before, and this is almost always something talking to the kernel via a driver running in the Windows User-Mode driver framework service (a svchost.exe process). I've only ever seen this actually be one of two things - one, nvidia chipset drivers, and two, bad memory.

First, a note - I am going to assume that you are NOT overclocking your components. If you are, STOP and retest, as overclocked components can cause this exact callstack and bugcheck, so that needs to be ruled out. Again, assuming you are NOT overclocking, read on for some analysis.

I can't see exactly what hardware you're using other than the motherboard bios and chipset (the bulk of the global object list is not included in a minidump), but I don't see any nVidia hardware on the P5E board. So, if you're using an nVidia video card, make sure you're using the very latest *windows certified* drivers from nVidia. If you are, or aren't using nVidia hardware at all, run a memory check post-haste. The reason I say this is because Windows is searching actual RAM for some information in an address that the driver requested, and it didn't find it. Since this generated a page fault, and you cannot page fault at this high an IRQL (we're at something higher than IRQL 2), the OS in fact WILL bugcheck. So, either you have a driver that isn't keeping track of it's memory addresses (not probable, but it's at least remotely possible) or you have corrupt locations in RAM itself (unfortunately, in these cases this is FAR more likely).

I'd suggest downloading memtest86+ and testing the memory in your machine before doing anything further.

[watling]

I actually noticed something very interesting on the stack:

3: kd> k
Child-SP		  RetAddr		   Call Site
fffff980`113dc498 fffff800`01c4da33 nt!KeBugCheckEx
fffff980`113dc4a0 fffff800`01c4c90b nt!KiBugCheckDispatch+0x73
fffff980`113dc5e0 fffff800`01c8e3b0 nt!KiPageFault+0x20b
fffff980`113dc778 fffff800`01c7cfe7 nt!MiFindNodeOrParent
fffff980`113dc780 fffff800`01cd576e nt!MiLocateAddressInTree+0x17
fffff980`113dc7b0 fffff800`01ce44fe nt!MiIdentifyPfn+0x77b
fffff980`113dc850 fffff800`01fb3965 nt!MmQueryPfnList+0x13e
fffff980`113dc890 fffff800`01e38c9c nt!PfpPfnPrioRequest+0x115
fffff980`113dc8e0 fffff800`01ec06ac nt!PfQuerySuperfetchInformation+0x1db
fffff980`113dc950 fffff800`01c4d733 nt!NtQuerySystemInformation+0x11aa
fffff980`113dcc20 00000000`770d05da nt!KiSystemServiceCopyEnd+0x13
00000000`0222e898 00000000`00000000 0x770d05da

That last address - that looks like a 32bit kernel address. I've actually seen this exact stack before, and this is almost always something talking to the kernel via a driver running in the Windows User-Mode driver framework service (a svchost.exe process). I've only ever seen this actually be one of two things - one, nvidia chipset drivers, and two, bad memory.

First, a note - I am going to assume that you are NOT overclocking your components. If you are, STOP and retest, as overclocked components can cause this exact callstack and bugcheck, so that needs to be ruled out. Again, assuming you are NOT overclocking, read on for some analysis.

I can't see exactly what hardware you're using other than the motherboard bios and chipset (the bulk of the global object list is not included in a minidump), but I don't see any nVidia hardware on the P5E board. So, if you're using an nVidia video card, make sure you're using the very latest *windows certified* drivers from nVidia. If you are, or aren't using nVidia hardware at all, run a memory check post-haste. The reason I say this is because Windows is searching actual RAM for some information in an address that the driver requested, and it didn't find it. Since this generated a page fault, and you cannot page fault at this high an IRQL (we're at something higher than IRQL 2), the OS in fact WILL bugcheck. So, either you have a driver that isn't keeping track of it's memory addresses (not probable, but it's at least remotely possible) or you have corrupt locations in RAM itself (unfortunately, in these cases this is FAR more likely).

I'd suggest downloading memtest86+ and testing the memory in your machine before doing anything further.

Hi there bud, i have ran MEMTEST in the past and each stick of memory has shown with at least 1 error, so could this be a big part to play in the occuring shutdowns?

and to Mr Snrub, im sorry bud i cannot find what you are looking for, my computer skills and knowledge is minimal and i am a noob in this field so to speak.

[Mr Snrub]

and to Mr Snrub, im sorry bud i cannot find what you are looking for, my computer skills and knowledge is minimal and i am a noob in this field so to speak.

What about the non-technical questions at the top?

I find quite often when dealing with customers who open support cases that the "extra" information they don't think to provide initially can give clues as to the root cause of problems.

There is a huge difference between a system that has been running stable for over a year and one that has just been (re)built - especially if a recent change such as added hardware or drivers being upgraded has been made, for example.

So having an idea as to whether your system suddenly started having the problem "out of the blue" with no hardware or software changes would imply a hardware fault - conversely if some anti-virus or firewall product, for example, was installed shortly before the first bugcheck then it would be the thing to rule out.

Fresh builds that are not stable are naturally the trickiest to resolve - there is no history to indicate whether the problem is provoked by software or hardware (sometimes you can get lucky by reproducing the problem in a specific way, but you have already indicated it is random).

I would recommend that anyone running Vista should have SP1 applied, unless they have some specific software that is known to have problems with it.

Did you follow the link to the instructions for configuring Windows to produce a complete memory dump instead of minidumps, for the next crash?

That might give more information to show if the issue has a consistent root cause or not...

[cluberti]

Hi there bud, i have ran MEMTEST in the past and each stick of memory has shown with at least 1 error, so could this be a big part to play in the occuring shutdowns?

Considering these are memory corruption errors, yes. It would have been wise to have let us know this, although from the fact you aren't running an nVidia chipset and you're getting memory errors I'd say it seems more probable.