Question

I have a .NET Compact Framework app that can runs on three windows machines (Desktop windows and two WinCE machines) and on the WinCE devices, the process never terminates on exit, even if I call Application.Exit(). Besides .NET, it uses one COM component (which does everything on the UI thread). If I break into the debugger after exitting, Visual Studio shows only one thread and a completely blank call stack.

What could possibly cause this?

Update: My process is terminating on the desktop but not the WinCE machines. I tried to force the process to terminate with the following code, but it doesn’t work:

[DllImport("coredll.dll")]
static extern int TerminateProcess(IntPtr hProcess, uint uExitCode);

static public void ExitProcess()
{
    if (Platform.IsWindowsCE)
        TerminateProcess(new IntPtr(-1), 0);
    Application.Exit();
}

There are also supposed to be ExitProcess() and GetCurrentProcess() APIs like the following, but if I try to call them, I get EntryPointNotFoundException. Therefore I am using TerminateProcess(-1, 0) because the documentation for the desktop version of GetCurrentProcess claims that it simply returns -1.

[DllImport("coredll.dll")]
static extern int ExitProcess(IntPtr hProcess);
[DllImport("coredll.dll")]
static extern IntPtr GetCurrentProcess();

Even throwing an unhandled exception won’t do it.

Update 2: the simplest program that causes the problem merely creates the COM object.

static void Main()
{
    new FastNavLib.MapControl();
}

C++ programs that use the COM component do not exhibit this behavior, so my C++ COM component must have some bizarre interaction with the .NET framework which I will investigate.

Answer 1

I sort-of figured it out.

My COM object sets itself up to get WM_TIMER messages through a hidden window. Basically:

// Register window class
WNDCLASS wc;
memset(&wc, 0, sizeof(wc));
wc.lpfnWndProc = &WinCeTimerProc;
wc.lpszClassName = _T("FastNavTimerDummyWindow");
// Create window
gTimerWindow = CreateWindow(wc.lpszClassName, wc.lpszClassName, 
    WS_OVERLAPPED, 0, 0, 100, 100, NULL, NULL, GetModuleHandle(NULL), NULL);
gTimerID = SetTimer(gTimerWindow, 88, gTimerIntervalMs, NULL);

(Experts might point out I don’t need a timer window to receive timer messages–the last parameter of SetTimer can be set to a callback function. Indeed, if I use a callback instead of a timer window, the problem disappears! However, I had to use a timer window to work around a strange bug in WinCE in which SetTimer(NULL,...) can cause WM_TIMER messages to received by somebody that calls PeekMessage().)

Now, when the last COM object that uses the timer is destroyed, the timer and timer window are also destroyed:

KillTimer(gTimerWindow, gTimerID);
DestroyWindow(gTimerWindow);

Unfortunately, DestroyWindow() never returns. I assume there is some kind of deadlock in DestroyWindow, though it is not clear why the call stack is blank when I pause in Visual Studio. Perhaps because the COM object is destroyed automatically instead of by Marshal.ReleaseComObject(), it is destroyed in the finalizer thread, and DestroyWindow cannot be called from the finalizer thread on WinCE. As usual Microsoft doesn’t spell out the danger in its documentation, stating only “Do not use DestroyWindow in one thread to destroy a window created by a different thread.”

The solution was simple: don’t destroy the timer window at all, as the OS destroys it automatically when the process exits.

Fun fact: the problem with DestroyWindow does not occur if I call SetTimer(NULL,...) instead of SetTimer(gTimerWindow,...), but it does occur if I don’t call SetTimer at all.