_set_se_translator
in [MFC]
|
From: TonyG on 11 Sep 2009 17:21 I inherited a program and I am trying to fix a couple of things. One item is kinda wild and I will explain it here. When the program is terminated it logs an error message in the program's log. I want to understand the error message and figure out how to stop it. Typically the program is terminated by a master program that sends the program a registered message. There is a registered message handler in the mainframe class. This handler does some stuff and then calls CMDIFrameWnd::OnClose(); to terminate the program. At some point after the OnClose is called an error message is generated. The error message is generated by a function in the program called End_SetSeTranslator This function is registered in the program's App class in InitInstance() using the following code: // tell the framework to call our terminate function for major errors _set_se_translator(End_SetSeTranslator); The End_SetSeTranslator function is part of the program's code and it formats and logs an error message based on the parameters that are passed to the function. The first parameter is named "code" and my error apparently has the value EXCEPTION_ACCESS_VIOLATION. The code also extracts the address from the second parameter pInfo->ExceptionRecord->ExceptionAddress The message that the program formats is: Memory access violation. The thread tried to read from or write to a virtual address for which it does not have the appropriate access. Error code: 0xC0000005 Exception address: 0x00000000 Questions: 1) I've never seen exception handling like this. Is this good? 2) Is calling CMDIFrameWnd::OnClose() from within the mainframe class a valid way to terminate the program. 3) How do I track down the root cause of the exception? There doesn't seem to be much to go on. How will I find it?
From: Joseph M. Newcomer on 11 Sep 2009 19:23 On Fri, 11 Sep 2009 16:21:31 -0500, TonyG <TonyG(a)junk.com> wrote: >I inherited a program and I am trying to fix a couple of things. One >item is kinda wild and I will explain it here. When the program is >terminated it logs an error message in the program's log. I want to >understand the error message and figure out how to stop it. > >Typically the program is terminated by a master program that sends the >program a registered message. There is a registered message handler in >the mainframe class. This handler does some stuff and then calls >CMDIFrameWnd::OnClose(); to terminate the program. > >At some point after the OnClose is called an error message is generated. >The error message is generated by a function in the program called >End_SetSeTranslator > >This function is registered in the program's App class in InitInstance() >using the following code: > > // tell the framework to call our terminate function for major errors > _set_se_translator(End_SetSeTranslator); > > >The End_SetSeTranslator function is part of the program's code and it >formats and logs an error message based on the parameters that are >passed to the function. The first parameter is named "code" and my error >apparently has the value EXCEPTION_ACCESS_VIOLATION. The code also >extracts the address from the second parameter >pInfo->ExceptionRecord->ExceptionAddress > >The message that the program formats is: > >Memory access violation. The thread tried to read from or write to a >virtual address for which it does not have the appropriate access. Error >code: 0xC0000005 Exception address: 0x00000000 > > >Questions: >1) I've never seen exception handling like this. Is this good? **** Applications often build in SEH intercepts like this so that they can save things like the partially-modified document or otherwise take some useful action. So it is not at all unusual to find this sort of thing in a program where robustness is critical. **** > >2) Is calling CMDIFrameWnd::OnClose() from within the mainframe class a >valid way to terminate the program. **** No. PostMessage(WM_CLOSE) to the main frame **** > >3) How do I track down the root cause of the exception? There doesn't >seem to be much to go on. How will I find it? ***** Try running it under the debugger and set the debugger to trap all exceptions. joe **** Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
From: Goran on 14 Sep 2009 02:52 On Sep 11, 11:21 pm, TonyG <To...(a)junk.com> wrote: > Questions: > 1) I've never seen exception handling like this. Is this good? That's not exception handling as defined by the C++ language. That's an attempt to somehow handle what Windows calls structured exceptions (SE). Encountering this type of "exception" means that there is a bug and that the program crashed in a sense that the code lost control of it's resources, heap and stack not withstanding. IMO, this is useful as a last-ditch crash help for support and development. As long as the rest of the code doesn't think it can recover from conditions like this, I'd say it's OK. If code tries to be smart (e.g. log error and continue), this "strategy" may even do more harm than good. By any means, SEH (structured exception handling) is to be used with great caution. Goran.
|
Pages: 1 Prev: List of Code Pages API Next: A serializable view for writing line delimited text? |