Googling helps and before even I thought of analyzing the dmp with WinDbg, I ran DumpChk, another tool in the debugger toolset, to create a readable version of the dmp. In this readable version, I could verify from googling that the bluescreen was caused due to an inconsistent power state. I couldn't get further information on this topic. So I ran Windbg and analyzed the dmp there.
The GUI is very friendly given the kind of low-level analysis one does with WinDbg. So, Windbg took a short while to look up symbols from the microsoft online symbol server and save it on my "downstreamstore". After a while, it had downloaded symbols for quite a few drivers that I guess were referenced in the crash report, amounting to a total of 15 mb. Once the symbols had ben loaded, I was given the option to run the Analyze command that goes like "!Analyze" in windbg syntax. - but I didn't even have to type this because the GUI offered me the tip along with a hyperlink to the command text that I just had to click.
The analyze command did give me more information -- it told me that "A device object has been blocking an Irp for too long a time" was the reason for the system to be halted. Unfortunately, Windbg couldn't fish for more information on which driver exactly caused this problem because it seemed to have problems with loading some dll's, as it spewed recurringly the following:
The call to LoadLibrary(exts) failed, Win32 error 0n2
"The system cannot find the file specified."
Please check your debugger configuration and/or network access.
This was strange because Windbg had just managed to download symbols from microsoft online...okay, more googling ensued....this time looking for a way to resolve the LoadLibrary problem. Finally, I found a possible explanation in a German discussion site, and thanks to some basic German that I've picked up, I managed to learn that the debugger extensions are not getting loaded. Voila! I then recollected that I had stopped short of installing debugger extensions thinking that it would consume a lot of disk space...and so I went and updated my installation and reran Windbg...and sakkatt -- this time, Windbg was able to point out the offending driver: athr.sys, which I googled to find out that it is my wireless network driver from Atheros -- which is true.
This piece of valuable info on LoadLibrary(ext) failing was hidden among so much other garbage out there in google results where they were mostly make ext a DLL of its own called ext.dll. I was even surprised that a post in EggheadCafe also treated this problem as if it were to do with missing DLL dependencies for ext.dll, with an added reply from someone who could be mistaken for a Microsoftian, who said that this was a regression issue (it was in this case, because the originator reported of problems with upgrading to a new windows debugger version or so) and was being looked into.
Well, a part of Saturday well spent. Its always fun to learn that you learn when you set out learning :-)
2 comments:
Thank you for saving me the time of filtering through all the misleading information you yourself had to pile through in order to simply determine that you didn't install all the windbg extensions. I too was too discerning during my original install in which items in the debugger package I wanted installed on my drive. The best advice for those similarly afflicted that happen upon your blog post is to install EVERYTHING from the debugging tools package. Thx again!
Post a Comment