How to get crash dump when a unhandled CException is thrown by a MFC app
in [MFC]
|
Prev: CString::GetLength error
Next: Want to set the width
From: Joseph M. Newcomer on 11 Jan 2010 12:24 See below... On Mon, 11 Jan 2010 01:05:29 -0800 (PST), Peter Schneider <peter.m.schneider(a)gmx.de> wrote: >On 8 Jan., 21:09, Goran <goran.pu...(a)gmail.com> wrote: >> Clear-cut theoretical answer, for me, is: code that errs should crash, >> preferably with a crash dump and as soon as possible. That's >> invaluable for the ease of development, because that helps the most in >> finding the source of the problem. >> >> Of course, in practice, things get muddy. Often, once error is >> detected, it's already too late (e.g. stranded pointer). OTOH, with >> that drastic approach, "user experience" suffers. I'd guess that >> numerous coders have been forced by their respective marketing or >> whatever departments to try to continue running even though there's >> something horribly wrong, and frankly, I can see that point, too. > >I fully agree with your theoretical answer and also with the fact that >in practice there can often will be other requirements. But the latter >depends a lot on the respective application (and maybe also company >policy). > >> I personally would not touch most of functions you list there - >> problems that cause them to be invoked are way too bad for me to try >> to get smart. So quick death there, using the default behavior. >> (Luckily, I don't remember when was the last time I got pure e.g. >> virtual call error). I do use SetUnhandledExceptionFilter to produce >> crash dump, though (but I TerminateProcess immediately after that). > >I completely agree. I'd also prefer to get a crash dump and terminate >in those cases. But as a side note: I had some problems with the >default behaviour of some of those handlers recently. The dump files >that were written looked sort of random under certain circumstances. I >posted about this to another news group and the issue is basically >still open. In case you are interested, the link is:http:// >groups.google.com/group/microsoft.public.windbg/browse_frm/thread/ >37e2f13f7ad05e6d#. It's ****] What I learned was that a "global catch" handler is not the solution under such conditions. In the system I worked on, there were hundreds of catch frames and more than half the code of the final product was involved in error recovery. The difference was that I was adding exception frames in an ad-hoc fashion; each time I had a crash, I added a new mechanism to recover from that specific incident. If you look at the Software Safety people (Parnas, Levison, et. al., work which postdates my 1976 work, and much of which evolved in the 1990s) these exception frames would have fallen directly out of the stringent design requirements imposed by software safety design methodologies. joe **** > >> WRT Java situation - I am ambivalent WRT benefits in mixing exceptions >> caused by bugs and "legitimate" exceptions (ones caused not but bugs >> but rather by "unusual" conditions). I think that such environments >> continue even in case of an error-exception is more consequence of >> general programming model �where all throws, than a conscious decision >> to do so. >> >> Goran.- Zitierten Text ausblenden - >> >> - Zitierten Text anzeigen - Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Joseph M. Newcomer on 11 Jan 2010 12:26
Catching the exception has to deal with the modal dialog. OTOH, I have come to detest modal dialogs. joe On Mon, 11 Jan 2010 06:01:47 -0800 (PST), Peter Schneider <peter.m.schneider(a)gmx.de> wrote: >On 11 Jan., 14:42, "Martin B." <0xCDCDC...(a)gmx.at> wrote: >> Check the docs for: >> virtual LRESULT ProcessWndProcException(CException* e, const MSG* pMsg); >> >> If you add a THROW_LAST() in you own, you should be able to produce a >> crash. (Except I think for the Modal Dialog Loop which contains an >> additional CATCH that is not handled via ProcessWndProcException > >Thanks for the suggestion! I will give it a try. (Unfortunately, our >app currently uses a modal dialog ...) > >Where did you find the documenation on this? >I used the following MSDN link and it doesn't seem to contain anything >on it: http://msdn.microsoft.com/en-us/library/93k07whb.aspx > >Peter > > Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm |