Not all exceptions are created equal

Hopper is designed to monitor the overall health of the device and will only concern itself with exceptions that affect overall system stability. Knowing what exceptions are critical to stability and which are annoying comes from lots of experience and diligent debugging.

Running without debugger, Hopper will not stop at (most) program exceptions – it doesn’t know or care, it just keeps going.

We get this question often because we recommend running Hopper under an active KITL debug session to detect poorly behaving applications found by Hopper. Unfortunately Platform Builder is unable to determine what exceptions are properly handled by the system and those that are not – and lastly those that won’t matter. Hopper will be clicking along and an exception will be raised, stopping PB waiting for user input – sometimes this exception matters, sometimes not.

The hard part is knowing what exceptions should be investigated – if possible – and knowing which ones can safely be continued past. For example, there are several windowing calls that will throw an exception in GWES.exe if the window handle parameter is null or invalid. Sometimes its possible to debug these (sometimes not), but in general are harmless and will not negatively affect system stability. However, there are additional GWES.exe exceptions that will eventually bring down your windowing system, which would eventually be detected by Hopper and the test would be stopped because user interaction has been rendered useless.

It gets more complicated when exceptions are found are in critical components deemed necessary for system stability. For this example, I will focus on the Pocket PC Phone Edition and how it loads the control panel components. If I load the Phone control panel from the signal strength settings indicator, the CPL is actually hosted in CProg.exe and can safely crash without bringing down the system. If however, I load the phone CPL (the same CPL as before) from Start->Settings, this time it the DLL be hosted by Shell32.exe and any exception in this critical module will cause the device to reboot.

So what does all this mean? There is no quick and easy solution to program exceptions on Windows Mobile devices – but the next time you see one, take the time to investigate the severity and make sure you understand the source. Its likely you can safely F5 past the exception and release Hopper to find bigger and better bugs in your platform.