These diagrams illustrate the interpretation made during the case. The captured output alone does not establish causality.

In this case, the update error remained after the visible app had been closed. An old-container Job handle became a diagnostic clue. The same error can have other causes: compare current processes, actual file handles and deployment events before drawing a conclusion.

The PIDs and versions below belong to the recorded session. These commands are case examples, not a checklist to run unchanged on another computer. Verify the current target and preserve active work before force termination or service changes.

/ 01 — SYMPTOM

You hit update, and the app vanished

The pattern goes like this. You restart the app to apply an update. During install, a warning says the executable is in use and the update never finishes. Then, when you try to open the app again, it won’t even start.

In the recorded session, ending processes with Claude in their name did not resolve the symptom. That does not rule out every process. A filter can miss relevant components or paths unavailable at the current privilege level; check what the query actually covers.

/ 02 — MISDIAGNOSIS

The process list is empty, yet it’s locked

In an elevated PowerShell, check two things: which Claude processes are alive, and what holds a handle on the files and objects. For handles, use Sysinternals handle.exe — it surfaces kernel objects more precisely than Task Manager or Resource Monitor.

# Live Claude processes (the app itself)
Get-Process *claude* | Select ProcessName, Id, Path

# What is holding what
handle.exe -a claude

Check · elevated PowerShell

The recorded Get-Process query returned no matches. This describes the filter result; it does not prove that no related process existed anywhere on the system. The handle.exe output included the following Job handle.

svchost.exe  pid: 8116  type: Job  710: \Container_Claude_1.15962.1.0_x64__pzs8sxrjxfjjc-...

Observation · a Job handle with the old-version name

The output shows a Job object handle, not a file handle. Microsoft documents that a Job object is deleted after all associated processes terminate and its last handle closes. This handle alone does not establish why MSIX refused a file replacement. Correlate actual file handles and deployment events.

Browser IndexedDB handles and task runners can appear in the search results. Do not terminate or exclude them solely because of a similar name; check paths, processes and deployment events. The old-version Job handle was a clue in this investigation.

/ 03 — PINPOINT

The clue: the versions don’t match

The WindowsApps*Claude* query matched the process below in that session. Finding a matching process and proving that it held the relevant lock are separate steps.

Get-Process | ? { $_.Path -like "*WindowsApps*Claude*" } | Select ProcessName, Id, Path

ProcessName   Id   Path
-----------   --   ----
cowork-svc  4408   …\Claude_1.17377.1.0_x64__…\resources\cowork-svc.exe

Observation · a process matching the query

The output contained a Job named for version 1.15962 and cowork-svc.exe under a version 1.17377 path. This is a clue to mixed version state. These two outputs alone do not establish that the process belonged to that Job or locked the package file.

/ 04 — RELEASE

Recorded recovery attempts and verification

The force-termination example below targeted PID 4408 in the recorded session. PID 4408 can now refer to a different process; do not run it unchanged. Verify the executable path and active work, and preserve unsaved content and pending output first. Automatic restart and absence of data loss are not guaranteed.

Stop-Process -Id 4408 -Force

# Check 1: is the Claude process gone?  -> empty output is correct
Get-Process | ? { $_.Path -like "*WindowsApps*Claude*" }

# Check 2: has the old-version Job disappeared?
handle.exe -a Container_Claude

Release attempt · step 1

The recorded Job handle remained after the termination attempt. An empty process query does not exclude a remaining open handle. That observation alone does not prove a kernel defect or a “zombie” state.

The service restart and re-registration below are recorded case actions, not mandatory steps for every update failure. They can affect shared services and other apps. Check current deployment errors, privileges and active work, and follow the product recovery guidance.

Restart-Service AppXSvc -Force -ErrorAction SilentlyContinue
Get-Service ClipSVC, AppXSvc, StateRepository | Restart-Service -Force -ErrorAction SilentlyContinue

# Re-register the new version to force the handover
Get-AppxPackage *Claude* | Foreach {
  Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml"
}

handle.exe -a Container_Claude   # check again

Release attempt · steps 2–3

In this case, the problem remained after service restart and re-registration, so the author proceeded to a reboot. This does not establish rebooting as the only possible remedy. Other environments require their own diagnosis.

A reboot is one way to reset running state. Its use in this case does not imply that every user must first terminate processes, restart services and re-register the package. Choose recovery actions for the current error and workload.

After rebooting, check app launch, the installed version and recurrence of deployment errors as well as the handle search. One disappearing handle is not sufficient to declare the update complete.

handle.exe -a Container_Claude
# if no 1.15962 line appears, you're done

Check · after the reboot

---

For the reader — points to watch

If you hit the same symptom, these four things are worth keeping in mind so you don’t make it worse.