views:

1101

answers:

4

On a customer machine (WinXP SP2) to which I have no access, I have a Win32 EXE (unmanaged C++) that crashes on startup. I guess the best way to troubleshoot this is to obtain a (mini-)dump and analyze it later with windbg or similar.

Now, I would normally tell the customer to install Debugging Tools for Windows and run

cscript adplus.vbs -crash

However, it appears that you can't use adplus for apps that crash on startup (http://support.microsoft.com/kb/q286350/ says that "Do not use ADPlus in the following situations: If you must troubleshoot a program or process that quits unexpectedly during startup"). The same article says "use User Mode Process Dump", but I failed to install it successfully.

Any idea of how to get a dump of a process that crashes on startup on Win32?

+6  A: 

You can install WinDBG on the client machine and then use "Image File Execution Options" and set WinDBG to open once that the process has started. Then run the crashing process and WinDBG will open up immediately. press g (Go) and wait for the process to crash then type *.dump /mfh [dump file name] *. Now you have dump file that you can debug.

Shay Erlichmen
Worked wonderfully. Thanks. Minor edit to your answer: after ".dump /mfh" one needs to add the dump filename.
Guido Domenici
+7  A: 

Alternatively you may set up your own dump generation framework which automatically creates a process dump when any Unhandled exception is encountered. This would avoid clients having to install Windbg.

Use SetUnhandledExceptionFilter Win32 API to register the application level exception handler at the application start up. The registered callback function is called whenever there is any exception which is not handled. U may then create the process dump using MiniDumpWriteDump api from DbgHelp.dll.

Sample Code:-

LONG WINAPI My_UnhandledExceptionFilter(struct _EXCEPTION_POINTERS* ExceptionInfo)
{
    HANDLE hFile = CreateFile("FileName",
      GENERIC_WRITE,
      0,
      NULL,
      CREATE_NEW,
      FILE_ATTRIBUTE_NORMAL,
      NULL);

    MINIDUMP_EXCEPTION_INFORMATION aMiniDumpInfo;
    aMiniDumpInfo.ThreadId = GetCurrentThreadId();
    aMiniDumpInfo.ExceptionPointers = ExceptionInfo;
    aMiniDumpInfo.ClientPointers = TRUE;

    MiniDumpWriteDump(GetCurrentProcess(),
      GetCurrentProcessId(),
      hFile,
      (MINIDUMP_TYPE) (MiniDumpWithFullMemory|MiniDumpWithHandleData),
      &aMiniDumpInfo,
      NULL,
      NULL);

    CloseHandle(hFile);

    return EXCEPTION_EXECUTE_HANDLER;
}


int main(int argc, char* argv[])
{
    SetUnhandledExceptionFilter(&My_UnhandledExceptionFilter);

    // User code throwing exception..

    return 0; 
}

NB:- The registered exception filter is not called when the process is being debugged. So during debugging if you put breakpoint in the exception filter function dont be surprised if it does not hit even after causing an Unhandled Exception.

Canopus
That's the way I do. :-)
yves Baumes
+1. That's just what I was looking for!
Simon H.
+2  A: 

Here is a nice way to collect Vista SP1 crashes:

http://msdn.microsoft.com/en-us/library/bb787181%28VS.85%29.aspx

No need to install anything on the machine!

A: 

Installing developer tools on a client machine would be my last resort, I must admit I hate the idea especially where there are alternatives that will work for you.

First sign up for WinQual. You'll now get access to crash dumps and other error from your customers automatically. As I recall this is a free service, no reason not to use it.

Since WinQual will likely take a while for the crash dump to get to you, and it is always nice to be a little more responsive to customers especially when you application crashes, use Dr. Watson. As I recall when the crash occurs, before clicking on the dialog you can run drwatsn32 from Start->Run or the command line and Dr Watson will pop up. At this point dismissing the crash dialog will generate a crash dump file. Should this fail, install Dr Watson by running it with the -i parameter on the command line.

Stephen Nutt