我肯定这是以前发生过的事情，有些东西可以在调试模式下工作，我们可以在发行版中进行编译，但是有些东西会中断。

这是在嵌入式XP环境中发生的，我发现做到这一点的最佳方法实际上是写一个日志文件来确定哪里出了问题。

我们尝试解决烦人的发布模式错误的经验/发现是什么？

解决方案

回答

如果仅是应用程序的一小部分需要调试，则可以更改这些源文件，使其仅在不进行优化的情况下进行构建。据推测，我们会为所有构建生成调试信息，因此这使应用程序几乎可以像发布时那样运行，但可以让我们正确调试有趣的部分。

回答

如何使用Trace语句。它们在那里用于发布模式值检查。

Trace.WriteLine(myVar);

回答

确保我们具有良好的调试符号(即使在发行版的情况下，甚至在嵌入式设备上也可以执行此操作)。我们应该能够获得堆栈跟踪以及希望的某些变量的值。在这一点上，良好的汇编语言知识可能也很有用。

我的经验是，该错误通常与损坏区域附近的代码有关。也就是说，如果我们发现函数" LoadConfigInfoFromFile"中出现了问题，那么，如果我们了解我的意思，那么可能应该从对问题的详细分析开始，而不是" DrawControlsOnScreen"。 "遥远的怪异动作"类型的虫子不会经常出现(尽管当它们出现时，它们往往是主要的负担)。

回答

我同意调试日志文件以缩小范围。

我一直使用" Entering FunctionName"" Leave FunctionName"，直到我找到崩溃前输入的方法。然后，我添加更多的日志消息，重新编译并重新发布。

回答

如pauldoo所述，除了为Release版本关闭优化和/或者打开调试信息外，日志文件还将为我们提供有用的数据。我曾经写过一个"跟踪"应用程序，如果发布版本开始运行的话，它将捕获该应用程序的跟踪日志(否则，如果在调试器下运行，结果将进入调试器的输出窗口)。我能够让最终用户通过电子邮件向我发送日志文件，重现他们所看到的错误，这是我至少在一种情况下才发现问题的唯一方法。

回答

尽管它可能无法在嵌入式环境中使用，但是我对WinDbg的运气很好，可以调试发行模式的Windows应用程序。即使未使用符号信息编译应用程序，我们也至少可以获得可用的堆栈跟踪和许多其他有用的崩溃信息。

回答

我们也可以将调试符号复制到生产环境中，即使它是在relase模式下编译的也是如此

这是更多信息的文章

回答

如果问题是与同步相关的转储文件中的日志可能有问题。
在这种情况下，我通常会使用一些较大的字符串数组，并在问题重现后将其转储到屏幕/文件中。
当然，这取决于内存限制，如果平台上的内存有限，有时我只使用很少的符号和数字来存储在阵列中。读取此类日志并不是一件大事，但有时这是唯一的选择。

回答

跟踪文件始终是一个好主意。
关于崩溃，我使用的是adplus，它是Windows调试工具的一部分。 adplus的主要作用是将windbg添加到我们正在监视的可执行文件上。当应用程序崩溃时，我们将获得崩溃转储和日志文件。我们可以在首选的调试器中加载故障转储并找出导致崩溃的指令。

与调试版本相比，发行版本经过了重大优化，因此编译代码的方式会影响其行为。当发布版本而不是调试版本中发生多线程代码崩溃时，这基本上是正确的。 adplus和windbg帮助我找出了发生的地方。

ADPlus的解释如下：
httx：//support.microsoft.com/？scid = kb％3Ben-us％3B286350＆x = 15＆y = 12

基本上，我们要做的是：
1.下载WinDbg并将其安装到C：\ debuggers中
httx：//www.microsoft.com/whdc/devtools/debugging/default.mspx

• 开始申请
• 打开一个cmd和cd到c：\ debuggers
• 开始这样的adplus：

" adplus.bat-崩溃your_exe.exe"

• 重现崩溃
• 在vs2005或者windbg中分析崩溃转储