1

I'm in the process of writing a wrapper DLL in C# for CAN communication DLLs through their APIs. As part of this process I need to use a security function related DLL in my communication sequence. This .Net DLL is provided by an external party as-is; I do not have the source of it, I just know how to use its methods. I have "linked" this external DLL by adding the reference to my project's references, and I can see the class and the methods within of the DLL just right. However when I'm debugging my code and get to a point where I need to call the external DLL's methods, I get the following message from VS 2019:

Your app has entered a break state, but there is no code to show because all threads were executing external code (typically system or framework code).

Managed Debugging Assistant 'FatalExecutionEngineError' : 'The runtime has encountered a fatal error. The address of the error was at 0x0323f5dc, on thread 0x3c0c. The error code is 0x80131623. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack.'

At this point my process flow is broken, even if I try to "Continue Execution", the method of the external DLL is not executed and the main code in my wrapper is relying on those methods to have executed successfully.

After debugging for a couple of days I finally got the confirmation from the developer of the external DLL that they do not "allow" this DLL to be debugged, traced, whatsoever. During my debugging I was searching for mistakes on my end, but found none. If I run my code in Release mode and start it with "Start Without Debugging", my code and the external DLL's code works as well. But to develop my wrapper code further, I need the debug mode.

I have tried to figure out how to configure VS not to try to debug this external DLL by trying different settings at the "Just My Code" section of the debugger settings. None seemed to have improved the situation.

I also tried to specify excluded modules an the Debugger Settings \ Symbols section, but this did not bring any change either.

I was looking for something like an in-line "instruction" to instruct the compiler to "let alone" the DLL an its method when the execution reaches a point where the external DLL's methods are executed. Well, I know, I know, this approach is probably strange to some people who are much more skilled than me, I come from an electrical engineering background and just learned programming to a limited degree along the way.

Did someone face the same situation? Was there a solution for this? What am I missing?

Big thanks for any related ideas!

  • maybe this is helpful : https://learn.microsoft.com/en-us/visualstudio/debugger/specify-symbol-dot-pdb-and-source-files-in-the-visual-studio-debugger?view=vs-2022 – Amjad S. Jan 28 '22 at 10:29
  • Alternatively, maybe the dll provider has set something up along these lines? https://stackoverflow.com/questions/65614165/how-not-to-debug-a-referenced-dll?rq=1 – Andrew Corrigan Jan 28 '22 at 10:35
  • Thank you for the tips! Andrew's suggested topic comes quite close to what I wish to achieve. Reading it now I get the feeling what the developer did to the external DLL that I need to use in order to produce the behavior that I see. – Balazs Bornyasz Jan 28 '22 at 10:42
  • Amjad's suggested topic contains explanations on how to use pdb files (among other topics). However, I do not have the PDB file for the external DLL which I need to use, and if I force VS to generate PDBs with the option "/debug:pdbonly", it only generated one for my own wrapper DLL, and of course nothing is generated for the referenced external DLL. – Balazs Bornyasz Jan 28 '22 at 10:48

0 Answers0