遇到Random native exception from .NET Compact Framework 3.5 application and have a same crash dump for an ES400 这个问题，但解决方案相当模糊，我需要澄清解决方案的细节和最新固件更新对摩托罗拉 ES400 设备的影响于 2013 年 1 月 15 日发布。
总结一下这个问题，一个在摩托罗拉 ES400 上运行的紧凑型框架 3.5 应用程序会以奇数的时间间隔抛出偶尔的且迄今为止无法重新创建的访问冲突。我可以发布故障转储，它对有用信息的了解相当少，并且与针对原始问题发现的相同，其答案似乎与系统状态信息监视和 ui 更新有关，但相当不具体。
我的问题是，什么系统状态信息/控制操作与这个已知问题相关？如果安装了截至 2013 年 1 月 15 日的最新固件版本，是否对解决方案有任何影响？
向对这个作为一个全新问题发布的任何人表示歉意，但我无法评论原始问题，因为我是堆栈溢出的新手。
尽管您可以使用 try..catch 块包装所有有问题的调用，但这会消耗资源和性能。避免异常总是更好的。 例如：您需要调用 Web 服务：您可以在 Web 服务调用周围放置一个 try/catch，但您也可以事先确保 Web 服务托管服务器是否可访问。
作为第一次尝试，您只能将主窗体调用包装在 try (Exception ex) ..catch 中的 program.cs 中。未处理的异常将以树状方式处理，并从上到下冒泡，直到它们被处理（对不起我的英语）。使用您可以从 Exception 类获得的所有信息：Message、StackTrace、InnerException 等... 可能将这些信息写入文件，以便稍后查看。
无法捕获某些本机异常。我已经将其与条形码阅读器对象或其他特定于设备的 .NET 包装器对象结合使用。包装程序的程序员和他们使用的本机代码/DLL 可以对此类坏对象进行唯一的修复。例如：itcscan.dll 是一个用于访问条形码阅读器的 C DLL，DataCollection.cf2.DLL 是这个 itcscan.dll 的 .NET 包装器。如果 itcscan.dll 中存在本机异常，则可能会使 .NET 包装器 DLL 和您的应用程序崩溃。您将无法自己解决此问题。您必须向供应商索取新的本机和/或 .NET DLL。
只需通过您的代码并考虑禁用一个或其他调用和测试。有一个很好的记录到一个文件，所有的函数调用和结果都被记录下来。您可能会在日志中找到引发本机异常的模式。重新思考如何实现一个功能。正如您提到的帖子中一样，作者将他的代码从事件驱动的图标状态更新更改为基于时间的定期检查。