0

I have a WPF Application, and I must load the DLL cc3260mt.dll I call it by using LoadLibrary(), but for whatever reason I am getting an ArithmeticException.

Here is what my code looks like :

public partial class MainWindow : Window
{
    [DllImport("kernel32.dll")]
    static extern IntPtr LoadLibrary(string dllToLoad);
    [DllImport("kernel32.dll")]
    static extern IntPtr FreeLibrary(IntPtr hModule);

    public MainWindow()
    {
        InitializeComponent();

        try
        {
            string cc3260mtPath = "dll/cc3260mt.dll";
            IntPtr cc3260Link = LoadLibrary(cc3260mtPath);
        }
        catch (Exception ex)
        {
            Console.WriteLine("ERROR : " + ex.Message);
        }

    } // <-- This is where I get the Exception.
}

When I run my code step by step, I can clearly see that the exception appears when I get out of my MainWindow() class.
Do you guys have any idea what gets me this exception ?

Hyarantar
  • 217
  • 1
  • 12
  • 3
    Presumably it will be the answer to this question... http://stackoverflow.com/questions/21677867/c-sharp-freelibrary-arithmeticexception – ta.speot.is Feb 12 '14 at 09:43

1 Answers1

3

That is the C runtime support library for old Borland C or C++ programs. And yes, it does something that's very incompatible with .NET code in general, and WPF in particular, it reprograms the floating point unit control register. It enables hardware exceptions, triggered when a floating point operation fails. Particularly problematic in WPF because is likes to use Double.NaN a lot. Which generates an FPU exception, the CLR intercepts it and re-raises it as an ArithmeticException.

You will have to undo what this DLL did and restore the FPU control word. This is problematic, .NET doesn't give you direct access to the hardware like that. There is however a trick you can use, the CLR automatically reprograms the FPU when it handles an exception. So you can intentionally generate an exception and catch it. Like this:

    IntPtr cc3260Link = LoadLibrary(cc3260mtPath);
    try { throw new Exception("Ignore this please, resetting the FPU"); }
    catch (Exception ex) {}

Do note the consequence of this, you'll now have the native code running without the exceptions it normally relies on. Maybe that will work.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Thanks a lot, now it is working, my WPF app is running properly. I'll keep in mind your note and pay attention to it. – Hyarantar Feb 12 '14 at 13:27
  • 1
    +1 Constantly amazed by the depth and breadth of your knowledge. – ta.speot.is Feb 12 '14 at 22:24
  • Also be aware that the entry point code from the loaded library (DLLMain) will be run again on any new threads that are created, which will not be resolved by the exception thrown on the original thread, as suggested above. To fully address this, it would be necessary to create a new DLL that resets the FPU control word in its entry point and LoadLibary that DLL after the "bad" DLL. Then, on any new threads, the two entry points will be called in sequence, resulting in the new thread having the expected FPU control word. – jlspublic Jun 02 '18 at 22:01