One of the often overlooked enhancements that was made to Windows with the release of Vista is the capability to write a complete (large) minidump describing the state of a process from Task Manager. To use this functionality, switch to the Processes tab in Task Manager, access the right click (context) menu for a process for which your user account has access to, and select Create Dump File.
Although not as handy as having an “in-box” debugger (ntsd was most regrettably removed from the Vista distribution on the grounds that too many users were getting it and the (typically more up to date) DTW distribution of ntsd confused), Microsoft has thrown the developer crowd at least something of a bone with the dump file support in Task Manager. (It’s at least easier to talk a non-developer through getting a dump via Task Manager than via ntsd, or so one would suppose.)
The create dump file option writes a full minidump out to %temp%\exename.dmp. The dump is large and describes a fairly complete state of the process, so it would be a good idea to compress it before transfer. (I don’t know of any option to generate summary dumps that ships with the OS. However, to be honest, unless space is of an extreme concern, I don’t know why anyone would want to write a summary dump if they are manually gathering a dump – full state information is definitely worth a few minutes wait of transfer time on a typical cable/DSL connection.)
While I’d still prefer having a full debugger shipped with the OS (still powerful, even without symbol support), the new Task Manager support is definitely better than nothing. Though, I still object to the line of thought that it’s better to remove developer tools from the default install because people might accidentally run an older version that shipped with the OS instead of the newer version they installed. Honestly, if a person is enough of a developer to understand how to work ntsd, they had better damn well be able to know which version they are starting (which is really not that much of a feat, considering that the start up banner for ntsd prints out the version number on the first line). If someone is really having that much trouble with launching the wrong version of the debugger, in my expert opinion that is going to be the least of their problems in effectively debugging a problem.
(</silly_rant> – still slightly annoyed at losing out on the debuggers on the default Vista install [yep, I used them!])
A bit offtopic, hope it’s ok.
Ken -great blog btw-, I have a problem for ages now, I m posting it just in case you have any good ideas. MS Visual Studio, either is 2005 or 2008(orcas), either my host system is XP or Vista, it is always seriously messing my sytem, to a point that the use of many of my daily apps becomes problematic(unhandled win32 exceptions, illegal operations, crashes).
Most people blame and focus at visual studio JIT debugger, but this is not the source of the problem. Diasbling it completely doesnt resolve anything, the programs continue to crash just without popping out hte debugger. The thing is what is the source of these unhandled exceptions. I m always speaking of healthy programs which, prior MS VS installation, worked like a charm.
I can’t trace it, and if you look at the MSFN or anywhere at the net, there are so many people facing this problem. Any ideas?
Is VS messin any system dlls? But then again why SFC reports everything is OK?Is there any way I can easily trace the problem? And what if the faulty module is the ntdll.dll file!
Thanks for your time, Ι would be grateful for any responses,
Microsoft was correct in its conclusion that the outdated ntsd included with Windows was being confused with the modern version distributed with the Debugging Tools for Windows. However, their cure may be worse than the disease.
Imagine if Windows included an up-to-date version of ntsd with symbol support. You could have a customer at a deployment site fire up a debugging server with ntsd without even xcopying a new ntsd from DTW to his system. You could sit down at arbitrary systems with hung or CPU hogging processes, attach, point at the web symbol store and examine thread stack traces and other state to diagnose the problem. If MS-DOS could include DEBUG 25 years ago, it seems a bit off to get NTSD out of the way in Windows Vista.
Frankly, Microsoft should be adding more diagnostic and debugging tools to the base OS distribution, not removing them.
It seems to me this specific instance of confusion could have been easily and more productively solved by renaming the OS version of ntsd to something else (like “ntsymdbg” or whatever). The opportunity of Vista’s release could have been taken advantage of to add web symbol store support to the OS debugger.
Koby: Yeah, I know they were getting -some- complaints. Still, I definitely agree with you: this seems to be a pretty extreme case of throwing the baby out with the bathwater, so to speak. Unfortunately, it seems that my complaints have thus far not carried enough weight to get ntsd reinstated…
I believe the reason why they were not updating the debugging distribution that shipped with the OS regularly was that the debugger team has fairly limited resources, and there’s a whole lot of testing and other quality control related hurdles with pushing out updates to everyone running Windows. Still, as you point out, there are plenty of other “middle ground” solutions that are far less drastic than taking the “sledgehammer approach” and discontinuing shipping ntsd period.
(BTW, I’d encourage you to send your thoughts on the subject to the WinDbg feedback alias (in a rational fashion of course) – every customer that complaints about ntsd going AWOL adds more weight to the idea that it should be put back in the base OS distribution.)
Honestly, while symbol support would be great, I used the built-in ntsd plenty even without symbols – often times just being able to set breakpoints on exported APIs is enough to get the job done anyway, and one can always pull up the addresses for non-exported symbols on an equivalent machine in a pinch.
Jim: Hard to say without more information, but crashes in NTDLL are very often the result of heap corruption. Perhaps you’ve got some sort of helper dll (e.g. shell extension or the like) that is getting itself loaded into many processes and is causing problems? You might poke around a bit with the debugger and see if there is a common third-party module in the call stacks of many of the crash sites (though this is never a hard and fast thing if heap corruption is a possibility). FWIW, I’ve installed VS 2005 on many boxes and haven’t ran into this sort of problem, though I always use WinDbg and not the VS debugger.
Hi Ken,
My guess as to the removal of ntsd.exe is that the DTW installer was under a ‘no exceptions’ policy requiring it to place its directory in the path after the standard Windows dirs (system32 et al.) Having an outdated .exe ahead of you in the path (and a user-configurable application dir) is a recipe for a continuing headache.
No doubt some feel that having a debugger on the box increases security.
At least now one can have a user install DTW with default settings, type ‘ntsd’ from any ‘Run…’ box, and have some expectation that it will succeed.
I know of an entire product that was initially developed with just debug.exe, I guess times are changing.
– Marsh
The default configuration doesn’t place the Debugging Tools for Windows directory in the path, nor does it registry an AppPaths alias for any of the debugger executables. So I don’t think that is the reason, as in a default configuration, you’ll get a not found error.