Windows: Browser pane hang leaves the MSIX package unregistered (0x80073D28 - packaged service needs elevation)

Status Open

Reported on v2.1.229

Maintainer reply None cached

Activity 0 comments · opened Aug 16, 2026

Browser pane hang leaves the MSIX package unregistered ("Reinstall the application from its original install location")

Summary

On Windows, opening the Browser pane (preview_start / computer) hangs
Claude Desktop. Windows kills the hung process, and the package servicing
operation that runs afterwards fails with

0x80073D28: Cannot register the Claude_1.30096.5.0_x64__pzs8sxrjxfjjc package.
Administrator privileges required to install packaged service

When that failure sticks, the app will not start again. Windows shows
*"We encountered a problem with Claude. Reinstall the application from its
original install location or contact your administrator."* The user has had to
fully uninstall and reinstall Claude Desktop several times because of this.

The trigger is the Browser pane itself, not a local dev server. The
occurrence documented below started from preview_start on a plain remote
https:// URL, with no dev server involved at any point.

Environment

| | |
|---|---|
| OS | Windows 10 Pro 22H2, build 19045.6456, x64 |
| Claude Desktop | 1.30096.5.0 (MSIX, Claude_pzs8sxrjxfjjc) — also seen on 1.30096.1.0 |
| Claude Code | 2.1.229 |
| User | member of Administrators, session not elevated |
| Install | C:\Program Files\WindowsApps\Claude_<version>_x64__pzs8sxrjxfjjc |

Steps to reproduce

On Windows, with Claude Desktop installed from the MSIX package, open a

session in any project.

Call preview_start with a remote URL (no dev server needed).
Call computer with action: "screenshot".
The app stops responding. Windows logs an Application Hang and terminates it.
Restart the app.

Expected

The screenshot returns, or fails with an error. Restarting the app works.

Actual

The app hangs and is killed. The package servicing that follows fails on the
packaged-service registration. On some occasions the retry succeeds and the app
recovers; on others the package is left unregistered and the only path the user
found was a full uninstall + reinstall.

Evidence

Two Application Hang events for claude.exe, on two different builds:

2026-08-16 12:01:24   Application Hang (1002)   claude.exe 1.30096.5.0
2026-08-14 21:39:51   Application Hang (1002)   claude.exe 1.30096.1.0

Timeline for the 2026-08-16 occurrence, local time, cross-checked between the
session transcript, C:\ProgramData\Claude\Logs\cowork-service.log, the
Application log and Microsoft-Windows-AppXDeploymentServer/Operational:

12:00:25.049   session: preview_start  {"url": "https://<remote-site>/<page>"}   -> ok
12:00:30.387   session: read_console_messages                                    -> ok
12:00:30.402   session: computer {"action": "screenshot"}                        -> no result, transcript ends here
12:00:30.751   cowork-service.log: [Server] Persistent RPC: connection ended: failed to read length: EOF
12:00:30.751   cowork-service.log: [Server] Session <...> has no active connections, idle timeout starts
12:01:24.917   cowork-service.log: Service stop requested / Shutdown signal received
12:01:24       Application log: Application Hang 1002, claude.exe stopped interacting with Windows
12:01:24       Application log: Windows Error Reporting 1001, type 5
12:01:18       AppXDeploymentServer 404: 0x80073CFA  "Windows cannot remove Claude_1.30096.5.0_x64__pzs8sxrjxfjjc
                because the PreserveApplicationData flag can only be used on a package
                that was deployed in development mode"
12:01:28       AppXDeploymentServer 404: 0x80073D28  "Cannot register the Claude_1.30096.5.0_x64__pzs8sxrjxfjjc
                package. Administrator privileges required to install packaged service"
12:01:33       AppXDeploymentServer 400: Add operation from C:\...\Temp\Claude-<id>.msix completed
12:01:34       AppXDeploymentServer 471: 0x12C (oplock request denied) deleting
                WindowsApps\Deleted\Claude_1.30096.1.0_...\app\chrome_200_percent.pak
12:01:34       cowork-service.log: "Warning: failed to configure recovery actions
                (a crashed service will stay down until reboot): open service: Access is denied."

Analysis

The MSIX package ships a packaged Windows service, CoworkVMService
("Claude VM Service"), running as LocalSystem from inside the package
directory:

C:\Program Files\WindowsApps\Claude_<version>_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe

Two consequences that combine badly:

Registering a packaged service requires elevation. The auto-update /

repair deployment runs in the user's unelevated context, so it fails with
0x80073D28. When that failure lands mid-servicing, the package is left
without a valid registration, which is exactly what produces the
"Reinstall the application from its original install location" dialog. The
user is in the Administrators group, but the interactive session is not
elevated, and nothing prompts for elevation.

The service holds the package directory in use. File deletions during

servicing fail with 0x12C (oplock request denied), and stale versions
accumulate. Event 1230 currently lists roughly sixteen orphaned package
versions whose hardlinks have no package in the repository:
1.13576.0.0, 1.13576.1.0, 1.13576.4.0, 1.15200.0.0, 1.15962.0.0,
1.15962.2.0, 1.17377.1.0, 1.18286.2.0, 1.19367.0.0, 1.20186.7.0,
1.21459.1.0, 1.22209.0.0, 1.24012.1.0, 1.24012.11.0, 1.25927.0.0,
1.28929.0.0.

The service also cannot configure its own SCM recovery actions
("open service: Access is denied"), so if it does crash it stays down until
reboot.

Impact

The failure mode is unrecoverable for a normal user: the app will not open, and
the error text sends them to reinstall. There is no in-app path back.

Workaround

Re-registering the package from an elevated PowerShell replays the step that
lacked privileges, and avoids the uninstall/reinstall cycle:

Get-AppxPackage -Name Claude | ForEach-Object {
  Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"
}

Run unelevated, it fails with the same 0x80073D28.

Two secondary issues found along the way

C:\ProgramData\Claude\Logs\cowork-service.log has grown to 260 MB with

no rotation or size cap.

The orphaned package versions listed above are never cleaned up, and each

failed servicing operation adds another.

Suggestions

Do not let a Browser pane / VM service RPC failure take the main window down

with it. The RPC connection ended with a plain EOF; the UI never recovered.

Make package servicing survive a failed packaged-service registration, or

request elevation for it, rather than leaving the package unregistered.

Add rotation to cowork-service.log.

View original on GitHub ↗