watling Posted August 30, 2008 Share Posted August 30, 2008 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: 2057Additional 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_1Files 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.txtRead our privacy statement: http://go.microsoft.com/fwlink/?linkid=501...mp;clcid=0x0409Hope anyone has some advice on my issue thanks in advance Link to comment Share on other sites More sharing options...
Mr Snrub Posted August 30, 2008 Share Posted August 30, 2008 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 Link to comment Share on other sites More sharing options...
watling Posted August 30, 2008 Author Share Posted August 30, 2008 (edited) 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.htmlHey 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 Link to comment Share on other sites More sharing options...
Mr Snrub Posted August 30, 2008 Share Posted August 30, 2008 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. Link to comment Share on other sites More sharing options...
watling Posted August 30, 2008 Author Share Posted August 30, 2008 (edited) 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 Link to comment Share on other sites More sharing options...
Mr Snrub Posted August 30, 2008 Share Posted August 30, 2008 Strange, I just copied a minidump to my desktop and 7-zip was able to archive it from there... I did the following:Start / ComputerBrowse to C:\Windows\Mindump - click OK on prompt to get accessSelect multiple minidump*.dmp files, right-click and select CopyShow desktop, right-click and select Paste - files are now copiedWith 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. Link to comment Share on other sites More sharing options...
watling Posted August 30, 2008 Author Share Posted August 30, 2008 Strange, I just copied a minidump to my desktop and 7-zip was able to archive it from there... I did the following:Start / ComputerBrowse to C:\Windows\Mindump - click OK on prompt to get accessSelect multiple minidump*.dmp files, right-click and select CopyShow desktop, right-click and select Paste - files are now copiedWith 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.htmlhttp://rapidshare.com/files/141355840/Mini083008-02.zip.htmlAnd thanks again for your speedy responses Link to comment Share on other sites More sharing options...
Mr Snrub Posted August 30, 2008 Share Posted August 30, 2008 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 x64Product: WinNt, suite: TerminalServer SingleUserTS PersonalBuilt by: 6000.16584.amd64fre.vista_gdr.071023-1545Kernel base = 0xfffff800`01c00000 PsLoadedModuleList = 0xfffff800`01d9af70Debug session time: Sat Aug 30 17:59:19.878 2008 (GMT+2)System Uptime: 0 days 0:25:55.6243: kd> !sysinfo machineidMachine ID Information [From Smbios 2.4, DMIVersion 36, Size=2655]BiosMajorRelease = 8BiosMinorRelease = 12BiosVendor = American Megatrends Inc.BiosVersion = 0203 BiosReleaseDate = 10/11/2007SystemManufacturer = System manufacturerSystemProductName = P5ESystemFamily = To Be Filled By O.E.M.SystemVersion = System VersionSystemSKU = To Be Filled By O.E.M.BaseBoardManufacturer = ASUSTeK Computer INC.BaseBoardProduct = P5EBaseBoardVersion = Rev 1.xx3: kd> !sysinfo cpuinfo[CPU Information]~MHz = REG_DWORD 2405Component Information = REG_BINARY 0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0Configuration Data = REG_FULL_RESOURCE_DESCRIPTOR ff,ff,ff,ff,ff,ff,ff,ff,0,0,0,0,0,0,0,0Identifier = REG_SZ EM64T Family 6 Model 15 Stepping 11ProcessorNameString = REG_SZ Intel® Core2 Quad CPU Q6600 @ 2.40GHzUpdate Signature = REG_BINARY 0,0,0,0,b3,0,0,0Update Status = REG_DWORD 6VendorIdentifier = REG_SZ GenuineIntelMSR8B = REG_QWORD b300000000IRQL_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 referencedArg2: 0000000000000002, IRQLArg3: 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 memoryTRAP_FRAME: fffff980113dc5e0 -- (.trap 0xfffff980113dc5e0)3: kd> .trap 0xfffff980113dc5e03: kd> rLast set context:rax=0000000000000000 rbx=fffff80001c00000 rcx=0000000000000000rdx=0000000000000000 rsi=fffff80001d69200 rdi=000000000000000arip=fffff80001c8e3b0 rsp=fffff980113dc778 rbp=0000000000000000 r8=fffff980113dc7c0 r9=fffff88003aef600 r10=fffffa80079661f0r11=fffffa8007966120 r12=0000000000000000 r13=0000000000000000r14=0000000000000000 r15=0000000000000000iopl=0 nv up ei ng nz na pe nccs=0010 ss=0018 ds=0000 es=0000 fs=0000 gs=0000 efl=00010282nt!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 itChild-SP RetAddr : Args to Child : Call Sitefffff980`113dc778 fffff800`01c7cfe7 : 00000000`00000000 fffff800`01cd503a 42506650`01c00000 fffffa80`04ded000 : nt!MiFindNodeOrParentfffff980`113dc780 fffff800`01cd576e : 00000000`00000000 00000000`000007ff 00000000`000018c0 fffff800`01d3d2a4 : nt!MiLocateAddressInTree+0x17fffff980`113dc7b0 fffff800`01ce44fe : 00000000`00054ad8 fffffa80`04dedbc8 fffffa80`0785d060 00000000`00000000 : nt!MiIdentifyPfn+0x77bfffff980`113dc850 fffff800`01fb3965 : fffffa80`04ded000 fffff980`113dcca0 fffff980`113dc918 00000000`00000000 : nt!MmQueryPfnList+0x13efffff980`113dc890 fffff800`01e38c9c : 00000000`00000000 00000000`00000000 fffffa80`04ded000 00000000`00000001 : nt!PfpPfnPrioRequest+0x115fffff980`113dc8e0 fffff800`01ec06ac : 00000000`00000000 00000000`00000000 00000000`0222e940 fffff980`047d7501 : nt!PfQuerySuperfetchInformation+0x1dbfffff980`113dc950 fffff800`01c4d733 : fffffa80`0785d060 00000000`042faff0 00000000`03d023e0 00000000`00000000 : nt!NtQuerySystemInformation+0x11aafffff980`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 : 0x770d05daCrash 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.) Link to comment Share on other sites More sharing options...
watling Posted August 30, 2008 Author Share Posted August 30, 2008 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 x64Product: WinNt, suite: TerminalServer SingleUserTS PersonalBuilt by: 6000.16584.amd64fre.vista_gdr.071023-1545Kernel base = 0xfffff800`01c00000 PsLoadedModuleList = 0xfffff800`01d9af70Debug session time: Sat Aug 30 17:59:19.878 2008 (GMT+2)System Uptime: 0 days 0:25:55.6243: kd> !sysinfo machineidMachine ID Information [From Smbios 2.4, DMIVersion 36, Size=2655]BiosMajorRelease = 8BiosMinorRelease = 12BiosVendor = American Megatrends Inc.BiosVersion = 0203 BiosReleaseDate = 10/11/2007SystemManufacturer = System manufacturerSystemProductName = P5ESystemFamily = To Be Filled By O.E.M.SystemVersion = System VersionSystemSKU = To Be Filled By O.E.M.BaseBoardManufacturer = ASUSTeK Computer INC.BaseBoardProduct = P5EBaseBoardVersion = Rev 1.xx3: kd> !sysinfo cpuinfo[CPU Information]~MHz = REG_DWORD 2405Component Information = REG_BINARY 0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0Configuration Data = REG_FULL_RESOURCE_DESCRIPTOR ff,ff,ff,ff,ff,ff,ff,ff,0,0,0,0,0,0,0,0Identifier = REG_SZ EM64T Family 6 Model 15 Stepping 11ProcessorNameString = REG_SZ Intel® Core2 Quad CPU Q6600 @ 2.40GHzUpdate Signature = REG_BINARY 0,0,0,0,b3,0,0,0Update Status = REG_DWORD 6VendorIdentifier = REG_SZ GenuineIntelMSR8B = REG_QWORD b300000000IRQL_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 referencedArg2: 0000000000000002, IRQLArg3: 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 memoryTRAP_FRAME: fffff980113dc5e0 -- (.trap 0xfffff980113dc5e0)3: kd> .trap 0xfffff980113dc5e03: kd> rLast set context:rax=0000000000000000 rbx=fffff80001c00000 rcx=0000000000000000rdx=0000000000000000 rsi=fffff80001d69200 rdi=000000000000000arip=fffff80001c8e3b0 rsp=fffff980113dc778 rbp=0000000000000000 r8=fffff980113dc7c0 r9=fffff88003aef600 r10=fffffa80079661f0r11=fffffa8007966120 r12=0000000000000000 r13=0000000000000000r14=0000000000000000 r15=0000000000000000iopl=0 nv up ei ng nz na pe nccs=0010 ss=0018 ds=0000 es=0000 fs=0000 gs=0000 efl=00010282nt!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 itChild-SP RetAddr : Args to Child : Call Sitefffff980`113dc778 fffff800`01c7cfe7 : 00000000`00000000 fffff800`01cd503a 42506650`01c00000 fffffa80`04ded000 : nt!MiFindNodeOrParentfffff980`113dc780 fffff800`01cd576e : 00000000`00000000 00000000`000007ff 00000000`000018c0 fffff800`01d3d2a4 : nt!MiLocateAddressInTree+0x17fffff980`113dc7b0 fffff800`01ce44fe : 00000000`00054ad8 fffffa80`04dedbc8 fffffa80`0785d060 00000000`00000000 : nt!MiIdentifyPfn+0x77bfffff980`113dc850 fffff800`01fb3965 : fffffa80`04ded000 fffff980`113dcca0 fffff980`113dc918 00000000`00000000 : nt!MmQueryPfnList+0x13efffff980`113dc890 fffff800`01e38c9c : 00000000`00000000 00000000`00000000 fffffa80`04ded000 00000000`00000001 : nt!PfpPfnPrioRequest+0x115fffff980`113dc8e0 fffff800`01ec06ac : 00000000`00000000 00000000`00000000 00000000`0222e940 fffff980`047d7501 : nt!PfQuerySuperfetchInformation+0x1dbfffff980`113dc950 fffff800`01c4d733 : fffffa80`0785d060 00000000`042faff0 00000000`03d023e0 00000000`00000000 : nt!NtQuerySystemInformation+0x11aafffff980`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 : 0x770d05daCrash 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 Link to comment Share on other sites More sharing options...
Mr Snrub Posted August 30, 2008 Share Posted August 30, 2008 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 & SystemAny 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... Link to comment Share on other sites More sharing options...
cluberti Posted August 31, 2008 Share Posted August 31, 2008 I actually noticed something very interesting on the stack:3: kd> kChild-SP RetAddr Call Sitefffff980`113dc498 fffff800`01c4da33 nt!KeBugCheckExfffff980`113dc4a0 fffff800`01c4c90b nt!KiBugCheckDispatch+0x73fffff980`113dc5e0 fffff800`01c8e3b0 nt!KiPageFault+0x20bfffff980`113dc778 fffff800`01c7cfe7 nt!MiFindNodeOrParentfffff980`113dc780 fffff800`01cd576e nt!MiLocateAddressInTree+0x17fffff980`113dc7b0 fffff800`01ce44fe nt!MiIdentifyPfn+0x77bfffff980`113dc850 fffff800`01fb3965 nt!MmQueryPfnList+0x13efffff980`113dc890 fffff800`01e38c9c nt!PfpPfnPrioRequest+0x115fffff980`113dc8e0 fffff800`01ec06ac nt!PfQuerySuperfetchInformation+0x1dbfffff980`113dc950 fffff800`01c4d733 nt!NtQuerySystemInformation+0x11aafffff980`113dcc20 00000000`770d05da nt!KiSystemServiceCopyEnd+0x1300000000`0222e898 00000000`00000000 0x770d05daThat 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. Link to comment Share on other sites More sharing options...
watling Posted August 31, 2008 Author Share Posted August 31, 2008 I actually noticed something very interesting on the stack:3: kd> kChild-SP RetAddr Call Sitefffff980`113dc498 fffff800`01c4da33 nt!KeBugCheckExfffff980`113dc4a0 fffff800`01c4c90b nt!KiBugCheckDispatch+0x73fffff980`113dc5e0 fffff800`01c8e3b0 nt!KiPageFault+0x20bfffff980`113dc778 fffff800`01c7cfe7 nt!MiFindNodeOrParentfffff980`113dc780 fffff800`01cd576e nt!MiLocateAddressInTree+0x17fffff980`113dc7b0 fffff800`01ce44fe nt!MiIdentifyPfn+0x77bfffff980`113dc850 fffff800`01fb3965 nt!MmQueryPfnList+0x13efffff980`113dc890 fffff800`01e38c9c nt!PfpPfnPrioRequest+0x115fffff980`113dc8e0 fffff800`01ec06ac nt!PfQuerySuperfetchInformation+0x1dbfffff980`113dc950 fffff800`01c4d733 nt!NtQuerySystemInformation+0x11aafffff980`113dcc20 00000000`770d05da nt!KiSystemServiceCopyEnd+0x1300000000`0222e898 00000000`00000000 0x770d05daThat 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. Link to comment Share on other sites More sharing options...
Mr Snrub Posted August 31, 2008 Share Posted August 31, 2008 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... Link to comment Share on other sites More sharing options...
cluberti Posted September 1, 2008 Share Posted September 1, 2008 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. Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now