Post-mortem analysis of Windows Embedded Compact (Windows CE) program

Question

We have an unmanaged C++ application (MFC framework, Windows CE) that closes on us at seemingly random moments.

There is no error message and no C++ exception, it just vanishes.

I presume something bad must have happened and the C run-time or OS decided to kill the program. But I'm not sure where to continue searching.

Question: is it possible to see somewhere in Windows CE why the application terminated in the first place?

Does Windows CE collect basic crash information? Perhaps then one can at least see if it was an Access Violation, an Out of Memory situation, kernel/driver panic or perhaps some other kind of internal or external event that forced the application to close?

On a regular x86 PC one would break out the debugger, application verifier, Windows Error Reporting tools, WinDbg etc. But how to (start) analyze a Windows CE application crash?

What I've tried so far:

• Creating global C++ exception handlers at tactical locations in the application. These build and transmit a simple UDP packet containing minimal exception info. these are then viewed on another machine running Wireshark.
• Adding the SEH exception compiler switch (/EHa), to be able to catch even those non C++ exceptions, like Access Violation and such.
• Connecting the Visual Studio 2008 debugger via TCP/IP with the Smart Device (connects to smart device successfully MSVS says, but debugger doesn't see any remote processes. The Attach to process VS window gives the following error: Unable to Connect to ''.)
• Retarget the application so it runs on a regular x86 PC (but then it runs fine, so no "luxury" of debugging the issue there either)

I've tested the exception handler by forcing an Access Violation. The expected UDP message the arrives at the machine running Wireshark perfectly. But when the real issue occurs, it stays completely silent.

The platform: MS Windows Embedded Compact 7.02 running on a Texas Instruments processor (ARM A8).

The application itself implements a rudimentary VNC viewer. It uses sockets and relies on a third party binary called zlib CE (ZLIBCE.DLL) for decompressing VNC data.

It hasn't been verified if the zlib binary has been built against the exact same compiler (and/or compiler settings).

Answer 1

Settled for a poor man's debugging solution. Now sending application state values to a memory mapped file. The idea is that a specially crafted helper program runs along the main application. This program opens the memory mapped file, displays values it reads from it. And the main program writes to it. If anything fatal happens to the main app, the helper program has the latest state info. Since it is shared memory it doesn't impact performance much. This way found the section of the program where the fault occurs.