Why won't my program terminate?

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

Just a hunch - make sure CoUninitialize() is called before exit? Also, instead of breaking into a debugger create a crash dump and debug that. Not sure how this works on CE, but that's what'd I'd recommend on Windows.

Answer 2

If an app doesn't exit that usually means that there's one handle still open which can't be closed from userspace. And that means there's a buggy driver.

See this post about details.

Answer 3

look like you have some threads still running in your application.

Make sure you have terminate every child thread before exiting the main one.

Answer 4

Your COM object is creating a thread in the background and that thread is not terminating. It's likely that this is because the COM object is not getting released in your code.

Try calling Marshal.ReleaseComObject before exiting, so your simple test app would look like this:

static void Main() 
{ 
    // create the COM object
    var obj = new FastNavLib.MapControl(); 

    // simulate doing stuff
    Thread.Sleep(1000);

    // release the COM object
    Marshal.ReleaseComObject(obj);
} 

Answer 5

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.