Prev: Enumerating handles in processes (C++) like procxp does
Next: How LocalFree find how much it has to free
From: nick.smith2.uk on 20 Jun 2008 09:44
Hello,

I have a simple .net program which makes a call to an unmanaged DLL.
The DLL is designed to generate exceptions as it's running. These
exceptions are normally caught by the Structured Exception Handler
chain. The DLL function adds it's own SEH record to the start of the
chain when it is called and removes it before returning.

The problem I am having is that the program terminates when it
encounters the first exception (which happens to be an int3). The
problem seems to arise only when the program is compiled to
target .net framework 2.0 or later and is run on Windows Vista.
Targetting .net 2.0 or later and running it on XP works fine.
Targetting .net 1.0/1.1 and running on either XP or Vista runs fine.

Windows gives me a "your program has stopped working..." box, the
screenshot of which is here:
http://kuro.homelinux.net/screenshot.jpg

The Exception Code 0x80000003 in the screenshot refers to the int3
that is causing the problem.

Any suggestions as to how I can get my unmanaged code to handle it's
own exceptions would be greatly appreciated.

Cheers,

Nick Smith.
From: Jeroen Mostert on 20 Jun 2008 14:21
nick.smith2.uk(a)gmail.com wrote:
> I have a simple .net program which makes a call to an unmanaged DLL.
> The DLL is designed to generate exceptions as it's running. These
> exceptions are normally caught by the Structured Exception Handler
> chain. The DLL function adds it's own SEH record to the start of the
> chain when it is called and removes it before returning.
>
> The problem I am having is that the program terminates when it
> encounters the first exception (which happens to be an int3).

That's a breakpoint exception. Those are generated on purpose, and they are
handled by the kernel before your application sees them (which is why
exception handlers will not avail you). If no debugger is attached, you get
an unpleasant dialogue. Run the thing under a debugger to see what the
problem might be.

> Any suggestions as to how I can get my unmanaged code to handle it's
> own exceptions would be greatly appreciated.
>
Simply put, breakpoint exceptions shouldn't occur in production code. You
can't really handle them, other than the obvious sucky technique of wrapping
the app in a process that acts as a debugger.

--
J.
http://symbolsprose.blogspot.com
 | 
Pages: 1
Prev: Enumerating handles in processes (C++) like procxp does
Next: How LocalFree find how much it has to free