Catch Win32 Exception from unmanaged code

[dh]

AppA is a console application (in C#), which uses DLLs in a unmanaged code
(C++, no source available for them).

AppB is a service (in C#), which starts AppA when needed.

When an exception of Win32 (e.g. Integer Division by Zero) thrown by those
DLLs, it will pop up an errorbox waiting for responses.

Just wondering if it's possible for either AppA itself or AppB to catch such
exceptions immediately when it occurs.

Any idea?

Thanks!

 

[forever.zet]

AppA is a console application (in C#), which uses DLLs in a unmanaged code
(C++, no source available for them).

AppB is a service (in C#), which starts AppA when needed.

When an exception of Win32 (e.g. Integer Division by Zero) thrown by those
DLLs, it will pop up an errorbox waiting for responses.

Just wondering if it's possible for either AppA itself or AppB to catch such
exceptions immediately when it occurs.

Any idea?

Thanks!

Hi,

In case of integer division by zero the exception should be converted
to the native .NET System.DivideByZeroException.
In general case if the exception will be converted to
System.Runtime.InteropServices.SEHException (you can look into MSDN to
see how exceptions are converted).
So I think you can catch them in AppA and probably it would be better
to check input so divide by zero exception doesn't occur.

HTH,
Sergey Zyuzin

 

[Willy Denoyette [MVP]]

AppA is a console application (in C#), which uses DLLs in a unmanaged code
(C++, no source available for them).

AppB is a service (in C#), which starts AppA when needed.

When an exception of Win32 (e.g. Integer Division by Zero) thrown by those
DLLs, it will pop up an errorbox waiting for responses.

The error pop-up is produced by the DLL, there is no way to do something in
the caller (C#). Also, note that exceptions cannot cross managed/unmanaged
module bounderies.

Just wondering if it's possible for either AppA itself or AppB to catch
such
exceptions immediately when it occurs.

No, there isn't. The DLL is simply not not designed to be used from Windows
Services and applications started from within Windows Services.

Willy.