Re: [vox] LUGOD advertisement...
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [vox] LUGOD advertisement...
On Fri, 22 Jun 2001, Micah Cowan wrote:
> But that's *exactly* the point! BSODs and coredumps are at completely
> different levels! UNIX coredumps are analagous to Windows blandly
> announcing that your application has quit due to some unknown error
> (except with coredumps you have a better chance of determining what
> that error was); BSODs are analogous to full-on-kernel panics (uh,
NT has the equivalent of a coredump. On a BSOD crash, it can dump the
contents of physical memory to a file, and the amount of what it drops is
controllable by the administrator. This file is useful for debugging what
happened...
I've never seen applications dump core in Windows, but presumably that's
because the debugging in Windows is done differently... (via the debug
API) ... It wouldn't be too tough to add a core-dump style feature (if it
doesn't already exist somewhere as some kind of option I'm unaware of.)
If you catch the exception with a debugger attached to the process, you might
not necessarily need such a thing as a coredump. You can use
ReadProcessMemory() and GetThreadContext() API's to retrieve relevant
information, and then use that. Somehow, when applications crash
sometimes in Windows, I get a box asking if I want to debug the
application. Methinks this prompt is brought up because somewhere in the
registry it knows that there is a debugger registered somewhere in the
system (but I am not sure.) In Visual C++, when you catch an
application for debugging, it is able to give you call stack information
too. I think this can happen if it has the debugging symbols within the
same directory as the executable... Otherwise, it's just a disassembly of
the process and register contents, iirc.
--
Pavan xxxxxx (xxxxxx@uiuc.edu) http://www.students.uiuc.edu/~xxxxxx
Computer Engineering Student University of Illinois @ Urbana-Champaign
|