starpilot1
asked on
BSOD Error code
Today I began seeing spontanious reboots. Just before rebooting a Blue Screen of Death would be displayed only to dissappear right away. One BSOD did stay on the screen and the error code was:
0X00000003,0X8CBC8348,0x8C
I need some assistance interpreting this code.
Thanks very much.
0X00000003,0X8CBC8348,0x8C
I need some assistance interpreting this code.
Thanks very much.
PUNKY
http://kadaitcha.cx/xp/stop_error.html#0x00000003
ASKER
Is it possible to interpet the rest of the numbers too?
Check in Event Viewer, you may see that some access violations. Then, you could possible interpret those.
It would probably be more beneficial to check for a Minidump which is the state of your system at the time it crashed.
The dumps are normally located in c:\windows\minidump\
or %systemroot%\minidump\
It (or they) will contain information about the bugcheck that was generated.
Can you paste the latest dump(s) in the "Attach Code Snippet" box and someone here can hopefully tell you the cause of the crash.
You may need to disable auto restart:
Right click My Computer > Properties > Advanced > Startup and Recovery Settings and uncheck Automatically Restart.
The dumps are normally located in c:\windows\minidump\
or %systemroot%\minidump\
It (or they) will contain information about the bugcheck that was generated.
Can you paste the latest dump(s) in the "Attach Code Snippet" box and someone here can hopefully tell you the cause of the crash.
You may need to disable auto restart:
Right click My Computer > Properties > Advanced > Startup and Recovery Settings and uncheck Automatically Restart.
If you cannot reach Windows, you can turn off the 'Automatic reboot on error' option by selecting the Advanced Options Menu at bootup. Keep press/releasing the F8 function key and you'll reach a menu where you can select the option "Disable Automatic restart on system failure".
@ PUNKY .. my earlier comments of course were refering to "the rest of the numbers" statement, not yours :)
@ PUNKY .. my earlier comments of course were refering to "the rest of the numbers" statement, not yours :)
Sure, Yonvee :o) ... feel free to correct me if I post any wrong ... so I can learn more.
ASKER
Thanks very much for all your esponses - I'll do this tomorrow morning and attach the file...
I believe the bugcheck itself is missing - a 0x3 is extremely rare. I think we have the four parameters, not the STOP code.
I would advise checking WERCON - Problem Reports and Solutions in addition to the already proposed Event Viewer. Certainly the mini kernel dumps will tell us. If you can upload them somewhere, I can take a look to see what clues they (it) holds.
WERCON - START | type wercon.exe - hit enter. View Problems. The full bugcheck s/b there.
Also look at WERCON portion of msinfo32 - START | type msinfo32 & hit enter | Software Environment | Windows Error Reporting
I would advise checking WERCON - Problem Reports and Solutions in addition to the already proposed Event Viewer. Certainly the mini kernel dumps will tell us. If you can upload them somewhere, I can take a look to see what clues they (it) holds.
WERCON - START | type wercon.exe - hit enter. View Problems. The full bugcheck s/b there.
Also look at WERCON portion of msinfo32 - START | type msinfo32 & hit enter | Software Environment | Windows Error Reporting
To interpret the four parms (located inside the parenthesis) normally requires a FULL kernel dump. A mini kernel dump won't do b/c page not contained and therefore unable to convert virtual and physical memory addresses.
ASKER
Good Morning,
I went to c:\windows\minidump\ and %systemroot%\minidump\ did not find any Minidumps. I went to: My Computer > Properties > Advanced > Startup and Recovery Settings and unchecked Automatically Restart - and found the setting for dumps set to None. I set it to Complete Memory Dump.
My computer doesn't have wercon.exe but I was able to run MSINFO32 andI'm attaching a document that shows that info.
I have 2 GB of RAM and and whe I was trying to do a detect and repair on OUtlook I was getting CRC errors on a file called outlook.pst - I eventually pulled out one of the sticks of RAM and the system calmed down. It's running fine on 1 GB of RAM - could all thhis have been caused by a bad dimm?
Msinfo1.doc
I went to c:\windows\minidump\ and %systemroot%\minidump\ did not find any Minidumps. I went to: My Computer > Properties > Advanced > Startup and Recovery Settings and unchecked Automatically Restart - and found the setting for dumps set to None. I set it to Complete Memory Dump.
My computer doesn't have wercon.exe but I was able to run MSINFO32 andI'm attaching a document that shows that info.
I have 2 GB of RAM and and whe I was trying to do a detect and repair on OUtlook I was getting CRC errors on a file called outlook.pst - I eventually pulled out one of the sticks of RAM and the system calmed down. It's running fine on 1 GB of RAM - could all thhis have been caused by a bad dimm?
Msinfo1.doc
By a bad RAM, yes. Will analyse your Minidump & get back to you.
A quick check of the results show several reasons for the crashdump which can be indicative of a memory problem. Will continue to inspect these dumps, but meanwhile you have an option or two ..
1) Remove the 1GB of RAM & install the 2nd 1GB stick, & see if the problem returns.
2) Check the sockets/seating of both RAM sticks, pushing both firmly home.
3) Test both RAMs with memtest86+ v1.70 :
http://www.memtest.org/
4) Perhaps the best option is to run your machine with the 'good' RAM for a few hours, use a few applications, and see if you can generally encourage it to fail again.
1) Remove the 1GB of RAM & install the 2nd 1GB stick, & see if the problem returns.
2) Check the sockets/seating of both RAM sticks, pushing both firmly home.
3) Test both RAMs with memtest86+ v1.70 :
http://www.memtest.org/
4) Perhaps the best option is to run your machine with the 'good' RAM for a few hours, use a few applications, and see if you can generally encourage it to fail again.
ASKER
Thanks Jonvee,
I did swap the RAM and found that when one of the DIMMs is in the system behaves badly and am now running the system on what I think is good RAM. I'll run Memtest shortly.
I did swap the RAM and found that when one of the DIMMs is in the system behaves badly and am now running the system on what I think is good RAM. I'll run Memtest shortly.
Although Memtest is good, no memory Test is flawless, and for best results you probably know you'll need to run at least three passes. Even then, with a report that says a RAM is good, it's no proof that it really is .. a RAM exchange (or swopout) gives the best result.
Interesting msinfo32 WERCON - Dr. Watson failed.
CRC (cyclic redundancy check) errors usually refer to hard drives - internal or external. crc ENSURES that the origin & destination files match using a math equasion. I would think that physical RAM would be involved only if problematic driver or app running in kernel mode - or if page file damaged, non-existant or under-sized. It could be "leaky" driver consuming physical RAM then going after virtual memory (page file).
If page file not on OS drive or not large enoughon OS drive to handle total kernel memory + at time of crash, no dump file written. Another reason could be an app had its own version of dbghelp.dll, which WERCON/msinfo32 indicates - Dr. Watson involved. Usually not the case. This would cause a 3rd party program to write the dump - not XP.
May I ask for entire msinfo32 NFO file (saved in NFO format - you'll see the extension when you go to save it)?. Also, please perform system-wide search for dmp (those 3 letters), specifically looking in the \Program Files folder. Enable hidden and system files for search. You may find a dump file ending in "hdmp" or something similar.
CRC (cyclic redundancy check) errors usually refer to hard drives - internal or external. crc ENSURES that the origin & destination files match using a math equasion. I would think that physical RAM would be involved only if problematic driver or app running in kernel mode - or if page file damaged, non-existant or under-sized. It could be "leaky" driver consuming physical RAM then going after virtual memory (page file).
If page file not on OS drive or not large enoughon OS drive to handle total kernel memory + at time of crash, no dump file written. Another reason could be an app had its own version of dbghelp.dll, which WERCON/msinfo32 indicates - Dr. Watson involved. Usually not the case. This would cause a 3rd party program to write the dump - not XP.
May I ask for entire msinfo32 NFO file (saved in NFO format - you'll see the extension when you go to save it)?. Also, please perform system-wide search for dmp (those 3 letters), specifically looking in the \Program Files folder. Enable hidden and system files for search. You may find a dump file ending in "hdmp" or something similar.
Per code snip from msinfo32 - I believe alot more than a RAM issue is going on here.
It appears to me that a vb program was somehow executed which resulted in the crashes as I have documented in the code snip area.
It is likely that the 4 hexadecimal code provided came out of Nero or msvrtcrt.dll itself calling a different dbghelp.dll. Furthermore, if pure RAM issue, the bugchecks would be all over the map - not the same each time.
The crashes are timed too far apart to be a pure physical RAM issue - page file corruption following the same w/kernel mode drivers would be my guess.
If the XP NT Kernel fails as it appears to have, but did not, I would expect to see a bugcheck of 0x109 - critical structure corruption.
I believe you will end up running sfc, a system repair, copying drivers in from your XP SP? CD (slipstream) and/or re-installing XP.
Regards. . .
jcgriff2
It appears to me that a vb program was somehow executed which resulted in the crashes as I have documented in the code snip area.
It is likely that the 4 hexadecimal code provided came out of Nero or msvrtcrt.dll itself calling a different dbghelp.dll. Furthermore, if pure RAM issue, the bugchecks would be all over the map - not the same each time.
The crashes are timed too far apart to be a pure physical RAM issue - page file corruption following the same w/kernel mode drivers would be my guess.
If the XP NT Kernel fails as it appears to have, but did not, I would expect to see a bugcheck of 0x109 - critical structure corruption.
I believe you will end up running sfc, a system repair, copying drivers in from your XP SP? CD (slipstream) and/or re-installing XP.
Regards. . .
jcgriff2
11/15/2008
From msinfo32/WERCON= (edited) -
8:01 AM appcrash iexplore.exe, v 7.0.6000.16735, fault_mod kernel32.dll, v 5.1.2600.5512
8:02 AM appcrash iexplore.exe, v 7.0.6000.16735, fault_mod msvcrt.dll, v 7.0.2600.5512
8:17 AM appcrash nmdllhost.exe, v 3.2.5.0, fault_mod neroapiengine.dll, v 8.2.8.0
8:31 AM appcrash nmdllhost.exe, v 3.2.5.0, fault_mod ntdll.dll, v 5.1.2600.5512
9:09 AM appcrash powerarc.exe, v 10.2.2.2, fault_mod powerarc.exe, v 10.2.2.2
9:38 AM appcrash powerarc.exe, v 10.2.2.2, fault_mod kernel32.dll, v 5.1.2600.5512
10:15 AM appcrash iexplore.exe, v 7.0.6000.16735, fault_mod comctl32.dll, v 6.0.2900.5512
10:16 AM appcrash drwtsn32.exe, v 5.1.2600.0, fault_mod dbghelp.dll, v 5.1.2600.5512
10:35 AM appcrash egui.exe, v 3.0.672.0, fault_mod uxtheme.dll, v 6.0.2900.5512ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
WOW! What a great Analysis!
I'll run sfc scannow
I'll run sfc scannow
Thank you.
I hope all goes well.
I hope all goes well.
ASKER
I read your analysis carefully and ran scannow - however I still think it was a bad ram stick - I've replaced it and the system is crisper and stable. Thank you for your tenacity and expert help. You are the kind of person that keeps me renewing my membership. Have a great Thanksgiving!!