Windows Mobile 6.5 Crash Reporting and Diagnostics

Windows Mobile 6.5 relied on a lightweight mobile version of Windows Error Reporting (WER), derived from the Windows CE Dr. Watson framework, to capture crash dumps and log diagnostic data. When a fatal application crash or system exception occurred, the operating system generated a minidump file and prompted the user to upload the report to Microsoft over an active internet connection. In addition to consumer-facing crash reporting, developers and enterprise administrators used the Windows CE Event Log (CELog), registry-based diagnostic flags, and device management suites to extract system performance metrics and troubleshoot failures.

The Windows Error Reporting (WER) Architecture

At the core of crash handling in Windows Mobile 6.5 was the Watson error-reporting client. Built directly into the Windows CE 5.2 kernel structure that powered Windows Mobile 6.5, this module monitored process executions and intercepted unhandled software exceptions.

When a process crashed:

  1. Exception Interception: The operating system halted the failing thread before termination.
  2. Dump File Creation: Dr. Watson generated a crash dump file (typically with a .kdmp extension) and stored it in the device's internal storage, usually in the \Windows\DumpFiles directory. Depending on system settings, these dumps ranged from minimal context captures to detailed memory states containing call stacks, loaded modules, and CPU registers.
  3. User Prompting: A notification appeared asking the user if they wanted to send the report to Microsoft. Users could choose to send immediately, dismiss the alert, or defer sending until the device established a data connection.
  4. Data Transmission: If approved, the report was compressed and uploaded over cellular data, Wi-Fi, or desktop pass-through via ActiveSync / Windows Mobile Device Center.

Registry-Based Configuration

OEMs, carriers, and administrators managed diagnostic capture behavior using the Windows Mobile registry. Under the HKLM\System\ErrorReporting key, specific values altered logging behaviors:

  • Upload Settings: Keys such as Upload and Consent determined whether the operating system prompted the user, sent reports automatically, or disabled crash reporting entirely to preserve battery and cellular data limits.
  • Dump Depth: The DumpFilter key determined the size and scope of crash logs, allowing developers to switch between basic exception data and full process memory captures.
  • Storage Allocation: The MaxDumpFiles and DumpFileQuota keys restricted the number of logs saved on the physical device to prevent low-memory errors on capacity-constrained flash memory.

Developer and Kernel Diagnostics via CELog

For software developers and device manufacturers, standard crash dumps were often insufficient for diagnosing real-time driver or thread issues. Windows Mobile 6.5 included CELog (Windows CE Event Logger), an event-tracing mechanism embedded in the kernel:

  • Event Interception: CELog recorded low-level kernel activities, such as thread switches, memory allocations, interrupts, and loader events.
  • Log Extraction: Data logged by CELog could be viewed using tools like Readlog or exported over a physical USB connection using the Windows Mobile Device Center or Platform Builder.
  • Live Debugging: Developers connected physical devices to Visual Studio via USB cables to receive real-time output from OutputDebugString and active kernel debuggers.

Enterprise and OEM Diagnostic Tools

Because mobile operators and enterprise IT departments frequently disabled public WER reporting to protect sensitive corporate data, enterprise and OEM solutions provided separate diagnostic avenues:

  • System Center Mobile Device Manager (SCMDM) 2008: Enterprise deployments used SCMDM to monitor device health, enforce security policies, and gather inventory data across fleet devices over an encrypted IPSec VPN.
  • OEM Diagnostic Suites: Manufacturers like HTC, Motorola (formerly Symbol), and Samsung built custom, hidden diagnostic applications into their ROMs. Accessible via dialer codes (e.g., *#*#DIAG#*#*) or dedicated hardware tools, these utilities tested component health—such as GPS, radio module logs, and touch calibration—and logged hardware diagnostics locally.