blocks|key|2554397|text|相当多的异常不能被捕获，这些异常在不同的.NET版本和.NET版本中是不同的。一些异常可以被捕获和记录，但不能恢复(内存异常)。然而，调试它们是可能的(它们被称为，第一次机会总是调试器的，第二次机会是代码的，感谢JeroenH指出这一点)。这里有一个post+at+CodeProject+that+explains+this原则。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2554398|您应该做的是在Visual+Studio中选择一些您怀疑可能发生的候选异常，并将调试器附加到正在运行的实例。|2554399|拥有非托管资源(串行端口)意味着您可能会有非托管泄漏(未正确使用IDisposable+%2B+using+)和非托管异常。这些异常只能在try/catch块中使用空catch+(即，没有指定even+Exception，它不是非托管异常的父级)来捕获。|style|CODE|2554400|PS:当在finally块或finalizer/destructor中引发异常时，可能会发生一些未定义的行为。此外，跨越线程边界传播并终止所有线程的异常也不多。|2554401|编辑|2554402|为了让事情更清楚一些，有一些例外情况是CLR+(及其规范)定义为不可捕获的。基本上，这些都是跨越线程边界的异常。当这些异步异常发生在锁中时，将导致状态损坏。最著名的是OutOfMemoryException、ThreadAbortException和StackOverflowException。当OutOfMemoryException或StackOverflowException出现在同步代码中时，您不太可能纠正状态，CLR将终止您的应用程序。|2554403|此外，还有ExecutionEngineException和BadImageFormatException，它们不应该出现在可验证的代码中，也不应该被捕获。像TypeLoadException和MissingMemberException这样的异常有时可以捕获，有时不能捕获(如果缺少链接的程序集，则很难捕获这些异常，而且您不应该捕获这些异常，但是如果使用反射，则应该捕获这些异常)。|2554404|简而言之:异常应该在它们发生的线程中被捕获。如果异常发生在另一个线程中，您将无法捕获它们，因为它们不会被传播(ThreadAbortException除外)。您的应用程序在发生异常后仍然存活(至少，您认为是这样的)，因此假设异常不会发生在您试图捕获它的线程中是合乎逻辑的。使用Debug+>+Exceptions窗口，您可以选择任何异常，并在发生异常时中断代码。|2554405|关于异常的说明|2554406|添加了有关托管和非托管异常的说明。由于非托管异常不是从Exception继承的，因此无法使用catch+(Exception+e)捕获非托管异常。相反，使用一个空的catch，它将为您捕获任何非托管异常。将其封装在您的应用程序和线程入口点方法中，您应该能够捕获大多数可捕获的异常。|2554407|entityMap|0|LINK|mutability|MUTABLE|url|http://www.codeproject.com/KB/dotnet/UnCaught_Exceptions.aspx^0|3H|12|0|0|0|W|B|1A|5|29|5|2R|9|0|0|0|2B|K|2W|K|3H|M|45|K|4Q|M|0|5|O|U|N|27|H|2P|M|0|1J|K|0|0|R|9|1A|J|0^^$0|@$1|2|3|4|5|6|7|15|8|@]|9|@$A|16|B|17|1|18]]|C|$]]|$1|D|3|E|5|6|7|19|8|@]|9|@]|C|$]]|$1|F|3|G|5|6|7|1A|8|@$A|1B|B|1C|H|I]|$A|1D|B|1E|H|I]|$A|1F|B|1G|H|I]|$A|1H|B|1I|H|I]]|9|@]|C|$]]|$1|J|3|K|5|6|7|1J|8|@]|9|@]|C|$]]|$1|L|3|M|5|6|7|1K|8|@]|9|@]|C|$]]|$1|N|3|O|5|6|7|1L|8|@$A|1M|B|1N|H|I]|$A|1O|B|1P|H|I]|$A|1Q|B|1R|H|I]|$A|1S|B|1T|H|I]|$A|1U|B|1V|H|I]]|9|@]|C|$]]|$1|P|3|Q|5|6|7|1W|8|@$A|1X|B|1Y|H|I]|$A|1Z|B|20|H|I]|$A|21|B|22|H|I]|$A|23|B|24|H|I]]|9|@]|C|$]]|$1|R|3|S|5|6|7|25|8|@$A|26|B|27|H|I]]|9|@]|C|$]]|$1|T|3|U|5|6|7|28|8|@]|9|@]|C|$]]|$1|V|3|W|5|6|7|29|8|@$A|2A|B|2B|H|I]|$A|2C|B|2D|H|I]]|9|@]|C|$]]|$1|X|3|-4|5|6|7|2E|8|@]|9|@]|C|$]]]|Y|$Z|$5|10|11|12|C|$13|14]]]]

Quite some exceptions cannot be caught and which these are differs from .NET version to .NET version. And some exceptions can be caught and logged, but cannot be recovered from (memory exceptions). However, it is possible to debug them (these are called <a href="http://support.microsoft.com/kb/105675?wa=wsignin1.0" rel="noreferrer">first chance exceptions</a>, the first chance is always for the debugger, the second chance is for the code, thanks to JeroenH for pointing this out). Here's a <a href="http://www.codeproject.com/KB/dotnet/UnCaught_Exceptions.aspx" rel="noreferrer">post at CodeProject that explains this</a> principle.

What you should do is select some candidate exceptions in Visual Studio that you suspect might occur, and attach the debugger to the running instance.

Having unmanaged resources as you have (serial port) means you can have unmanaged leaks (not using <code>IDisposable</code> + <code>using</code> properly) and unmanaged exceptions. These exceptions can only be caught with an empty <code>catch</code> (i.e., without specification of even <code>Exception</code>, which is not the parent of unmanaged exceptions) in a try/catch block.

PS: some undefined behavior can occur when exceptions are raised in finally blocks or in finalizers/destructors. Also, not many exceptions propagate across thread boundaries and terminate all threads.

<h2>Edit</h2>

To make things a little clearer, there are a few exceptions that the CLR (and its specification) define as non-catchable. Basically, these are all exceptions that cross thread boundaries. These asynchronous exceptions, when occurring within a lock, will result in state corruption. Best known are <code>OutOfMemoryException</code>, <code>ThreadAbortException</code> and <code>StackOverflowException</code>. When the <code>OutOfMemoryException</code> or <code>StackOverflowException</code> occurs in synchronous code, it's unlikely that you can correct state and the CLR will terminate your application.

In addition there's the <code>ExecutionEngineException</code> and <code>BadImageFormatException</code> which should not happen in verifiable code and should not be caught. Exceptions such as the <code>TypeLoadException</code> and <code>MissingMemberException</code> can sometimes be caught and sometimes not (if a linked assembly is missing, it'll be hard to catch these, and you shouldn't, but if you use reflection, you should catch these).

In short: exceptions should be caught in the thread they happen in. You will not be able to catch exceptions if they happen in another thread, because they are not propagated (with the exception of the <code>ThreadAbortException</code>). Your application stays alive after an exception (at least, you think), so it is logical to assume that the exception doesn't happen in the thread where you're trying to catch it. Using the Debug > Exceptions window, you can select any exception and break on the code when they happen.

<h2>Note on Exception</h2>

An added note on managed and unmanaged exceptions. You cannot catch an unmanaged exception using <code>catch (Exception e)</code>, because the unmanaged exception does not inherit from <code>Exception</code>. Instead, use an empty catch, which will trap any unmanaged exception for you. Wrap this around your application and thread entrypoint methods and you should be able to catch the majority of catchable exceptions.

blocks|key|2554447|text|如果您使用Thread类启动辅助线程，并且没有指定它们是后台线程，那么它们将使您的进程保持运行，直到它们退出，即使主线程已经完成(即。main窗体已关闭，Main方法已返回。)|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2554448|如果你有一个StackOverflowException，你的进程就会被Windows直接杀死，所以这不是它。|2554449|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

If you start secondary threads using the Thread class, and don't specify that they are background threads, they will keep your process running until they exit, even if the main thread has completed (ie. main form closed, and Main method has returned.)

If you had had a StackOverflowException, your process would've been killed by Windows outright, so that isn't it.

blocks|key|793555|text|您可能有一个本机异常或访问冲突(通常表现为第一次机会异常)。任何数量的托管异常处理都无法捕获其中的一个-关键是不要在一开始就导致异常。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|793556|您是否正在调用或进行不安全的调用？如果你正在调用一个API，并导致缓冲区溢出或堆栈损坏之类的事情，你会看到这种行为(尽管你经常会得到一个操作系统对话框抱怨。|793557|追踪这些通常是很困难的。这是一个CE设备-它有调试端口(通常是串行端口)吗？异常很可能会在那里转储一条消息，所以如果您可以访问一个异常，这是一个很好的起点。如果你有KITL，在应用程序运行的同时运行调试中的操作系统也可能会捕获正在发生的事情。|793558|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

You likely have a native exception or an access violation (which will typically manifest as a first-chance exception). No amount of managed exception handling can trap one of these - the key is to not cause the exception in the first place.

Are you p/invoking or making unsafe calls? If you're calling an API and causing something like a buffer overrun or stack corruption you would see this kind of behavior (though often you'll get an OS dialog complaining.

Tracking these down is often tough. This is a CE device - does it have a debug port (it's typically a serial port)? It's very likely that an exception will dump a message there, so if you have access to one, that is a good starting point. If you have KITL, running the OS in debug while the app runs may also trap whatever is happening.

I have a program written in C#, running on a Windows CE device (on Compact Framework). It processes minimal user actions (button clicks), uses serial port and TCP/IP communication.

The problem is sometimes the software shuts down on its own. 
In the background the application (or parts of the application) seems to be still running (at least in one documented case it was) because it uses the serial port, so restarting the application doesn't help. I can't reproduce the problem since it happens in most of the cases when there is no user interaction, no serial port communication and the network communication is all "I am still alive" messages, the software just crashes seemingly without reason. (I try to make it happen in debug mode to know at least where is the problem in the code if it is a software bug but I have had no luck so far.)

Since I'm running out of ideas, the question is: what bug or exception or OS action or hardware malfunction can cause such a behaviour? 

The problem has been seen on different devices of the same type, so it shouldn't be a hardware error. (Or all my hardware has the same error.) Exceptions are handled, so it shouldn't be an exception. Unhandled exceptions are handled too, so it shouldn't be an unhandled exception either. (My guess is that it is caused by a <code>StackoverflowException</code> because I don't know any other exceptions that can't be caught, but there isn't recursion in the code, at least not willingly, so it shouldn't be a possibility either.)

Partly crashing application? How can I catch uncatchable exceptions?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我有一个用C#编写的程序，在Windows CE设备(在Compact Framework上)上运行。它处理最少的用户操作(按钮点击)，使用串行端口和TCP/IP通信。问题是有时软件会自动关闭。在后台，应用程序(或应用程序的一部分)似乎仍在运行(至少在一个文档记录的情况下是这样)，因为它使用串行端口，所以重启应用程序没...

问应用程序部分崩溃？如何捕获无法捕获的异常？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问应用程序部分崩溃？如何捕获无法捕获的异常？EN