views:

2207

answers:

4

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, what are the required steps/configuration (e.g. where to put the PDB file)?

Edit:

If have the PDB file in the same place as the DLL (in the bin/debug directory of a simple console test application). I can see that the symbols for the DLL are loaded (in the Output window and also in the Modules window), but still I cannot step into the methods of that DLL.

Could this be the result of compiler optimizations (as described by Michael in his answer)?

+3  A: 

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.

Marc Gravell
The PDB is next to the DLL, the symbols are loaded, but I still can't step into the methods. Any idea?
M4N
+2  A: 

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.

Michael
A: 

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.

Stephen Nutt
A: 

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.

M4N