Clearing up confusion over the proposed crashdump cut
Clearing up confusion over the proposed crashdump cut.
As I posted in my last blog, Scott is soliciting feedback about a proposal to cut support for an old dump format.
There has been some confusion over this, so I wanted to throw in my two cents.
Crashdumps aren’t the only (or recomended) way to save a full-memory dumps. The 'minidump' format is the preferred format for saving dumps of any size. You can save a minidump with heap using '.dump /ma' in windbg/cdb/ntsd. The crashdump format was lacking in many respects, so I encourage everyone to stop using it, even if VS continues to support it.
We sometimes get a request to use dbgeng (the windbg engine) in Visual Studio. I can understand the appeal of this, but honestly it would make no one happy. True windbg users would still use windbg -- no benefit there. VS users would be unhappy because it would feel like windbg. We sometimes take feature ideas from windbg (example: .cxr), and we someday might share more code with windbg, but we are never going to be able to just use their engine.
Only the Win 2k version of Dr. Watson produces crashdumps. Newer version of Windows use minidumps. The latest service pack of Win2k might even use minidumps, I haven’t checked in a while.
This change would prevent you from debugging dumps produced from Win 2k Dr. Watson, which could be a problem for some people. However, there is a great work around -- create your own unhandled exception filter. This is quite easy to do, and would make it easier to support your application. I encourage you to do this even if VS continues to support crashdumps. More on this in an upcoming blog.
Managed minidumps are definitely something that we are thinking about, and something that we desperately want to do. We realize that 'sos' is not the tool for most VS users.
Comments
- Anonymous
January 22, 2005
It might be worth pointing out that minidumps can actually contain more information than the old crashdump format (which is unfortunately called the 'full dump' in WinDbg).
A minidump created with /ma contains all process memory plus things like memory protection info, handle info, list of unloaded modules, per-thread CPU times etc. It's a strict superset of the old format. - Anonymous
January 22, 2005
I was a little disappointed in your comments about dbgeng.
There is significant internal cost to maintaining multiple debug engines. The cost to support managed code, new architectures, etc. is doubled. The windows development team uses windbg/kd/ntsd/etc rather than the nifty tools that VS is supposedly building.
The PPRC folks build nifty tools that integrate badly into VS and run standalone in the windows team.
I'm aware of the conflicting objectives, schedules, etc. but it would be nice to see more than lip service to sharing code. - Anonymous
January 23, 2005
Adam,
I am a believer that long term Microsoft should not be producing multiple debuggers, build systems, source control systems, etc. However, this does not mean that the way to solve the problem is to use dbgeng.dll in VS.
Could you use dbgeng in a VS shell? Sure, but it would act like windbg, not like VS. This wouldn't make anyone happy - windbg uisers would still use windbg. VS users would have lost their debugger.
If we wanted to solve this problem, we would need to bring the various debugger teams together and come up with a solution that everyone can use and love. - Anonymous
January 24, 2005
Perhaps I can get an answer here:
Just to clarify -- You propose dropping support for files with the USERDUMP signature but will retain those with the MDMP signature? What about PAGEDUMP files? Also, there will be no overhaul of the DBGHELP interface, right? - Anonymous
January 26, 2005
Glad to hear that you at least recognize the importance of supporting managed minidumps. We feel like we've taken a step backwards moving to .NET WRT post-mortem debug analysis of our deployed apps. - Anonymous
January 05, 2008
PingBack from http://birthdays.247blogging.info/?p=2035