Proper handling of .NET exceptions

[chen-456]

UPDATE: My problems are solved. For a quick outline of my problems and their solutions, see my last comment.

---

AFAIK, the current behavior when a .NET exception is caught, is to simply raise a Win32 exception with code 0xe0434352. It is hard to know the details of the exception, which makes debugging very difficult.

I'm currently having a hard time debugging a C# shim which is expected to be called from Python. It could be a lot more handy if I could know the details of the exceptions.

My story:

I was unaware that .NET assemblies should be put in the same directory as the executable file (putting them in the current directory or %Path% did not work). So I always get a 0xe0434352 whenever I call any of the [DllExport] functions. I tried hard to rearrange my code and see if anything changes, but without success. Finally, by using .NET reflection, I realized that I should try to add the current directory to the .NET search path, using the instructions on Stack Overflow.

Currently, I'm facing another problem, that I'm unable to call a [DllExport] method from another [DllExport] method (I realized that by changing my code). For example, the following code did not work:

[DllExport]
public static int GetWidth() { ... }

// Calling the following method results in 0xe0434352
[DllExport]
public static void ProcessImage()
{
  int width = GetWidth();
  ...
}

If there were any way to catch these exceptions, it could be really helpful.

Anyway, thank you very much for making this library, it is really amazing when it works.

[3F]

This is duplicate of #94. Just follow my instruction there.

Also please note #156 in a future possible case.

Anyway, thank you very much for making this library, it is really amazing when it works.

I am glad to hear this!

Thanks for using,
-- Denis

[chen-456]

Thank you for your quick reply. What I want to know is, how could I get the details of the exception when an exception happens? In my case, Python only tells me the following:

OSError: [WinError -532462766] Windows Error 0xe0434352

A Visual Studio debugger cannot catch any exception either. It really took me too long to diagnose when such problem happens.

[3F]

@chen-456

• the C++ part #83 (comment)
• create dll based on 3rd dll #93 (comment)
• Exception thrown in managed DLL is not handled properly #85
• https://github.com/3F/Examples/blob/master/DllExport/BasicExport/UnmanagedCppConsole/UnmanagedCppConsole.cpp

upd.

I forgot to clarify, that the mentioned problems and other such as seh and some memory violation are typically outside the module under debug:

#125
#130

[chen-456]

Thank you very much for providing me such solutions! I have finally solved this problem.

I want to write up some tutorial for catching any 0xe0434352 exception in Visual Studio 2019, so anyone who encounters this problem can check this to see if it helps. (The actual text on the UI may differ, since I do not use Visual Studio in English.)

• If you need debugging symbols, uncheck "Use our IL Assembler" in DllExport's configuration dialog and rebuild your project.
• In the "Attach to process" dialog, make sure you checked both "Managed code" and "Native code" in the "Attach to..." box.
• After attaching to the target process, in the "Exception Settings" tab, make sure "Common Language Runtime Exceptions" and "Managed Debugging Assistants" are checked. (Managed Debugging Assistants are necessary for catching exceptions like being unable to load assembly.) If you are not sure, just check them all.
• Now run your code and you should be able to catch any annoying exceptions!

[3F]

@chen-456

We're talking about different problems! Your initial issue points to #94.
However, this is not the same if we're talking about problems with common debugging at runtime in mixed environment.

You just voiced about "to catch any annoying exceptions" while initially it was "If there were any way to catch these exceptions" (your src points exactly to #94 issue)

But finally your latest post points to this issue: 3F/coreclr#3

[3F]

Well, I see :) mixed problems. My thoughts, as I said, were about seh and some memory violation or like, for the term of "these" (because of src).

Still a duplicate, thus please read all related issues above.
Thanks for clarifying information to our users!

[chen-456]

Yes. Let me clarify for readers in the future, all the problems I have met were:

1. Being unable to load .NET assemblies / DLLs from outside the program directory (even if %PATH% was set)
2. Being unable to call [DllExport] methods from [DllExport] methods
3. The Python console not printing any detailed information upon such .NET exceptions (it just says Windows Error 0xe0434352)

Finally, my solutions are to:

1. Write another .NET DLL that injects to the assembly search path (also try pre-processing with ILMerge, as stated in the Wiki) (related: How to reference other projects with DllExport #156)
2. Avoid such manners and add another layer of indirection (related: cannot call a Exported function A from Exported function B? #94)
3. Use Visual Studio debugger to catch those .NET exceptions, and it will show their details (as in my last comment)

No problems about SEH / access violations, I believe.

At last, thank you for all your hard work!