Great information on gathering memory dumps. However users should not get frustrated if they do not completely understand the crash report from these memory dumps. Memory analysis is still an emerging field of study (in my opinion).
Another tool to get another type of memory dump is ProcDump.exe release by sysinternals (Microsoft) in September 2009 (updated in August). http://live.sysinternals.com/
"This new command-line utility is aimed at capturing process dumps of otherwise difficult to isolate and reproduce CPU spikes. It also serves as a general process dump creation utility and can also monitor and generate process dumps when a process has a hung window or unhandled exception"
Analysis of a Memory Dump incase of a Blue Screen of Death (BSOD), System freeze or deadlock OR Performance issues, etc...
Perfect steps and explanation for BSOD related dumps..
For NON-BSOD crashes or as we have called it as System freezes, performance issues OR prgram crashes in the PPT we might also be able to use the application crash dump generated by Dr. Watson at the location:
C:\Documents and Settings\All Users\Application Data\Microsoft\Dr Watson\user.dmp
Great information withThe Tool mentioned in the PPT - DebugWiz, this works great in cases where you need to generate a log in .txt (Example: debuglog.txt) which could then be easily sent for a review.. I could be wrong as I have not used DebugWiz a lot, but I guess it by default runs the !drivers which is now called the lm N T extension command after WinXP which helps us collect most of information needed.
Incase if one wants to gather specific information like Stop error code and its parameters from a Dump we could try windbg (Microsoft Tool) for Dump Check and Analysis
"windbg" would allow us to run extension commands on the DMP file for a desired output...
most commonly used commmands with windbg:
!analyze -show command displays the Stop error code and its detailed parameters
!analyze -v command displays verbose output of teh dump
lm N T command lists the specified loaded modules/drivers (before WinXP called as !drivers)
Keeping this post specific to Analysis of SEP or SEPM related issues withSystem freeze or deadlock OR Performance issues, etc...
Best command I feel is !analyze - v (which most of the times gives a fair idea of the source driver, application causing the issue)
(which most of the times gives a fair idea of the source driver, application causing the issue)
In !analyze -v we only need to look at the following as a first steps of Analysis of the issue / conflict with driver, system, application, etc... file
MODULE_NAME: xxxxxx
IMAGE_NAME: xxxxxx.sys
After the file driver, system, application, etc... file is identified, track the parent service, driver, application, etc... associated with the file and the FIRST STEP after identification could be to try an UPGRADE for the identified object.
In case where upgrade for the identified component does not help.. we might want to submit the analysis for bug check and fix for the same In some cases you might face issues executing the commands on a DMP, this migh usually happen in case if the DUMP file generated is not complete OR corrupt due to some reason..
In such cases it would recommended to use the Dumpchk.exe (Microsoft Tool) to check a memory dump file.
We may simply try
Example: c:\dumpchk.exe -q which would perform a quick test and after checking the Dump file it would give the status in clear text
Great content, I'm sure folks
Great content, I'm sure folks will find this helpful.
Oh, that a man's reach should exceed his grasp
Great information on
Great information on gathering memory dumps. However users should not get frustrated if they do not completely understand the crash report from these memory dumps. Memory analysis is still an emerging field of study (in my opinion).
Another tool to get another type of memory dump is ProcDump.exe release by sysinternals (Microsoft) in September 2009 (updated in August). http://live.sysinternals.com/
"This new command-line utility is aimed at capturing process dumps of otherwise difficult to isolate and reproduce CPU spikes. It also serves as a general process dump creation utility and can also monitor and generate process dumps when a process has a hung window or unhandled exception"
Nice Work AMOL
Nice work Amol..
Analysis of a Memory Dump incase of a Blue Screen of Death (BSOD), System freeze or deadlock OR Performance issues, etc...
Perfect steps and explanation for BSOD related dumps..
For NON-BSOD crashes or as we have called it as System freezes, performance issues OR prgram crashes in the PPT we might also be able to use the application crash dump generated by Dr. Watson at the location:
C:\Documents and Settings\All Users\Application Data\Microsoft\Dr Watson\user.dmp
Great information withThe Tool mentioned in the PPT - DebugWiz, this works great in cases where you need to generate a log in .txt (Example: debuglog.txt) which could then be easily sent for a review.. I could be wrong as I have not used DebugWiz a lot, but I guess it by default runs the !drivers which is now called the lm N T extension command after WinXP which helps us collect most of information needed.
Incase if one wants to gather specific information like Stop error code and its parameters from a Dump we could try windbg (Microsoft Tool) for Dump Check and Analysis
We may download and install windbg, also known as Debugging Tools for Windows from:
http://www.microsoft.com/whdc/devtools/debugging/default.mspx
"windbg" would allow us to run extension commands on the DMP file for a desired output...
most commonly used commmands with windbg:
Keeping this post specific to Analysis of SEP or SEPM related issues with System freeze or deadlock OR Performance issues, etc...
Best command I feel is !analyze - v (which most of the times gives a fair idea of the source driver, application causing the issue)
(which most of the times gives a fair idea of the source driver, application causing the issue)
In !analyze -v we only need to look at the following as a first steps of Analysis of the issue / conflict with driver, system, application, etc... file
MODULE_NAME: xxxxxx
IMAGE_NAME: xxxxxx.sys
After the file driver, system, application, etc... file is identified, track the parent service, driver, application, etc... associated with the file and the FIRST STEP after identification could be to try an UPGRADE for the identified object.
In case where upgrade for the identified component does not help.. we might want to submit the analysis for bug check and fix for the same
In some cases you might face issues executing the commands on a DMP, this migh usually happen in case if the DUMP file generated is not complete OR corrupt due to some reason..
In such cases it would recommended to use the Dumpchk.exe (Microsoft Tool) to check a memory dump file.
We may simply try
Example: c:\dumpchk.exe -q which would perform a quick test and after checking the Dump file it would give the status in clear text
Output Example:
**************--> This dump file is good!
Thanks :-)
Kedar Mohile
http://kedarmohile.blogspot.com
thanks for this information I
thanks for this information I can use this for future reference
:-)
A useful presentation
A useful presentation
Got it, it will be useful
will share with our team mates.
Got it, it will be useful
will share with our team mates.
Searching for this
Thanks:)
:)
:)
Brandon Boyd Rocks!
Would you like to reply?
Login or Register to post your comment.