Generating a memory dump for a crashing process
-
![]()
Generating a memory dump for a crashing process
Summary:
When faced with a crashing process or application, the following procedure is one way to obtain useful information regarding the specifics of the crash, and hence the likely cause:
1) Download and install either the 32-bit or the 64-bit "Debugging Tools" package, depending on your OS type: Debugging Tools for Windows - Overview
2) Open a CMD prompt and CD to the folder where you installed the debugging tools.
3) Run this command after substituting the real executable name for <ProcessName> in the example:
cscript adplus.vbs -crash -nodumponfirst -minionsecond -quiet -pn <ProcessName>.exe
4) Reproduce the application/process crash.
5) Find the new folder in that same location with a DMP (memory dump) file.
In that dump folder you should find 2 DMP files:
a) A massive one (hundreds of MB) with "1st_chance" as part of its name.
b) A much smaller one (few MB at most) with "2nd_chance" in the name.
It's (b) that is of primary interest. Zipped up, that file may only be a few hundred KB in size - small enough to upload here.
=================================
Background Information:
Unlike a BSOD, a crash in a non-critical process does not normally affect the rest of the operating system (OS). Instead, once the OS notices that the process has attempted to do something undesirable or impossible, such as accessing memory which does not belong to it or attempting to divide by zero due to programming bugs, the offending process is shut down to prevent further damage.
To the user, this looks like an application crash, although in more recent versions of Windows the wording in the user interface has been softened to refer to an application as having "stopped working". The event logs will frequently record some summary information about the crash conditions, but unless a 3rd-party module (usually a DLL) is specifically fingered by the event description, it is difficult to proceed based on the event information alone.
By attaching a debugger to the process using the steps above, a crash can be "recorded" in the sense that a memory dump is produced which contains far more information than the textual event description. Analysis of the memory dump using techniques similar to those employed during BSOD troubleshooting can frequently pinpoint the cause of the application crash.
Last edited by H2SO4; 03 Nov 2009 at 06:10.
-
-
What if I don't know the process name?
I'm getting blue screens and shut-downs and I 'believe' it has to do with CPU temps but I can't prove it. I followed the previous 2min drill and set up windbg and the symbol path.
I kinda follow the rest of the debugging info but how do I figure out what process to attach 'to'? I currently only have one gig of RAM so the blue screen pretty much just flashes by and when the machine doesn't blue screen it just shuts down and the screen goes black.
I've looked at more logs in the past week than I knew existed. I would appreciate any help you can give me.
I'm running an EliteGroup (ECS) GeForce 7050M-M motherboard and an AMD Phenom 9950 Quad-Core Processor. As I said I currently only have one gig of Ram, more after the first of the year.
What other info could I provide that would help?
Thanks in advance.
J. R.
-
Navigate to C:/windows/minidump and zip up the .dmp file and attach it to your next post for analysis...
-
-
Dump problems
Sorry, I should have mentioned that. The 'minidump' folder is empty. I also looked for the 'memory.dmp' file but it isn't on the drive.
Do I need to set something in 7 to ensure that the .dmp files are generated?
J. R.
-
- Click Start, point to Settings, and then click Control Panel.
- Double-click System.
- Click the Advanced tab, and then click Settings under Startup and Recovery.
- In the Write debugging information list, click Small memory dump (64k).
-
![]()
Dump Problems
Thanks Tews:
Well, I've got it all setup as you instructed. Last night after I created the settings, I decided to call it a night. About fifteen minutes later, with the machine sitting idle and the three cores running at 1% or less, with memory usage at approximately 55% and CPU temps around 94 F, the system randomly shut down again. No blue screen, just 'click' and shut down to power off and black screen.
After waiting for a short time, I rebooted and checked the 'windows/minidump' folder, it is empty.
At this time I think I'm going to start working my way through the system restore point list, as suggested a while back. I've been creating a restore point before I install anything, regardless how trivial. I've also got a system image of the system when it was running fine.
All it will cost me is time. I can use my other XP Pro SP3 system just as I have been all along. There is another thing I forgot to mention, my Win7 machine is a clean install on new hardware.
As soon as I get anymore info, I'll get back to you. Many thanks for your patience and help.
One last question, what memory checker would you recommend I use to check my RAM? Do I need a 64bit tool or?
I'll be back, 
J. R.
-
-
Use Memtest86 to check your RAM ... get it -=> here
-
-
ProcDump from Sysinternals:
ProcDump is a command-line utility whose primary purpose is monitoring an application for CPU spikes and generating crash dumps during a spike that an administrator or developer can use to determine the cause of the spike. ProcDump also includes hung window monitoring (using the same definition of a window hang that Windows and Task Manager use) and unhandled exception monitoring. It also can serve as a general process dump utility that you can embed in other scripts.
More Info : ProcDump
-
never mind, i figured that part out. now im confused by "3) Run this command after substituting the real executable name for <ProcessName> in the example:
cscript adplus.vbs -crash -nodumponfirst -minionsecond -quiet -pn <ProcessName>.exe"
what am i supposed to replace process name with?
Quote