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 following article http://www.networkworld.com/news/2005/041105-windows-crash.html. 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. Of course, 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?
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 corrupt. 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.
Good luck! Don't let crashes keep you done!
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 following article http://www.networkworld.com/news/2005/041105-windows-crash.html. 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. Of course, 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?
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 corrupt. 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.
Good luck! Don't let crashes keep you done!