|
用WinDbg分析dump文件,可以找到crash的起因。
在这里可以简单学习一下。
http://www.networkworld.com/news/2005/041105-windows-crash.html
以下是节选的分析及处理
Finding out what went wrong is often a simpleprocess, but it isn't always so. At least 50% of the time (often 70%),the debugger makes the reason for a crash obvious. But sometimes theinformation it provides is misleading or insufficient. What do you dothen?
Inconsistent answers
If you have recurring crashes but no clear or consistent reason, it may be a memory problem. Download the free test tool, Memtest86. This simple diagnostic tool is quick and works great.
Many people discount the possibility of a memory problem, because they account for such a small percentage of system crashes. However, they are often the cause that keeps you guessing the longest.
The operating system is the culprit
Not likely! As surprising as it may seem, theoperating system is rarely at fault. If ntoskrnl.exe (Windows core) orwin32.sys (the driver that is most responsible for the "GUI" layer onWindows) is named as the culprit, and they often are, don't be tooquick to accept it. It is far more likely that some errant third-partydevice driver called upon a Windows component to perform an operationand passed a bad instruction, such as telling it to write tonon-existent memory. So, while the operating system certainly can err,exhaust all other possibilities before you call Microsoft! The samegoes for debugging Unix, Linux, and NetWare.
Wrong driver named
Often you will see an antivirus driver named as the cause. For instance, after using !analyze –v, the debugger reports a driver for your antivirus program at the line "IMAGE_NAME". This may well be the case, but bear in mind that such a driver can be named more often than it is guilty. Here's why: For antivirus code to work it must watch all file openings and closings. To accomplish this, the code sits at a low layer in the operating system and is constantly working. In fact, it is so busy it will often be on the stack of function calls that was active when the crash occurred, even if it did not cause it. Because any third-party driver on that stack immediately becomes suspect, it will often get named. From a mathematical standpoint it is easy to see how it will so often be on the stack whether it actually caused a problem or not.
Little or no vendor information
Not all vendors include needed information (not even their name!). If you use the lmv command and turn up nothing, look at the subdirectories on the image path (if there is one). Often one of them will be the vendor name or a contraction of it. Another option is to search Google. Type in the driver name and/or folder name. You'll probably find the vendor as well as others who have posted information regarding the driver. |
评分
-
1
查看全部评分
-
|