Hi
I would like to call an API function from within an exception handler
before returning ExceptionContinueExecution..
However, the operating system terminates the program.
Anyone have any help with this?
It sounds like your exception handler is not working if the OS closes the program. It probably depends on the exception but most you can recover from if you handle it correctly.
I would show some code, but i can't at the moment from my location.
But yeah, the handler worked perfectly without any call to another api.
Some things i tried were to save all registers and flags with pushad/pushfd..no good.
What I was just thinking was that GetThreadContext/SetThreadContext may help..but they
both need to be called.
In the kernel, it seems to do a check on values of the context returned on ExceptionContinueExecution.
Anyone who knows of anything to do with this, help would be appreciated.
Thanks for response Hutch.
Quote from: Kernel_Gaddafi on March 03, 2005, 11:46:15 AM
Hi
I would like to call an API function from within an exception handler
before returning ExceptionContinueExecution..
However, the operating system terminates the program.
Anyone have any help with this?
Does the OS terminate the program silently?
If so, you probably got new exception when calling the API from within the handler and you probably don't handle such situation in your handler, so the API is called again, it throws exception again, your handler is called again... and you get stack overflow and OS will silently kill your process.
If there was an exception while executing the handler, bit 4 is set in EXCEPTION_RECORD.ExceptionFlags (sometimes called EXCEPTION_NESTED_CALL, but it is missing in windows.inc). If so, you should execute another as simple as possible code to handle it.
pushad is useless cause SEH chages the stack
Try to back up your register to somewhere else like this
mov [backup_ebp], ebp
and restore ebp from [backup_ebp] in SEH
probably ebp is the main problem when calling API.
I'll post some code next time i get a chance.
I never bothered with since the first post.
We'll see what happens..perhaps its as was said..an exception handler set up by the called API
which doesn't replace the old one maybe?
i don't know.