Bug 14989 - running with mono, calling a dll, throw - catch inside the dll ceases to work. works with .net and earlier mono versions
Summary: running with mono, calling a dll, throw - catch inside the dll ceases to work...
Status: NEW
Alias: None
Product: Runtime
Classification: Mono
Component: Interop (show other bugs)
Version: 3.2.x
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2013-09-25 14:05 UTC by Dennis Fantoni
Modified: 2013-10-07 03:48 UTC (History)
3 users (show)

See Also:
Is this bug a regression?: ---
Last known good build:

VS2012 solution to create C# program and C++ DLL, plus binaries that fail (49.89 KB, application/octet-stream)
2013-09-25 14:05 UTC, Dennis Fantoni

Description Dennis Fantoni 2013-09-25 14:05:45 UTC
Created attachment 4991 [details]
VS2012 solution to create C# program and C++ DLL, plus binaries that fail

This archive exposes a bug in mono 3.2.3.

The problem is that local throw and catch inside a function in a dll called from a C# program will not work if running with mono 3.2.3. but the same binaries works fine with mono 3.1 or 2.x or .net.  Building the C# program with mono doesn't help.

1) unpack the archive mono323bug

2) inside, find an archive called throwfailsinmono323.zip unpack this archive somewhere, say C:\Test

3) start mono commandline and navigate to c:\Test

run consoleapplication1.exe like this :

(note the output is different)

F:\QI\test\mono323bug\mono323bug>mono ConsoleApplication1.exe
Test v0.3
CSHARP: Before call
CPPDLL:Immediatly throwing std::eception
CHARP: After Call

Test v0.3
CSHARP: Before call
CPPDLL:Immediatly throwing std::eception
CPPDLL:cpp exception caught.  Exception.what: (CPPDLL Std_exception)
CHARP: After Call

Note, that when running under .net the throw in the C++ dll throws as it should,
but when running under mono 3.2.3 - the throw works as if it was a NOP - execution continues just below the throw as if nothing had happened

enclosed are two solutions - one to create a C# program, and one to produce the C dll that outputs CPPDLL: lines

The code producing above result :

c# :

            Console.WriteLine("CSHARP: Before call");
            Console.WriteLine("CHARP: After Call");   


      cerr<<"CPPDLL:Immediatly throwing std::eception \n";
      throw std::exception("CPPDLL Std_exception");
      cerr<<"CPPDLL:AFTER THROW\n";
    catch (std::exception& e) 
        cerr<<"CPPDLL:cpp exception caught.  Exception.what: (" << e.what()<<") \n";        
    catch (...) {
        cerr<<"CPPDLL: something non exception caught \n";        

The line       cerr<<"CPPDLL:AFTER THROW\n";  is executed when running inside mono 3.2.3

it is not executed when running inside .net 4.5 or inside mono 3.1 or mono 2.x

Tested on windows7 , two different computers.
Comment 1 Dennis Fantoni 2013-10-07 03:48:10 UTC
If I am not mistaken, this bug means that the latest released windows version of mono will make any .net program fail, that calls native DLL's written with VS2012 - if the DLL internally throws and catches exceptions. Perhaps even VS2010 compiled DLL's, or perhaps even any native DLL (that relies internally on throwing and catching exceptions).

This would mean that many programs would work in normal circumstances but would behave wrongly in case of unusual things happening - which is hard to find problems.

If Possible, I would love for someone to confirm the problem by checking out the attached archive, which contains a ready-to-build solution for a C# program, and a c++ DLL (should build with VS2012). VS2012 can be downloaded as the free express version or as a timed trial.

If it works in some cases and fail in other cases, there is the possibillity of a workaround, which would be interesting as I then could flag my product as working with (latest downloadable) mono on windows, after I have implemented the workaround.

Note that the problem only exists in the newest downloadable mono for windows - the example project works fine with 3.1 and the currently downloadable 2.x.

Note You need to log in before you can comment on or make changes to this bug.