How to debug a fatal error that happens after calling Application.Exit() in .NET CF 3.5 WinForms application for Windows CE 6?

Question

I am porting a .NET CF 1.0 WinForms application (for older versions of Windows CE) to .NET CF 3.5 (for Windows CE 6). The problem is that, a few seconds after Application.Exit() is called, I get a flash of a "fatal error" message box, which simply says something to the effect of "A fatal error has occurred and the application will terminate.". Since I'm using a Chinese version of Windows CE, the message is in Chinese and I'm not sure what the exact message is in English. Anyway, the error message then automatically disappears and the application fails to terminate and release resources completely, such that the whole operating system becomes unusable (launching any application would result in the perpetual hourglass animation, docking the device in its cradle also does not cause ActiveSync to connect) until I warm boot the device.

This fatal error apparently never occurred in its original form (.NET CF 1.0) on the older device.

And because it's not a .NET exception, it is not caught by the .NET runtime.

What can I do?

Answer 1

Because you can not catch the exception which is happening at Application.Exit(), this sounds like you are facing a bug I've seen before. Please try to comment out all the lines where you set the Font attribute. If the application exists without the error message, you are facing a bug which affects NetCF 3.5 at WinCE 6.0 only. See this link for more information.

Answer 2

I've came across this issue recently and the issue was the forms weren't being disposed. So what I had to do was on every form load I added the form instance to a global list that contained all opened forms and upon the application exit I loop through the list and did a form.dispose on each. That solved my problem instantly.

Answer 3

Sounds like a Dispose or Finalizer has a problem that's showing up when the GC is cleaning house. Check all app finalizers and all Dispose overrides. If that fails to find it, look at any worker thread shutdowns (things sitting in blocking calls, reading handles that might be invalidated, etc).