遇到了。net Compact Framework 3.5应用程序的随机本地异常问题，并且对ES400有相同的崩溃转储，但解决方案相当模糊，我需要澄清关于解决方案的细节和2013年1月15日发布的摩托罗拉ES400设备上最新固件更新的效果。
总结一下这个问题，在摩托罗拉ES400上运行的一个紧凑的框架3.5应用程序偶尔会抛出访问违规，到目前为止，这是不可重建的。我可以发布崩溃转储，这是相当轻的有用信息，是相同的那些发现反对原来的问题，其答案似乎是与系统状态信息监控和ui更新，但相当不具体。
我的问题是，什么系统状态信息/控制操作与这个已知问题相关?如果安装2013年1月15日的最新固件版本，解决方案会有什么不同吗?
对任何对这个问题感到不安的人表示歉意，但我不能对原始问题发表评论，因为我是堆栈溢出的新手。
虽然您可以用try..catch块包装所有有问题的调用，但这会消耗资源和性能。避免例外总是更好的。例如:你需要调用一个webservice:你可以在webservice调用周围放一个try/catch，但你也可以确保之前，如果webservice托管服务器是可访问的
作为第一次尝试，您可以只在try (Exception ex) ..catch中包装program.cs中的主窗体调用。未处理的异常将以树状的方式处理，并从上到下冒泡，直到它们被处理(抱歉我的英语)。使用你可以从异常类中获得的所有信息:Message, StackTrace,InnerException等…可以将这些信息写入文件，以便稍后查看。
某些本机异常无法捕获。我已经看到这样与条形码阅读器对象或其他特定于设备的。net包装器对象相结合。对这些坏对象的唯一修复可以由包装器的程序员和他们使用的本机代码/DLL来完成。例如:itcscan.dll是访问条码阅读器的C DLL, dataccollection .cf2.DLL是itcscan.dll的。net包装器。如果itcscan.dll中存在本机异常，可能会导致. net包装器DLL和应用程序崩溃。你自己解决不了的。你必须要求供应商提供一个新的本机和。net DLL。
如何找到本地异常的来源?
浏览你的代码，考虑禁用一个或另一个调用和测试。有一个好的日志文件，所有的函数调用和结果都被记录下来。您可能会在日志中找到引发本机异常的模式。重新思考如何实现一个功能。正如你所提到的，作者将他的代码从事件驱动的图标状态更新更改为周期性的基于时间的检查。