CODEWITHSUNDEEP
c#.netexceptioncompact-framework
IronicMuffin
IronicMuffin

Reputation: 4202

How come a line of code in a try/catch block still causes the whole application to crash?

I've been battling this for a few hours now, and it may just be that I don't understand reference assemblies as well as I should.

I have a .NET CF 1.0 application running on Windows CE 4.2/5.0.

There is a managed assembly that is part of the SDK for the device that I added as a reference to my project.

Most of the time, everything works great. I can call the methods and successfully modify the state of the device (e.g. set the keyboard state or dim the backlight).

On some devices, when my application hits the code that references the DLL, it just blows up on itself

My problem is that I can't recover from this. The code is fully contained in a try/catch catching a generic Exception:

try
{                   
    if (Terminal.API.UnitAPI.KbdGetKeyInputState() == 
                         (int)Terminal.API.KbdState.AlphaOn)
     Terminal.API.UnitAPI.KbdSetKeyInputState
                          (Terminal.API.KbdState.AlphaDown);
}
catch (Exception e) 
{
    log("Error loading DLL: " + e.Message);
}

If anyone has any ideas on how to recover correctly from this, I would appreciate it. Thanks.

Upvotes: 0

Views: 419

Answers (4)

DxCK
DxCK

Reputation: 4552

Mistakes in the declaration of unmanaged functions, in using unmanaged functions, or bugs/hacks/workarounds inside the unmanaged code can break the process memory, results in AccessViolationException, ExecutionEngineException and crashes, depending on the broken location in the memory, it can change between various machines and states of the application.

A specific location in your code can cause all of this symptoms even if previously called unmanaged function broke the process memory and completed successfully without any of above symptoms.

First of all, validate the unmanaged function declaration, especially int/uint/IntPtr fields. Second, validate that you sending expected values, and non released pointers (IntPtr) with enough memory allocated for them.

Upvotes: 0

Ali Tarhini
Ali Tarhini

Reputation: 5358

exceptions that occur within native APIs cannot be handled. this is the natural behavior becuase a try catch block interprets managed exceptions only.

Upvotes: 2

cdhowie
cdhowie

Reputation: 169353

If your assembly A references another assembly B, then B is not actually loaded until the first method is JITed that references something in assembly B. If assembly B is not available, a runtime crash will occur while JIT-compiling your method, not when executing the call. This exception cannot be reliably caught, because it is not actually an exception.

If this referenced assembly may not be available on some platforms, you should instead load it via reflection. This mechanism will throw an exception that you can catch.

Upvotes: 2

Walter
Walter

Reputation: 2560

You may want to take a look at this question that I raised a while back. The root to my issue was that the exception that was thrown did NOT inherit from System.Exception so it was not getting caught.

Upvotes: 0

Related Questions