http://www.codeguru.com/Cpp/V-S/debug/article.php/c4419/

-cb

@cbenoi1: I'd prefer to wire a structured exception handler function to the MiniDumpWriteDump
function instead. You can open minidumps in visual studio .net, or the free WinDbg debugger,
and debug symbolically.

Also, to debug "hangs", you probably need a watchdog thread which you can trigger,
and which will create a minidump of your entire process before killing it, if you
want automated diagnostics collection.

A core dump, and a kill -ABRT, is so much simpler on UNIX ;-)

Quote:

Original post by hplus0603 A core dump, and a kill -ABRT, is so much simpler on UNIX ;-)

You can use drwtsn32 to kill a PID and generate the dump file.

drwtsn32 -p PID

Where PID is the process id you wish to kill. I don't see the linux equiv. being so much simpler.

Although, for a process that hangs, wouldn't it be better to attach the debugger to that process?

-Halo7

Quote:

Where PID is the process id you wish to kill. I don't see the linux equiv. being so much simpler. Although, for a process that hangs, wouldn't it be better to attach the debugger to that process?

I did not know of that command. I agree, it's the same as "kill" (although less easy to find :-)

Attaching the debugger is only an option if you're there to look at it, and customers aren't waiting to use the process again. In a production environment, neither is actually the case, so capturing state for post-mortem diagnostics is your best bet. Certainly beats just restarting and forgetting.