1

We have error handling around our Windows Mobile application similar to the following:

static class Program
{
    /// <summary>
    /// The main entry point for the application.
    /// </summary>
    [MTAThread]
    static void Main()
    {
        try
        {
            AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(OnUnhandledException);
            LogWriter.WriteDebugLog("******* Application Start *******");
            Application.Run(new Form1());
        }
        catch (Exception ex)
        {
            LogWriter.WriteDebugLog("LOG MAIN: " + ex.Message + "\r\nTrace: " + ex.StackTrace);
            MessageBox.Show("An unexpected error has occured, please try again. If the problem continues please contact application provider.", "Fatal Error");
        }
        finally
        {
            AppDomain.CurrentDomain.UnhandledException -= new UnhandledExceptionEventHandler(OnUnhandledException);
            try
            {
                //System.Diagnostics.Process proc = System.Diagnostics.Process.GetCurrentProcess();
                //proc.Kill();
            }
            catch { }
            LogWriter.WriteDebugLog("******* Application Exit *******");
        }
    }

    public static void OnUnhandledException(object sender, UnhandledExceptionEventArgs e)
    {
        string application_name = sender.ToString();
        Exception except = (Exception)e.ExceptionObject;
        string errormessage = "Application " + application_name + " [ Exception " + except.Message + " ]" + Environment.NewLine + except.StackTrace;

        //MessageBox.Show(errormessage, "Fatal Error");
        LogWriter.WriteDebugLog(errormessage);
        AppDomain.CurrentDomain.UnhandledException -= new UnhandledExceptionEventHandler(OnUnhandledException);
    }
}

Despite this error handling methodology, we have received logs from users where the application has simply terminated without recording an exit or an unhandled exception or a LOG MAIN exception.

I have been trying to reproduce this by creating a very simple application and throwing around various types of exception strategy to kill the application, but with no success. Every time I throw any kind of exception it seems to be caught by the code above.

If anyone has any ideas as to what kind of issues might skip this error handling it would be greatly appreciated as this might move our investigations forwards.

Kind regards, Graham.


Edit: Slightly more information in case it is relevant as requested.

The applications in question are a large variety of Windows Mobile 6.5 applications, mostly running on Motorola MC65 devices although some are on Psion EP10 devices and some are on other devices too (so it is unlikely to be device-specific).

The applications all use SQLCe and Merge Replication. Many of them use third-party controls for displaying on forms. All of them use a certain amount of PInvoking for varying purposes.

The crashes themselves do not appear to be happening at any particular point in the application and not very often even then but when we review the logs we see the application logging its progress (including memory usage and various other useful details) and then it simply terminates without any record.

  • Some exceptions can't be trapped this way. Including exceptions raised before Main() starts running, the kind of exception that this web site was named for and exceptions in unmanaged code not started by the CLR. Document what you *know* about these crashes so we don't have to guess or write a book about it. – Hans Passant Sep 12 '13 at 15:11

3 Answers3

1

"Despite this error handling methodology, we have received logs from users where the application has simply terminated without recording an exit or an unhandled exception or a LOG MAIN exception."

There are exceptions that are not handled by any .NET excption handler: for example native code referenced by your app function useage may crash.

Possibly you have a more simple problem: if the device resources geting low it sends a hibernate message (http://msdn.microsoft.com/en-us/library/aa925791.aspx) to all windows. If a process does not release resources and respond to this request, it may be just killed by the OS, if the resources remain low after the broadcast.

I already had some support calls about this (I am doing WM/PPC support for 9 years now) and they were fixed by lowering the resource usage on the devices and by implementing a WM_HIBERNATE handler.

josef
  • 5,951
  • 1
  • 13
  • 24
  • There is a distinct possibility that the error is being thrown in native code. Unfortunately the nature of the issue leaves me unable to confirm or deny this since it can happen pretty much at any point in the application's life-cycle. I was hoping to find a way of catching such issues so that I can at least see what had thrown the error in the first place – user2773054 Sep 13 '13 at 09:19
  • if you use p/invoke then log every call to these p/invoke functions. The issue may also be caused by a standard lib, so enable error reporting or dumps: http://blogs.msdn.com/b/hopperx/archive/2005/10/07/getting-help-from-the-doctor-dr-watson-that-is.aspx. You should also log memory and resource conditions periodically to verify that there is no reason that the app is being killed by the OS (or implement a wm_hibernate handler). – josef Sep 13 '13 at 16:47
  • +1 for josef. Do you have a simple managed code snippet to show how to listen for `WM_HIBERNATE` messages? I've never found a good way to implement this in `WinMobile` ...I'd *like* to, though. –  Sep 20 '13 at 12:44
0

You also need to catch unhandled Thread exceptions in a similar manner:

static void Main()
{
    Application.EnableVisualStyles();
    Application.SetCompatibleTextRenderingDefault(false);

    Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);


    Application.ThreadException += new ThreadExceptionEventHandler(Application_ThreadException);
    AppDomain.CurrentDomain.UnhandledException += new UnhandledExceptionEventHandler(CurrentDomain_UnhandledException);

    Application.Run(new Form1());
}

Ref.: Application.ThreadException

Mitch Wheat
  • 295,962
  • 43
  • 465
  • 541
  • They are already handled by default, that doesn't produce a log entry. – Hans Passant Sep 12 '13 at 15:09
  • 1
    Winforms simply already provides a default handler for Application.ThreadException. It displays the ThreadExceptionDialog. Most relevant to the question is that .NET CF doesn't have the event at all. – Hans Passant Sep 12 '13 at 15:12
  • sure, but it won't log anything in the posters log file. Good point about the un-catchable exceptions. http://stackoverflow.com/questions/2014562/whats-the-difference-between-application-threadexception-and-appdomain-currentd – Mitch Wheat Sep 12 '13 at 15:14
  • I am fairly sure that the unhandled thread exceptions are already being caught by the event handlers in place, but I will certainly try adding the extra event handler to see if it provides any feedback. The difficulty is in the rarity of the event so it may take some time to get any results from the full application – user2773054 Sep 13 '13 at 09:15
0

@Mitch Wheat I believe we are talking here about Windows Mobile 6 which uses .NET CF 3.5 .NET CF does not support ThreadException, so you can not do that.

d.b
  • 95
  • 2
  • 9