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

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

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"

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

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

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".

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

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...

I actually noticed something very interesting on the stack:



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.

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...

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.