Post-Windows Embedded Compact (Windows CE) 程序的剖析
Post-mortem analysis of Windows Embedded Compact (Windows CE) program
我们有一个非托管的 C++ 应用程序（MFC 框架，Windows CE）在看似随机的时刻关闭我们。
没有错误消息，也没有 C++ 异常，它就消失了。
我猜一定是发生了什么不好的事情，C 运行-time 或 OS 决定终止程序。但我不确定在哪里继续搜索。
问题：是否可以在 Windows CE 中的某处看到 为什么 应用程序首先终止？
Windows CE 是否收集基本的崩溃信息？也许这样至少可以看出是访问冲突、内存不足情况、kernel/driver 恐慌还是某种其他类型的内部或外部事件迫使应用程序关闭？
在普通的 x86 PC 上，人们会使用调试器、应用程序验证器、Windows 错误报告工具、WinDbg 等。但是如何（开始）分析 Windows CE 应用程序崩溃？
到目前为止我尝试过的：
- 在应用程序的战术位置创建全局 C++ 异常处理程序。这些构建并传输包含最少异常信息的简单 UDP 数据包。然后在另一台机器上查看这些 运行ning Wireshark。
- 添加 SEH 异常编译器开关 (
/EHa)，甚至能够捕获那些非 C++ 异常，如访问冲突等。
- 正在通过 TCP/IP 连接 Visual Studio 2008 调试器与智能设备（成功连接到智能设备 MSVS 说，但调试器没有看到任何远程进程。
Attach to process VS window 给出以下错误：Unable to Connect to ''.)
- 重新定位应用程序，使其 运行 在常规 x86 PC 上运行（但随后它 运行 没问题，所以也没有 "luxury" 调试问题）
我已经通过强制访问冲突测试了异常处理程序。
预期的 UDP 消息完美地到达机器 运行ning Wireshark。但是当真正的问题发生时，它完全保持沉默。
平台：MS Windows Embedded Compact 7.02 运行ning 在 Texas Instruments 处理器 (ARM A8) 上。
应用程序本身实现了一个基本的 VNC 查看器。它使用套接字并依赖名为 zlib CE (ZLIBCE.DLL) 的第三方二进制文件来解压缩 VNC 数据。
尚未验证 zlib 二进制文件是否针对完全相同的编译器（and/or 编译器设置）构建。
解决了穷人的调试解决方案。现在将应用程序状态值发送到内存映射文件。这个想法是一个特制的帮助程序与主应用程序一起运行。该程序打开内存映射文件，显示从中读取的值。主程序写入它。如果主应用程序发生任何致命事故，辅助程序会获得最新的状态信息。由于它是共享内存，因此不会对性能产生太大影响。这样就找到了出错的程序段
我们有一个非托管的 C++ 应用程序（MFC 框架，Windows CE）在看似随机的时刻关闭我们。
没有错误消息，也没有 C++ 异常，它就消失了。
我猜一定是发生了什么不好的事情，C 运行-time 或 OS 决定终止程序。但我不确定在哪里继续搜索。
问题：是否可以在 Windows CE 中的某处看到 为什么 应用程序首先终止？
Windows CE 是否收集基本的崩溃信息？也许这样至少可以看出是访问冲突、内存不足情况、kernel/driver 恐慌还是某种其他类型的内部或外部事件迫使应用程序关闭？
在普通的 x86 PC 上，人们会使用调试器、应用程序验证器、Windows 错误报告工具、WinDbg 等。但是如何（开始）分析 Windows CE 应用程序崩溃？
到目前为止我尝试过的：
- 在应用程序的战术位置创建全局 C++ 异常处理程序。这些构建并传输包含最少异常信息的简单 UDP 数据包。然后在另一台机器上查看这些 运行ning Wireshark。
- 添加 SEH 异常编译器开关 (
/EHa)，甚至能够捕获那些非 C++ 异常，如访问冲突等。 - 正在通过 TCP/IP 连接 Visual Studio 2008 调试器与智能设备（成功连接到智能设备 MSVS 说，但调试器没有看到任何远程进程。
Attach to processVS window 给出以下错误：Unable to Connect to ''.) - 重新定位应用程序，使其 运行 在常规 x86 PC 上运行（但随后它 运行 没问题，所以也没有 "luxury" 调试问题）
我已经通过强制访问冲突测试了异常处理程序。 预期的 UDP 消息完美地到达机器 运行ning Wireshark。但是当真正的问题发生时，它完全保持沉默。
平台：MS Windows Embedded Compact 7.02 运行ning 在 Texas Instruments 处理器 (ARM A8) 上。
应用程序本身实现了一个基本的 VNC 查看器。它使用套接字并依赖名为 zlib CE (ZLIBCE.DLL) 的第三方二进制文件来解压缩 VNC 数据。
尚未验证 zlib 二进制文件是否针对完全相同的编译器（and/or 编译器设置）构建。
解决了穷人的调试解决方案。现在将应用程序状态值发送到内存映射文件。这个想法是一个特制的帮助程序与主应用程序一起运行。该程序打开内存映射文件，显示从中读取的值。主程序写入它。如果主应用程序发生任何致命事故，辅助程序会获得最新的状态信息。由于它是共享内存，因此不会对性能产生太大影响。这样就找到了出错的程序段