Thursday, January 24, 2013

PC & Adobe Crashes & How To Deal With Them - Part Three



The Blue Screen of Death or worse BSOD and no error/dump file! What's a person to do?

After you've tested your disk, your memory, ran all sorts of virus and malware search and destroy tools and every test comes up clean.... and you still have system crashes! Well you might just have a driver problem. But what driver? There may be a hundred or more.

Finding tools to do all the appropriate tests online may take the better part of an afternoon if you don't already have them handy, and then running the test may take days depending on how thorough they are. I've learned my lesson. Before I go through all that I will follow the simply outline below to see if system crashes are caused by a missing, corrupt, outdated, or wrong driver.

First, thanks to NetWork World for publishing the this article. Read the article for details.

In my case I found that a Nvidia driver had somehow gone bad. By following the procedure outlined in the article I was able to locate the culprit and stop the crashes in minutes, after having spent days doing needless system testing.

You will need to download WinDbg at the Microsoft site here. After installing the tools run WinDbg. The WinDbg GUI is not pretty, and as any debugger there are a lot of complex commands, but by following the simple instructions written by Dirk Smith in the article I found my answer, that is, which driver was causing the crash. I went to the Nvidia site for the download, reinstalled the driver and my problems were over.

One catch for me was that my crashes were not producing dump files even though it was set up to do so under My Computer > properties > advanced  > startup and recovery > system failure. Insure that you have your PC set up to provide a crash dump file. Without a dump file of the crash you cannot use the debugger. During my prior analysis of memory usage I noted that I had virtual memory page files on all drives except the C: drive. I did that because I didn't want VM competing with other activities on C:. The dump file was supposed to go to C:/windows. Just as a shot in the dark I created a pagefile on C: too, and wha-la, during the next crash a dump file was created. Coincidence? I'm guessing yes, but on the other hand not having a pagefile on C: may be taken by Windows as your not wanting to use space on C: for system related files like pagefiles and dumps which at times can be large.

System crashes can be deeply mysterious, but by following this outline you can detect what driver may be causing the problem or at least potentially eliminate drivers as the culprit. The debugger can do a lot more of course and might even detect other sources of a crash. But that's too deep of a dive for this post.

If drivers are not your issue, then spending time look for malware may be warranted, and that's a topic too large for this post.

Checking your disk and memory is fairly easy though it may takes many hours depending how large they are. Here are some decent tools in that regard as well as general health check sources.

Look over parts One and Two of this series for other troubleshooting tips.

Micosoft help with drivers
Microsoft debugging tool
Microsoft virus tools
Microsoft help with deceptive software 
How to read memory dumps
Generic disk checking software by Seagate
How to check your disk 
Memory testing tool (there is a free version too)

No comments:

Post a Comment