0

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.

Charles Bretana
  • 143,358
  • 22
  • 150
  • 216
IronicMuffin
  • 4,182
  • 12
  • 47
  • 90
  • Is a specific exception being thrown? Some can't be caught as well as others. – David Nov 26 '10 at 22:25
  • Does the method you call run in a separate thread? – KBoek Nov 26 '10 at 22:28
  • 1
    @David, shouldn't *any* exception be caught by the Exception class? – KBoek Nov 26 '10 at 22:29
  • 2
    @KBoek: Some exceptions can't be caught. StackOverFlowException, OutOfMemoryException and ExecutingEngineException come to mind. (I mention these in an old blog post discussing circumstances in which a `finally` block wouldn't be executed: http://publicvoidlife.blogspot.com/2010/07/try-and-catch-me.html) – David Nov 26 '10 at 22:32
  • @KBoek: no it runs in the main thread. @David: it is a MissingMethodException. – IronicMuffin Nov 29 '10 at 13:54

4 Answers4

2

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.

cdhowie
  • 158,093
  • 24
  • 286
  • 300
2

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

Ali Tarhini
  • 5,278
  • 6
  • 41
  • 66
0

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.

Community
  • 1
  • 1
Walter
  • 2,540
  • 2
  • 30
  • 38
  • MissingMethodException is what is thrown, and it is inherited from System.Exception. I tried to catch it specifically and it still failed. – IronicMuffin Nov 29 '10 at 14:10
0

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.

DxCK
  • 4,402
  • 7
  • 50
  • 89