Generating a memory dump for a crashing process

[H2SO4]

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.

 

[WeGrok]

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.

 

[Tews]

Navigate to C:/windows/minidump and zip up the .dmp file and attach it to your next post for analysis...

 

[WeGrok]

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.

 

[Tews]

1. Click Start, point to Settings, and then click Control Panel.
2. Double-click System.
3. Click the Advanced tab, and then click Settings under Startup and Recovery.
4. In the Write debugging information list, click Small memory dump (64k).

 

[WeGrok]

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.

 

[Tews]

Use Memtest86 to check your RAM ... get it -=> here

 

[Tews]

Holy necromancy Batman!!

 

[Capt.Jack Sparrow]

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

 

[ritzon]

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?

 

[Capt.Jack Sparrow]

im confused, "2) Open a CMD prompt and CD to the folder where you installed the debugging tools." how do you "CD to the folder"

CD is "Change Directory"

From Command Prompt you have to navigate to that location.

cd\
cd Program File\Debugging Tools for Windows (x86)\ and Hit Enter

Hope this helps,
Captain

 

[Capt.Jack Sparrow]

Starting with Windows Server 2008 and Windows Vista with Service Pack 1 (SP1), Windows Error Reporting (WER) can be configured so that full user-mode dumps are collected and stored locally after a user-mode application crashes. Applications that do their own custom crash reporting, including .NET applications, are not supported by this feature.
This feature is not enabled by default.

Enabling the feature requires administrator privileges. To enable and configure the feature, use the following registry values under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\Windows Error Reporting\LocalDumps key

Collecting User-Mode Dumps (Windows)

 

[usasma]

Another link relating to creating dump files for crashing apps:
Collecting User-Mode Dumps (Windows)

 

[quide]

hi,

I have run the cscript adplus.vbs ... (actually I've only found and used the file adplus_old.vbs to my application that runs as python.exe and this openned 3 consoles (because there are 3 python.exe running).
Unluckely, running like this doesn't reproduce the crash because it makes my application to run a little slower.
Anyway, when I've restarted the system and run my application normally (without this cscript) it stopped working. I've already uninstalled and installed my app, what does this cscript did?