Debugging a release version of a DLL (with PDB file)

后端 未结 4 1746
余生分开走
余生分开走 2020-12-24 07:21

If I have a DLL (that was built in release-mode) and the corresponding PDB file, is it possible to debug (step-into) classes/methods contained in that DLL?

If so, wh

相关标签:
4条回答
  • 2020-12-24 07:49

    The pdb is usually (for me at least) detected if it is next to the dll (like with the intellisense xml files).

    Alternatively; you'll need a break point after the module has loaded...

    At the break-point, bring up the "Modules" window (Ctrl+D,M - or Debug->Windows->Modules). Right click on your dll "Load symbols from", "Symbol path", etc.

    0 讨论(0)
  • 2020-12-24 08:00

    I finally found what cause the problems debugging a DLL that was built in release configuration:

    First of all, it basically works as expected. Which means, if I have a DLL built in release-configuration plus the corresponding PDB file, then I can debug the classes/methods contained in that DLL.

    When I first tried this, I unfortunately tried to step into methods of a class which has the DebuggerStepThroughAttribute, e.g:

    [System.Diagnostics.DebuggerStepThrough]
    public class MyClass {
        public void Test() { ... }
    }
    

    In that case, it is of course not possible to step into the method from the debugger (as expected/intended).

    So everything works as intended. Thanks a lot for your answers.

    0 讨论(0)
  • 2020-12-24 08:11

    Yes, you can debug release code with a PDB. There are some pitfalls however with debugging optimized code, more info here and here.

    Your PDB just needs to be in a place that the debugger can find it - for local debugging same directory as the dll is usually easiest. Otherwise, put it in some place that the debugger can find it, and point the debugger to that place with the symbol path.

    0 讨论(0)
  • 2020-12-24 08:14

    Debugging a release build is typically much harder that debugging a debug version. In general you'll need some understanding of x86 assembler and you'll likely spend some time looking at the disassembly window. This tends to be the only way to figure out what line of code you are really on since in a release build with optimizations on the compiler may do significant inlining and instruction reordering. In addition I find the debugger frequently fails to correctly report values of variables. If you need to know a variable's value and you are not sure the debugger is correct, go into the disassembly window and find the memory location or register it is located in.

    The pdb files can be stored in a Symbol Server. Check out Setting up a Symbol Server for a good tutorial. Every product we build on a build machine publishes the symbols to our symbol server, so we can always debug any crash dumps we receive from WinQual.

    0 讨论(0)
提交回复
热议问题