Cannot debug application in release mode even with DebugType=full

Question

We are building a solution for Release, but when attempting to attach using studio 2010 professional, no thread is showing any stack information, nor any breakpoint can be set, etc.

The goal is to be able to attach the Visual Studio/JIT Debugger to the running process while having as many optimization benefits as possible.

Most of our searches comes down to 'compile with debug:full' and you will be able to debug, but that doesn't seem to be the case, I thing that the JIT optimizes the code in runtime and thus we cannot debug, is this true? Is it possible to compile and tell the JIT to downplay the optimizations and allow debugging? (while retaining other optimizations)

UPDATE

using @HansPassant's answer, I looked at the modules and saw that although the pdbs are in the same directory as the binaries, indeed no debug symbols were loaded. what I also saw is that the my libraries are marked as 'User Code'-'NO' which is probably the reason it was not loaded automatically. By loading symbols manually AND disabling 'just-my-code' I was also able to set breakpoints and see stacks.

Question now: why is my code not marked as User Code? is this normal behavior? can I configure this to my assemblies in some way to avoid this?

Answer 1

Debugging optimized code is no great pleasure. You certainly may have trouble setting breakpoints, a method may have been inlined. And inspecting local variables and method arguments is liable to make the debugger sulky when the variable was optimized to be stored in a cpu register.

You however certainly can still inspect call stacks, you'll see the methods that didn't get inlined in the stack trace. Basic mistakes you might make:

• when you attach a debugger, you get the option to select the debugger type. Be sure to select "Managed", you will not have much use for the native debugger
• be sure that you are looking at the correct thread, the program can be broken at an arbitrary location. Use Debug + Windows + Threads to select the appropriate thread
• be sure that you are actually broken at a location in your code. You can easily end up inside a Windows operating system DLL or a framework method, there will be very little to look at when that's the case. Tools + Options, Debugging, Symbols and enable the symbol server so that stack traces that start inside Windows will be accurate
• the debugger must be able to locate the PDB files. Use Debug + Windows + Modules, you'll see the assemblies loaded in the process. First make sure that the one you want to debug is actually loaded. Right-click it and select "Symbol load information". It shows you where it looked for the PDB file
• the "just my code" option can get in the way heavily, you are very likely to run into significant chunks of code that are not yours. Tools + Options, Debugging, General and turn that option off.

Answer 2

Thought I'd follow up with an additional answer regarding your updated question to help others.

From Microsoft:

To distinguish user code from non-user code, Just My Code looks at symbol (.pdb) files and program optimizations. The debugger considers code to be non-user code when the binary is optimized or when the .pdb file is not available.