Share via

Troubleshooting Crashes on Windows Mobile

  • Article

Crashes happen when the application closes unexpectedly. On Desktops you can leverage on many tools, starting with ADPlus + WinDbg. But this is not the case for us "tiny" programmers… some hints:

1. Start by reading "How the Windows Mobile 5.0 Shell Handles Low Memory Situations": note that the OS doesn't send WM_HIBERNATE nor WM_CLOSE to the foreground application: is your application the one with the focus?

2. How many processes are running at the time of the process' exit? If your process requires so much memory, then you should free the virtual memory associated to the DLLs loaded by other processes (which places the DLL Load Point down in the 32MB), by killing undesired processes and if possible by not starting the drivers you don't need (this last thing is not supported for ISVs however there are some known ways over the web to achieve the result, which may be OEM-specific).

3. If the application is managed: in general, the .NET CF CLR does not close applications without an unhandled exception dialog box. If you are seeing your application disappear in low memory conditions, it is more likely either the OS closing the application because of general low memory or because some native code within the application’s process experienced an unhandled exception.

4. It may be that the exception is raised by the application and not caught by anyone. Global Exception Handling is a concept for example discussed by Daniel Moth here.

5. In order to trap whatever interesting information, you may use BugTrap. This is the device-side executable of the "Windows Mobile Developer Power Toy" named "RAPI Debug". It might be useful in some cases because it can trap exceptions that aren’t caught by the application or are (or should be) smoothly handled by the OS. For any exception type problem, BugTrap will capture the exception details without the need for an ActiveSync\WMDC connection. But with such it gets even better since DEBUGMSG and RETAILMSG info will be available on the attached PC screen (or redirect to a file). You can run the application after starting RAPI_Debug on your development PC (it requires an ActiveSync connection with the device), and you can use it more than once, to see if the caught exception, if any, is always the same. If you have problems on running it, it may be that it's because RAPI Security Policy on the device (chosen by the manufacturer) prevents it to run: in such a case, you may simply start bugtrap.exe on the device BEFORE launching your application."

6. If you enable "Error Reporting", in case of a crash a mini-dump will be automatically generated. A .kdmp file is then available and you can for example look at it through the Windows CE Dump Viewer. Unfortunately, when working with RETAIL devices very rarely this approach leads to something interesting, because a RETAIL image by definition has no Debug Symbols and you may simply end up by knowing that the function at address X failed to access parameter at address Y. So this approach is for OEMs or for In-ROM ISVs\IHVs, not really for ISV Application Developers. Also because without control on the platform, you can’t even control how DrWatson creates the dumps for you.

 

Cheers,

~raffaele

Comments