Re: SetUnhandledExceptionFilter
From: Ivan Brugiolo [MSFT] (ivanbrug_at_online.microsoft.com)
Date: 05/25/04
- Next message: Daniel Xu: "How to hook Mute, Volume Up, and Volume Down key under win98?"
- Previous message: Vinay: "preventing inside IFSFN_READ...Win98 ...Vxd"
- In reply to: Werner B. Strydom: "Re: SetUnhandledExceptionFilter"
- Next in thread: Mikko Noromaa: "Re: SetUnhandledExceptionFilter"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 25 May 2004 14:45:41 -0700
The only way to prevent at all cost a crash in the applicaiton
is to have code that can be proven all-case correct that runs over there
:-).
If your goal is to NOT crash the application from your code,
then you can do something about, but, per my experience,
you might crash the application with your module on the stack
because of some corruption in the shared state of the application.
Looking at a full dump of Word.exe and/or LotusNotes is the only way
to diagnose the problem. All other solutions are short leged.
They are useful only to the fingerpointing exercise, and not to the
resolution.
As I said in the end of the posting, a correct stack code capture
with StackWalk64 requires full symbols, that are non a cheap commodity
in terms of deployment and disk space.
Let me reinforce the concept that binlde exception filtering is bad in
general.
In the anatomy of an application crash, there are 3 times:
-1- t_corr, when a corruption in the global state happens
(overwriting a heap metadata, unloading a module prematurely, leaking
CritSec)
-2- t_det, where the corruption has a sensible side effect on some code
(for eaxmple, heap metadata is checked in the free and coalasce code path.
Paradoxically, and application that leaks will suffer less from corruptions.
A bad heap metadata will cause an access violation, the access violation is
normally dismissed in some wide exception handler)
-3- t_crash, when the alteration in the global state causes
kernel32!UnhandledExceptionFitler,
or msvcrt!abort, or a generalized application hung to happen.
Even if you can write code that runs at t_det, for example, by installing
exceptions filters
and/or vectored exception handlers, your code may run minutes after t_corr,
and, your stack trace is not that useful in isolation, and it may be useful
only
with a full dump of the process.
Writing correct code in a shared process is a matter
of cooperation of all the entities involved in that process.
It's not bad to install an unhandled exception filter in DllMain because
it's in DllMain.
It's a bad idea to attempt to chain a behavior over other behaviors
with no guarantee of what is the order and the final result for a process
that you don't own.
For code that runs in shared application, and for Microsoft applications,
you can engage (through your company) the ISV portal team to get access
to custumer reported dumps minidump that contains your module.
Or, you can change the error reporting infrastructure to report the dump to
your web site,
or, you can have the dumps to be queued in a central location.
-- This posting is provided "AS IS" with no warranties, and confers no rights. Use of any included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm "Werner B. Strydom" <bloudraak@hotmail.com> wrote in message news:uYU91WpQEHA.4000@TK2MSFTNGP10.phx.gbl... > Hi Ivan, > > Thanks for the reply. Here's some remarks: > > I'm told not to crash the application and prevent that at all cost. I'm also > told, prevention is better than cure. So, if I have an access violation, > stack corruption or something like that somewhere in my code, its best to > know about it quickly. ;) Looking at a dump of Microsoft Word or Lotus Notes > is a time consuming and expensive task. > > Stack dumps is a last resort. For that to happen, 80MB of symbols needs to > be installed. Remote debugging even a later resort [many firewalls and > companies don't allow that anyways]. We do the whole try/catch spiel. > However catch(...) doesn't tell me much as to where the access violation > happened, or that an access violation even happened (could be a third party > exception class). > > We write tests for everything except the coffee machine. For standalone > tests, the test harness installs various callbacks (_set_se_translator, > _set_unexpected, _set_new_handler etc.) which throws C++ exceptions. > Failures are reported (rather than crashing the process), and we have enough > information (from a stack trace, perhaps) to fix it quickly. What about dlls > loaded by Microsoft Word, Outlook, Lotus Notes or GroupWise? For extension > dlls I'm learning here that its a bad idea to install an exception handler > in DllMain, because its unreliable, it may effect other third party code and > may be totally hidden from you until its too late. Its a shame. > > Regards > Werner > > > >
- Next message: Daniel Xu: "How to hook Mute, Volume Up, and Volume Down key under win98?"
- Previous message: Vinay: "preventing inside IFSFN_READ...Win98 ...Vxd"
- In reply to: Werner B. Strydom: "Re: SetUnhandledExceptionFilter"
- Next in thread: Mikko Noromaa: "Re: SetUnhandledExceptionFilter"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
