hey guys wanna find what caused BSOD instead of facing it again and again heres a way where in you can solve by identifing what caused it. i must acknowledge that the article is not by me . i read it in another forum and posted here since only members can access it . for those who like to check it out heres the link
http://appzpla.net/index.php?showtopic=52722
here goes the article
To some users a blue screen (or a BSOD) is totally inunderstandable. In this guide or reference or whatever i will give you a chance to understand them and solving them yourself.
First of all, you should have the option minidump on by default in start and recovery (Right click my compter-> Propeerties -> Advanced -> Start & Rcovery -> At the bottom there is a dropdown list (choose the one that says (64 Kb)in the end)).
Okay, so next time the computer gets the BSOD, let it be until it has dumped the memory. Now the computer will restart, when you reaches windows the OS tells you to send a report about this to Microsoft, DO THIS so that your problem can be solved in the future.
Now get the debugging tools from microsoft:
CODE
http://www.microsoft.com/whdc/ddk/debugging/default.mspx
Got it? Good, start it, now you should download the symbol reference files: easiest way to get them is to let teh program download them itself; File -> Symbol File Path...; Here you type this
CODE
SRV*c:_websymbols*http://msdl.microsoft.com/download/symbols
(NOTE, you will have to change the "_" after c: to a backslash this will download the symbols to the directory websymbols in you root. (If you doesn't already have the directory there, create it!))
Okay, now it is time to open the dumpfile (File -> Open Crash Dump... (the dump is located in c:/windows/minidump))this might take some time due to the fact that the debugger is locating and downloading the necessary symobls.
When finished downloading the window should state: "kd>"
Now you shall analyze the dump, this is made by typing: "!analyze -v"
Quite often you are able to tell exactly what the problem is, and it's not always as it is stated on the BSOD.
Here is an example of a logfile:
CODE
Okay, by looking at the MiniDump you can tell that the file s3gsavmx.dll, might be the troublemaker here.
Okay, how will we prevent this from happening in the future? Well, you can close the debugger now, and start the verifier. (Start -> Run -> Verifier)
Okay Choose: "Create standard" -> Next -> Automatically select unsigned... -> Next.
Choose the file that was the trouble maker -> Finish.
So, why the verifier? Because it will try to catch the problem earlier, before the BSOD (nice, huh?) and report it to you. Now reboot, this is necessary for the verifier to work.
This option only applies to an unsigned driver, and if you got a signed driver that you think is the trouble maker - it is probably not. What you should try to do if you experience problems with signed drivers is trying to change the memory (both the modules and the manufacturer, on the homepage of your mainboard manufacturer they will tell you which memories that wil fit your board. Also make sure that the cpu isn't to hot - or that you have overclocked it.)
Well, guys that was all from me, good luck and hopefully we will see analyzed dumpfiles in the posted threads instead of just error codes...
http://appzpla.net/index.php?showtopic=52722
here goes the article
To some users a blue screen (or a BSOD) is totally inunderstandable. In this guide or reference or whatever i will give you a chance to understand them and solving them yourself.
First of all, you should have the option minidump on by default in start and recovery (Right click my compter-> Propeerties -> Advanced -> Start & Rcovery -> At the bottom there is a dropdown list (choose the one that says (64 Kb)in the end)).
Okay, so next time the computer gets the BSOD, let it be until it has dumped the memory. Now the computer will restart, when you reaches windows the OS tells you to send a report about this to Microsoft, DO THIS so that your problem can be solved in the future.
Now get the debugging tools from microsoft:
CODE
http://www.microsoft.com/whdc/ddk/debugging/default.mspx
Got it? Good, start it, now you should download the symbol reference files: easiest way to get them is to let teh program download them itself; File -> Symbol File Path...; Here you type this
CODE
SRV*c:_websymbols*http://msdl.microsoft.com/download/symbols
(NOTE, you will have to change the "_" after c: to a backslash this will download the symbols to the directory websymbols in you root. (If you doesn't already have the directory there, create it!))
Okay, now it is time to open the dumpfile (File -> Open Crash Dump... (the dump is located in c:/windows/minidump))this might take some time due to the fact that the debugger is locating and downloading the necessary symobls.
When finished downloading the window should state: "kd>"
Now you shall analyze the dump, this is made by typing: "!analyze -v"
Quite often you are able to tell exactly what the problem is, and it's not always as it is stated on the BSOD.
Here is an example of a logfile:
CODE
Code:
kd> !analyze -v
************************************************************
*******************
* *
* Bugcheck Analysis *
* *
************************************************************
*******************
THREAD_STUCK_IN_DEVICE_DRIVER_M (100000ea)
The device driver is spinning in an infinite loop, most likely waiting for
hardware to become idle. This usually indicates problem with the hardware
itself or with the device driver programming the hardware incorrectly.
If the kernel debugger is connected and running when watchdog detects a
timeout condition then DbgBreakPoint() will be called instead of KeBugCheckEx()
and detailed message including bugcheck arguments will be printed to the
debugger. This way we can identify an offending thread, set breakpoints in it,
and hit go to return to the spinning code to debug it further. Because
KeBugCheckEx() is not called the .bugcheck directive will not return bugcheck
information in this case. The arguments are already printed out to the kernel
debugger. You can also retrieve them from a global variable via
"dd watchdog!g_WdBugCheckData l5" (use dq on NT64).
On MP machines it is possible to hit a timeout when the spinning thread is
interrupted by hardware interrupt and ISR or DPC routine is running at the time
of the bugcheck (this is because the timeout's work item can be delivered and
handled on the second CPU and the same time). If this is the case you will have
to look deeper at the offending thread's stack (e.g. using dds) to determine
spinning code which caused the timeout to occur.
Arguments:
Arg1: 82624718, Pointer to a stuck thread object. Do .thread then kb on it to find
the hung location.
Arg2: 829a7008, Pointer to a DEFERRED_WATCHDOG object.
Arg3: 82ac0530, Pointer to offending driver name.
Arg4: 00000001, Number of times "intercepted" bugcheck 0xEA was hit (see notes).
Debugging Details:
------------------
Database SolnDb not connected
FAULTING_THREAD: 82624718
IMAGE_NAME: [b]s3gsavmx.dll[/b]
DEBUG_FLR_IMAGE_TIMESTAMP: 3e30f8a8
MODULE_NAME: s3gsavmx
FAULTING_MODULE: bf99e000 s3gsavmx
DEFAULT_BUCKET_ID: [b]GRAPHICS_DRIVER_FAULT[/b]
BUGCHECK_STR: [b]0xEA[/b]
LAST_CONTROL_TRANSFER: from 804f43f7 to 805313cf
STACK_TEXT:
f3e476f0 804f43f7 00000000 f7ae6c0c 00000000 nt!KiUnlockDispatcherDatabase+0x77
f3e47700 f7276830 f7ae6c2c 00000000 00000000 nt!KeSetEvent+0x73
f3e479f0 804f816d f7ae6bdc f3e47a3c f3e47a30 watchdog!WatchdogKernelApc+0xf2
f3e47a40 806b138c 00000000 00000000 f3e47a58 nt!KiDeliverApc+0xb1
f3e47a40 806ac383 00000000 00000000 f3e47a58 hal!HalpApcInterrupt2ndEntry+0x31
f3e47adc f74ac56a 00000010 f7d56004 e1146010 hal!HalpAcpiTimerStallExecProc+0x63
WARNING: Stack unwind information not available. Following frames may be wrong.
f3e47adc f74ac56a 00000010 f7d56004 e1146010 s3gsavm+0x456a
f3e47afc bf99e53d f7d56004 0000e3db 000000c8 s3gsavm+0x456a
f3e47b40 bf9a19f9 e1146010 f3e47b80 ffffffc0 s3gsavmx+0x53d
00000000 00000000 00000000 00000000 00000000 s3gsavmx+0x39f9
f3e48690 8057d4c1 f3e48718 f3e4871c f3e4872c nt!KiCallUserMode+0x4
f3e486ec bf805674 00000002 f3e4873c 00000018 nt!KeUserModeCallback+0x87
f3e4876c bf895d1f bc64d4c0 0000000f 00000000 win32k!SfnDWORD+0xa0
f3e487b4 bf802802 4064d4c0 0000000f 00000000 win32k!xxxSendMessageToClient+0x174
f3e48800 bf80a4c6 bc64d4c0 0000000f 00000000 win32k!xxxSendMessageTimeout+0x1a6
f3e48820 bf807c4b bc64d4c0 0000000f 00000000 win32k!xxxSendMessage+0x1a
f3e4884c bf807d5c bc64d4c0 00000001 00eaf090 win32k!xxxUpdateWindow2+0x77
f3e4886c bf807ce9 bc64d4c0 00000001 bf807daa win32k!xxxInternalUpdateWindow+0x6d
f3e48878 bf807daa bc64d4c0 00eaf090 f3e48bfc win32k!xxxUpdateWindow+0xb
f3e48894 8052d571 00010116 0000005e 00000286 win32k!NtUserCallHwndLock+0x49
f3e48894 7ffe0304 00010116 0000005e 00000286 nt!KiSystemService+0xc4
00eaf0c4 00000000 00000000 00000000 00000000 SharedUserData!SystemCallStub+0x4
f3e48b5c 8057d4c1 f3e48be4 f3e48be8 f3e48bf8 nt!KiCallUserMode+0x4
f3e48bb8 bf805674 00000002 f3e48c08 00000018 nt!KeUserModeCallback+0x87
f3e48c38 bf807e76 bc6b1e38 0000007f 001792e0 win32k!SfnDWORD+0xa0
f3e48cac bf892dd4 e188c008 f3e48d64 00000000 win32k!xxxReceiveMessage+0xb5
f3e48ce8 bf8730c0 f3e48d14 000025ff 00000000 win32k!xxxRealInternalGetMessage+0x1ce
f3e48d48 8052d571 00eaff2c 00000000 00000000 win32k!NtUserPeekMessage+0x40
f3e48d48 7ffe0304 00eaff2c 00000000 00000000 nt!KiSystemService+0xc4
00eafed8 00000000 00000000 00000000 00000000 SharedUserData!SystemCallStub+0x4
STACK_COMMAND: .thread ffffffff82624718; kb
FOLLOWUP_NAME: MachineOwner
BUCKET_ID: 0xEA_IMAGE_s3gsavmx.dll_DATE_05_24_2004
Followup: MachineOwner
---------Okay, how will we prevent this from happening in the future? Well, you can close the debugger now, and start the verifier. (Start -> Run -> Verifier)
Okay Choose: "Create standard" -> Next -> Automatically select unsigned... -> Next.
Choose the file that was the trouble maker -> Finish.
So, why the verifier? Because it will try to catch the problem earlier, before the BSOD (nice, huh?) and report it to you. Now reboot, this is necessary for the verifier to work.
This option only applies to an unsigned driver, and if you got a signed driver that you think is the trouble maker - it is probably not. What you should try to do if you experience problems with signed drivers is trying to change the memory (both the modules and the manufacturer, on the homepage of your mainboard manufacturer they will tell you which memories that wil fit your board. Also make sure that the cpu isn't to hot - or that you have overclocked it.)
Well, guys that was all from me, good luck and hopefully we will see analyzed dumpfiles in the posted threads instead of just error codes...