Pavel Lebedinsky said:
The built-in ntsd.exe is a lot more limited than the latest version.
It should be able to generate a dump on XP and later but I'm not sure
if it supports all the options that you might need (like storing thread
times in the dump, for later analysis with !runaway).
I see your point. I came home and tried to run ntsd on my Win2k system, and
it's very much lacking in function, including the dump command.
I guess I had gotten the impression that such debugging facilities had been
part of Windows for quite some time, even though I hadn't been aware of
them. Perhaps the reason I wasn't aware was that they simply didn't exist
apart from the debuggers built into the IDE's.
I've often wondered why the old-fashioned tried-and-true method of debugging
via memory-dump had apparently gone out of fashion. Obviously, the size of
memory compared to computers of a few decades ago plays a role, but mostly
in terms of not wanting to print them out on a printer.
Still, I think programmers were given better tools, and documentation on how
to use them, back in what you call the "Stone Age" (Grrr!!)
So, apparently the idea of dumping a running application so you can go
through the entrails is only now getting seriously developed.
Well, the first thing I've got to do tomorrow is to tell the customer that I
wrote that my instructions for using ntsd are in error, since they can't get
a dump. It never occurred to me that such a facility wouldn't have been
built into a system such as Windows right from the start.
So, do I have to tell the customer to install the entire Windows debugging
package in order to get a dump out of a Win2k system, or is there a way they
get just the minimum support (like cdb.exe), or does this thing include a
whole legion of DLL's that have to be installed and registered?
These days .map files are rarely (if ever) needed. You should just generate
.pdb files for everything you build, and store a copy of source files. This
should be all you need to debug dumps or live crashes:
http://support.microsoft.com/default.aspx?scid=kb;en-us;291585
I had often wondered what all those big PDB files were, and what function
they performed. The normal documentation does not make much mention of them,
and other Windows programmers I've worked with who've used C++ did not seem
to know what they were for.
My goal for this particular situation is to try to find out why our
application is looping in this particular machine in the field. I didn't
want to have to build a special "debug" version of the program, partially
because such problems might well only show up with the original executable.
(There might be a buffer overflow or something that would manifest itself
differently if everything in the program got re-arranged.) It wasn't clear
whether the pdb had to be sent to the customer in order to run the debugger
to get a dump. I've heard of situations, from programmers working under me,
wherein programs built in debug-mode didn't fail, but only the "release"
version did. In this case, that's the version that's failing on the
customer's machine.
I certainly never saw anything that said that MAP files and program listings
were obsolete. I guess that's what provoked your "Stone age" remark. I
guess the ability to read hex is now something to be ashamed of? I don't
think so.
