The Cases of the Blue Screens: Finding Clues in a Crash Dump and on the Web

re: The Cases of the Blue Screens: Finding Clues in a Crash Dump and on the Web

Yassine Souabni — Sun, 24 Apr 2011 20:32:34 GMT

@ Mark Russinovich :

many thanks - this worked perfectly.

The issue I was facing is a BSOD occuring just after I type the password of my encrypted

Western Digital "My passeport - 500 Go" external hard drive and press "Enter" on a XP SP3 station.

(In any other "normal" station, the authentication would succeed and the WD disk becomes visible

under My Computer).

For months, I used to run a Windows 7 VM inside the XP, mapping the HDD to Win 7

then sharing it on the Network from the VM.... :D oufff

"RAM angry workaround" :) but not a solution...

When the BSOD problem happens, no log data to begin with ... - nothing on event viewer also -

After following these debugging tips, I now know for sure that the bug was due to SGEFLT.SYS

file (the system disk is "also" encrypted :) using Safeguard Easy).

"All i understood" is that this safeguard driver version installed on the station

was a legacy version causing these BSOD to happen when dealing with USB devices

managed by device lock service .......

Using the file name given by the crash dump analysis, I found this link (that fixed my issues) :

"www.utimaco.com/.../W27GVC4F014OBELEN**&db=C1256F63004688CE&q=PKD_Search&nm=0&unid=66AB8A11AA1E84F7C12573B100611300&view=sgi&LG=EN&ip=66.249.65.4&j=1"

Many thanks again !!

re: The Cases of the Blue Screens: Finding Clues in a Crash Dump and on the Web

Huajun Gu — Thu, 17 Mar 2011 09:29:55 GMT

Thank you, Mark. Very helpful.

Actually, I am analyzing a dump file with bug check: SESSION_HAS_VALID_VIEWS_ON_EXIT (ba).

But I am not lucky enough, the proper cause of this BSOD is not a driver fault.

Maybe it's caused by handle leaks, I still need a final confirmation from the vendor company.

I think this case is a deep digging, not a little one.

I know, "No pains, no gains". But BSOD analyze is really not a easy job for system administrator.

re: The Cases of the Blue Screens: Finding Clues in a Crash Dump and on the Web

Sanjeev Singh — Tue, 15 Mar 2011 09:18:26 GMT

Thanks a lot Mark. It is realy very good and helpful.......I really appreciate it........

re: The Cases of the Blue Screens: Finding Clues in a Crash Dump and on the Web

MikeC — Fri, 11 Mar 2011 20:48:14 GMT

Thanks Andrew. Very helpful. I was never sure what the significance was or where it fit into the crash.

re: The Cases of the Blue Screens: Finding Clues in a Crash Dump and on the Web

AndrewRichards — Thu, 10 Mar 2011 20:05:55 GMT

@ MickC:

The PROCESS_NAME is the process that was scheduled at the time of the bugcheck. The process itself may not have been the instigator though if it was pre-empted. That is, an interrupt, DPC or APC occurred. In these cases, the process's thread stack context is stored (in a trap) and the pre-empting code takes over control (i.e. it is run the CPU core).

In general, the PROCESS_NAME rarely relates to the cause.

re: The Cases of the Blue Screens: Finding Clues in a Crash Dump and on the Web

MikeC — Thu, 10 Mar 2011 17:26:00 GMT

Thanks for the post Mark. I'm working to wrap my brain around Windbg. Can someone answer the following? When looking at a Minidump file, what does the PROCESS_NAME field refer to?

Case in point. We have some HP Notebooks and desktops that recently started crashing after KB2393802 was applied. The culprit was an an Intel Graphics Driver. Once updated the issue was resolved. The PROCESS_NAME in each of the notebook dumps refered to HPWA_Main.exe, while the desktops referred to iexplore.exe. I can draw the link between IE and the video driver but where does the Wireless Card fit into this? Thanks for any insight!

re: The Cases of the Blue Screens: Finding Clues in a Crash Dump and on the Web

AndrewRichards — Mon, 28 Feb 2011 17:32:35 GMT

@ Great post:

When diagnosing MSI issues, enable the 'voicewarmup' logging (support.microsoft.com/.../314852) and do a ProcMon capture. The MSI log will tell you the reason, or will help you identify what part of the ProcMon to review.

re: The Cases of the Blue Screens: Finding Clues in a Crash Dump and on the Web

Great post — Sat, 12 Feb 2011 22:26:07 GMT

Great post as usual, and nice information by Andrew in the comments! I will have to remember this manual crash dump generation procedure to help try and find problems in a system.

It's always hard finding why an application isn't working, or a crash isn't working, etc.

Mark, I'd love to see a post about how to diagnose and troubleshoot installation/windows installer errors and how to do some analysis for cleanup. I've run into a lot of situations where for some reason certain applications won't install properly and aren't uninstalled cleanly. Trying to repair the app fails as well.

re: The Cases of the Blue Screens: Finding Clues in a Crash Dump and on the Web

Miro — Sat, 05 Feb 2011 13:18:17 GMT

@ Glenn:

Symbol files are based on the dump file you are analyzing (to be more precise, they are based on the type and version of each specific module located in the dump). You can use x86 WinDbg to look at x64 crash dumps and vice versa.

re: The Cases of the Blue Screens: Finding Clues in a Crash Dump and on the Web

Glenn Faustino — Wed, 02 Feb 2011 06:12:31 GMT

Excellent Article as always Mark.

With regards to Symbol files, is it based on the client with WinDBG installed or the type of dump file I'm analyzing?