Claude Desktop 2.9939.2.0 fails to launch with 0x80070020; five stale Silo hives remain after service stop

Additional data point: Claude Desktop for Windows, MSIX package version 2.9939.2.0. I am omitting user and machine identifiers, raw paths, SIDs, container GUIDs, and process IDs.

Related issue: #53247. This report documents a verified recovery on version 2.9939.2.0 without sign-out or reboot.

Symptom and evidence

• Launching Claude produced the Windows dialog “Another program is currently using this file.” No Claude Desktop window or Claude.exe process remained. Windows Settings refused to repair the app because it considered the app running.
• Microsoft-Windows-AppModel-Runtime/Admin recorded Event 215 (0x80070020, error converting the job while creating the Desktop AppX container) and Event 208 (0x80070020, runtime setup / LaunchProcess). The installed package status was Ok.
• The packaged CoworkVMService was running. Stopping it did not clear the condition: a launch attempt restarted the service and failed with the same events. An elevated Microsoft Sysinternals Handle search for the package installation path found no matching handles.
• With CoworkVMService stopped and no Claude Desktop package processes running, five Claude-specific \REGISTRY\WC\Silo* hives remained mounted. They comprised software, user_sid, user_classes, and two com entries. The service's separate package hives disappeared when the service stopped.

Recovery observed

After checking that the service was stopped and no Claude Desktop package processes were running, I used a temporary SYSTEM task to call NtUnloadKey2(REG_FORCE_UNLOAD) only for the five hives whose backing paths belonged to the Claude package family. Four returned success on pass 1; the remaining COM hive returned 0xC0000121 on pass 1 and success on pass 2. No Claude user-data reset, uninstall, or reboot was performed.

Afterwards, hivelist showed zero remaining Claude user hives. Launching the registered app succeeded: AppModel-Runtime recorded Event 201, Claude.exe stayed alive, its main window responded, and CoworkVMService returned to Running with its original Auto start mode. I verified startup and window responsiveness, not sign-in or Cowork functionality.

This is consistent with a stale per-user container/hive state rather than an ordinary open handle to the executable. It does not establish which operation originally kept the container mounted. A supported, package-scoped recovery path and cleanup during update/relaunch would help avoid requiring a full sign-out or reboot.