即使使用DebugType = full，也无法在发布模式下调试应用程序 [英] Cannot debug application in release mode even with DebugType=full

问题描述

我们正在构建发布解决方案，但是当尝试使用Studio 2010 Professional连接时，没有线程显示任何堆栈信息，也无法设置任何断点，等等。

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.

目标是能够将Visual Studio / JIT调试器附加到正在运行的进程中，同时具有尽可能多的优化优势。

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.

我们的大多数搜索都来自直到使用debug：full进行编译，您就可以进行调试了，但事实并非如此，我认为JIT在运行时优化了代码，因此我们无法调试，这是真的吗？
是否可以编译并告诉JIT忽略优化并允许调试？ （同时保留其他优化）

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)

更新

使用@HansPassant的答案，我查看模块，发现尽管pdb与二进制文件位于同一目录中，但实际上没有加载调试符号。我还看到我的库被标记为用户代码-否，这可能是未自动加载的原因。
通过手动加载符号并禁用'我的代码'，我还能够设置断点并查看堆栈。

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?

推荐答案

调试优化的代码并不是一件很愉快的事情。您当然可能在设置断点时遇到麻烦，可能已内联了一个方法。当变量被优化以存储在cpu寄存器中时，检查局部变量和方法参数很容易使调试器感到困惑。

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:

• 连接调试器时，可以选择调试器类型。确保选择托管，对于本机调试器来说并没有太多用处。


• 确保您正在寻找正确的线程，该程序可以在任意位置被破坏。使用Debug + Windows + Threads选择适当的线程


• 请确保您实际上在代码中的某个位置被打断了。您可以轻松地将其放入Windows操作系统DLL或框架方法中，在这种情况下，几乎没有什么可看的。工具+选项，调试，符号并启用符号服务器，以便Windows内部启动的堆栈跟踪准确无误


• 调试器必须能够找到PDB文件。使用Debug + Windows + Modules，您将看到过程中加载的程序集。首先确保您要调试的已被实际加载。右键单击它，然后选择符号负载信息。它向您显示在哪里寻找PDB文件


• 仅我的代码选项可能会严重影响您的工作，您很可能会遇到大量非您自己的代码。工具+选项，调试，常规，然后关闭该选项。

• 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.

这篇关于即使使用DebugType = full，也无法在发布模式下调试应用程序的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！