捕获仅在 Release 上发生的 .NET 错误，不会引发异常
我目前正在目睹一个错误，该错误仅发生在我的 exe 的“发布”模式下。
因此，我没有附加调试器，并且应用程序仅显示“...已停止工作。”。
我最初的反应是捕获主循环中的所有异常并显示其消息，但结果没有抛出任何异常，程序只是崩溃了。 （我的程序是单线程的）。
这可能与我集成非托管代码有关，但即使如此，为什么在发布模式下会有所不同？有什么办法让我捕捉到这个异常吗？
我怀疑这是在调试器中运行时出现“无法显示堆栈跟踪/查找代码”的错误之一（并且实际上不会引发异常），但老实说我无法测试它。建议是吗？
I currently am witnessing an error that only happens on "Release" mode of my exe.
Therefore, I have no debugger attached, and the application only goes "... has stopped working.".
My initial reflex was to catch any and all exception in my main loop and display its message, but turns out none is thrown, the program just crashes. (My program is single threaded).
This might be related to the fact that I integrate unmanaged code, but even then, why would it be different on release mode? Is there any way for me to catch that exception?
I suspect it to be one of those errors that go "Cannot show stack trace/find code" when run in the debugger, (and don't actually throw an exception), but I honestly can't test it. Suggestions SO?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
即使它在发布模式下运行，您仍然可以将调试器附加到它。您可以尝试类似的操作...
然后看看会发生什么。如果它停止发生并在调试器下工作，即使在发布模式下运行，那么您就有一个 Heisenbug（基本上意味着很难找到这个错误）。
但是，如果发生这种情况并且 Visual Studio 调试器在问题发生时中断，则查看“线程”窗口（我认为是 Ctrl+Alt+H）。尽管您的应用程序仅使用一个线程，但您运行的本机代码可能会启动其自己的非托管线程。如果是这种情况，您也许可以找到一种方法让它停止这样做，因为不幸的是，没有办法在托管代码中捕获该异常。
You can still attach a debugger to it even if it’s running in Release mode. You could try something like...
Then see what happens. If it stops happening and works under the debugger even when running in Release mode, then you have a Heisenbug (basically meaning it will be very difficult to find this bug).
If, however, it happens and the Visual Studio debugger breaks when the problem happens, then look at the Threads window (Ctrl+Alt+H, I think). It is possible that, although your application uses only one thread, the native code you ran could start unmanaged threads of its own. If that is the case, you might be able to find a way to get it to stop doing that, as unfortunately there is no way to catch that exception in your managed code.
Release 和 Debug 之间的内存布局会有所不同。堆栈的布局也可能不同。如果您有一段有缺陷的非托管代码，浪费了内存，那么它将产生随机影响。
The layout of memory will be different between Release and Debug. Also the layout of the stack may be different. If you have a buggy piece of unmanaged code trashing memory, then it's going to have random effects.
这可能是因为您在某些地方使用了 try catch 块，
请尝试执行以下步骤
1- 转到 Visual Studio IDE
2- 选择“调试”选项
3- 单击“异常”
4- 检查以下的“抛出”选项
“公共语言运行时异常”和本机 Win 32 异常
5 - 首先在调试模式下运行代码。
6-检查您是否遇到异常。
这可能会解决您的问题，至少您会在调试模式下遇到异常。
That may be due to the fact you are using try catch block some where
Try below steps
1- Go to Visual Studio IDE
2- Select Debug options
3- Click on Exceptions
4- Check Throw option for following
'Common Language RunTime Exception' and Native Win 32 Exceptions
5- Run your code in DEBUG mode first.
6- Check you are getting exceptions or not.
this may solve your problem atleast you will get the exception in DEBUG mode.
这里两分钱：
我最近在 winforms 应用程序中遇到了一个问题，我会收到异常“对象引用未设置到对象的实例”。这只发生在发布模式下，而不是调试模式下。
我能够以有限的调试方式运行该程序，并且可以看到所有变量。他们都没有任何问题。
无论如何，我实际上只是将 Visual Studio 从版本 15.7.1 升级到 15.7.3，问题就消失了。
Two cents here:
I ran into an issue in a winforms application recently where I would receive the exception "object reference not set to an instance of an object". This only occurred in release mode and not debug mode.
I was able to run the program as release with limited debugging and could see all the variables. None of them had any issues.
Anyway, I literally just upgraded visual studio from version 15.7.1 to 15.7.3 and the problem went away.
您仍然可以从 VS 逐步调试发布版本；首先尝试一下。
如果托管代码和非托管代码的混合由于某种原因而变得棘手，您可以尝试使用带有 SOS 和 SOSEX 扩展的 WinDbg。请参阅我的答案此处了解所需的基本步骤 - 并检查您是否已完成也为发布版本生成 PDB 符号。
You can still step debug a Release build from VS; try that first.
If the mixing of managed and unmanaged code makes it tricky for some reason, you could try using WinDbg with the SOS and SOSEX extensions. See my answer here for the basic steps required - and check you are generating PDB symbols for Release builds too.
我认为最好首先单独测试非托管代码。
如果成功，则问题可能是非托管代码与托管代码的集成或托管代码本身的集成。
I think it's better to test the unmanaged code in isolation first.
If this is successful, then the problem maybe the integration of the unmanaged code to managed code or in the managed code itself.