VisualStudio / C #: debugging an imported DLL

I have a project that imports a DLL (written by me). Sometimes, when an exception occurs inside a method in a DLL, the host project opens a tab and allows me to see the code in the DLL. I can also set breakpoints in it.

But this behavior seems rather random, I cannot have it on purpose and does not always work. In addition, I do not see the file name in the project explorer window.

Any help on debugging a dll? Thanks

+4
source share
6 answers

Extended debugging (for dlls not in the current solution) depends a lot on whether you have a debugging symbol file (.pdb) in an obvious place - in particular, next to the dll itself. You can also load symbols manually from the modules window (during debugging, Debug β†’ Windows β†’ Module, right-click, Load Symbols From ...)

+12
source

What could be in your way here is a feature known as Just My Code (JMC). This is a debugger / CLR function, designed to limit the way users view the world only on the code they wrote. Various ways, whether a piece of code or a DLL is defined as yours or not, can sometimes be misleading.

The next time you encounter this problem, try disabling JMC and see if it fixes your problem.

  • Go to: Tools β†’ Options
  • Move: Debugger -> General
  • Uncheck "Only my code"
+2
source

In a C # managed program that calls C ++ dll, right-click properties debug tab Check Enable unmanaged code debugging

Hope this helps, Tony.

+2
source

To debug a DLL, it must have a pdb file with debug information corresponding to that DLL.

+1
source

Visual studio uses the .Pdb characters generated by the compilation process to allow the developer to peer into the source when an exception occurs.

This information exists for two reasons. The first reason is the compiler (i.e., the program that turns the source code into an application, such as a .exe or .dll file) to use when creating the application. The second reason is what people can use when debugging an application. Character information is generated as part of compiling the application (if you installed a compiler to generate symbolic information). This information may be located directly in the application files or may be recorded in separate symbol files. If the characters are found depends on your development application and the settings you choose. For example, Microsoft Visual Basic (VB) builds characters directly into program files. Visual C ++ (VC ++) usually creates one or two separate files.

Character files have two types of files: .dbg and .pdb. The .dbg files are in the common object file format (COFF), which is a description of the description of a common character that does not include information about the source string; many debuggers can read these files. .Pdb files are a Microsoft format and contain much more information than .dbg files. For example, source string information is only available in .pdb characters. Character files that contain source code information allow you to use the source code for debugging.

+1
source

While it does not allow you to debug code, Reflector is very useful when it comes to checking the DLL. The combination of Stack Trace, a malicious DLL and a reflector will often make you think about a problem.

+1
source

Source: https://habr.com/ru/post/1286002/


All Articles