Restoring Backups Across Windows Mobile 6.5 ROMs

Restoring a system image backup across different Windows Mobile 6.5 ROM versions was notoriously problematic due to the operating system's tight integration with hardware drivers, registry structures, and kernel builds. While standard full backups worked reliably on identical ROM builds, flashing a new or custom ROM changed the underlying system architecture. Consequently, attempting a direct, full system restore almost always resulted in fatal system instability or bootloops, forcing users to rely on specialized selective restoration utilities or dedicated ROM-migration tools.

The Problem with 1:1 Image Restores

Windows Mobile 6.5 organized its persistent storage using a combination of flash partitions and memory-mapped files. Backup tools from that era, such as SPB Backup, Sprite Backup, and Resco Backup, offered "full image" backups that captured the entire device state, including the \Windows directory, user databases, and the registry hives (system.hv and user.hv).

When users flashed a new ROM—such as upgrading from a stock manufacturer build to an XDA-Developers custom build like EnergyROM—the underlying Windows Embedded CE kernel, OEM drivers, and device configurations changed. Executing a standard 1:1 restoration caused several critical conflicts:

  • Registry Corruption: The older registry hive would overwrite the new ROM's registry. This replaced newly defined hardware pointers, power management profiles, and radio interface layer (RIL) configurations with outdated entries, leaving the device unable to boot or without functional cellular, Wi-Fi, and Bluetooth radios.
  • XIP and SYS Mismatches: The Execute-in-Place (XIP) core kernel and the system packages (SYS) differed across builds (e.g., 21xxx vs. 23xxx/28xxx series). Restoring system binaries or shortcuts designed for an older interface frequently crashed the Windows Mobile shell (shell32.exe) or the HTC Sense/TouchFLO 3D interface.
  • File Shadowing: Files restored to flash memory would "shadow" (override) identical files stored in the read-only section of the new ROM, effectively breaking newly patched system components.

ROM Upgrade Modes and Selective Restoration

To address these cross-ROM compatibility issues, third-party backup software introduced specific "ROM Upgrade" or "Migration" modes. When restoring across different builds, these utilities modified their restore process:

  1. Filtering the Registry: The backup software bypassed the core system registry (HKLM\Drivers, HKLM\System) and only restored non-conflicting user keys, such as application licensing, personalization settings, and specific software registry entries.
  2. Database Isolation: Crucial personal data—such as contacts, SMS messages, tasks, and call history—was maintained inside the pim.vol file (or CE database tables). Upgrade modes extracted these databases independently without writing over OS-level files.
  3. App-by-App File Placement: Software applications that were installed in user flash memory (e.g., \Program Files or the storage card) were restored individually, re-registering their dynamic link libraries (DLLs) without replacing OS-level dependencies in the \Windows directory.

Native and Advanced Alternatives

Advanced users frequently avoided system backup software altogether when jumping between ROM versions. Instead, they relied on automated provisioning scripts and tools such as UC (User Customization) or Sashimi.

These tools automated the post-flash configuration rather than restoring raw image files. Once a new ROM booted for the first time, an SD-card script automatically reinstalled applications via individual CAB files, restored PIM data from standalone XML or CSV exports, and applied custom registry tweaks sequentially. This guaranteed that the core operating system remained clean while still restoring the user's environment.