[BUG] Windows Server 2025: cumulative update KB5094125 (OS build 26100.32995) breaks MSIX registration — package lands "Modified, NeedsRemediation" despite deployment reporting success; removing the LCU fixes it

Found 1 possible duplicate issue:

1. https://github.com/anthropics/claude-code/issues/68792

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Not a duplicate of #68792 — same HRESULT, but this report adds the specific trigger (cumulative update KB5094125 / OS build 26100.32995), confirms it on Windows Server 2025, and provides a verified fix (Remove-WindowsPackage of the LCU). #68792 has neither a root cause nor a fix.

Claude Desktop MSIX: recurring NeedsRemediation caused by Code Integrity blocking vk_swiftshader.dll (package ships no CodeIntegrity.cat)

Prepared: 2026-07-23. For: Anthropic support ticket + comment on github.com/anthropics/claude-code/issues/70700

Environment

• Windows 11 Pro 25H2, build 26200 (desktop machine, NOT Windows Server)
• NOT MDM-managed (no Intune/SCCM), single user, per-user install via official MSIX
• Package: Claude_1.24012.1.0_x64__pzs8sxrjxfjjc
• Windows Defender only, zero threat detections in the relevant period (verified twice)

Symptom

Claude Desktop package repeatedly enters Status: Modified, NeedsRemediation
(PackageStatus = 2 under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\AppModel\StateChange\PackageList\<PackageFullName>,
BinaryName = app\vk_swiftshader.dll). App then fails at GPU process init
(GPU process gone, exitCode: 101457950 in main.log), CoworkVMService cannot start
(sc start returns error 87, "The parameter is incorrect").

Every known workaround is temporary: Settings Repair/Reset, setting PackageStatus = 0
plus reboot, and two full uninstall/reinstall cycles all worked for a few hours, then the
package was flagged again. On 2026-07-22 the package was flagged 4 separate times.

Root cause evidence (Microsoft-Windows-CodeIntegrity/Operational log)

Each incident is preceded by exactly this event cluster, with claude.exe as the loading process:

Event 3010 (Warning, x3):
Code Integrity was unable to load the \Device\HarddiskVolume3\Program Files\WindowsApps\
Claude_1.24012.1.0_x64__pzs8sxrjxfjjc\AppxMetadata\CodeIntegrity.cat catalog.
Status 0xC000003A.

Event 3033 (Error):
Code Integrity determined that a process (...\WindowsApps\Claude_1.24012.1.0_x64__pzs8sxrjxfjjc\app\claude.exe)
attempted to load ...\WindowsApps\Claude_1.24012.1.0_x64__pzs8sxrjxfjjc\app\vk_swiftshader.dll
that did not meet the Microsoft signing level requirements.

Occurrences on 2026-07-22: 15:20:09, 18:19:40, 18:27:21, 23:31:35. The 23:31 cluster is the
only Claude-related event of any kind between a healthy check at 19:23 and the package being
found flagged at 09:00 next morning. In that overnight window there were: no AppX deployment
operations, no Windows updates (nothing installed after 2026-07-16), no reboots, no power
events, no NTFS errors, no Defender detections. The Code Integrity block is the only candidate
trigger, and BinaryName in the StateChange registry key points at the exact same DLL.

Key facts:

1. The package does not contain AppxMetadata\CodeIntegrity.cat at all. The folder

AppxMetadata does not exist even in a freshly downloaded and installed MSIX
(package root contains only: app, assets, AppxBlockMap.xml, AppxManifest.xml,
AppxSignature.p7x, priconfig.xml, resources.pri, resources.scale-200.pri).
Status 0xC000003A in Event 3010 is simply "path not found".

1. vk_swiftshader.dll is NOT corrupted or tampered with. Get-AuthenticodeSignature

returns Valid, signed by CN="Anthropic, PBC". The "Modified" package state is a false
positive from Windows' perspective of the failed signing-level check, not actual tampering.

1. The trigger is sporadic because vk_swiftshader.dll is only loaded when the Electron GPU

process falls back to the SwiftShader software renderer. That is why the package can
survive many launches and then suddenly get flagged, and why every repair holds only
until the next fallback.

1. Control case: Google Chrome on the same machine logs the identical Event 3033 for its own

vk_swiftshader.dll several times a day with zero consequences, because Chrome is not MSIX
so there is no package for Windows to flag. This strongly suggests the bug is in the MSIX
packaging (missing code integrity catalog for a DLL that gets loaded under a
Microsoft-signing-level Code Integrity Guard mitigation), not in the machine.

Suggested fix directions (for the Claude Desktop team)

• Ship AppxMetadata\CodeIntegrity.cat in the MSIX so catalog validation of

vk_swiftshader.dll (and other Electron DLLs loaded under CIG) can succeed, or

• Relax/adjust the CIG (MicrosoftSignedOnly) mitigation on the GPU process for the MSIX

build, or otherwise prevent a SwiftShader fallback from poisoning the whole package state.

Relation to issue #70700

Same package family, same Modified, NeedsRemediation status, same "works for months then
suddenly breaks" pattern. This report adds: Windows 11 desktop (not Server 2025), no MDM,
no Windows update correlation, and a concrete reproducible trigger (CI Events 3010+3033 on
vk_swiftshader.dll with the catalog file absent from the package). The LCU-removal fix from
that issue does not apply here: no cumulative update was installed in the failure window.

Update: July 2026 cumulative updates do NOT reproduce the issue

After the Windows Update pause expired, the server installed the July 2026 updates on 2026-07-27:

• KB5099536 (Security Update, OS build 26100.33158)
• KB5100998 (.NET Framework Security Update)

Claude Desktop works normally after reboot with these July updates installed. The Modified, NeedsRemediation issue from the June baseline (KB5094125 / build 26100.32995) does not recur.

This confirms the problem was specific to the June cumulative update. The workaround (removing that LCU) is no longer needed — the July updates work cleanly.

Regarding @vucko211212's Code Integrity root-cause analysis: I checked Microsoft-Windows-CodeIntegrity/Operational on my server — the only Event 3033 entries are from Google Chrome loading its own vk_swiftshader.dll. No Claude-related CI events were found. This does not rule out the same root cause (the relevant events from the June period may have rotated out after the LCU removal and reboot), but I cannot confirm it either.

Additional data point for #70700 — Windows 11 25H2 (Build 26200.8973), consumer SKU

Same failure mode as reported in #70700, but on a different Windows branch and a different LCU, which suggests the problem is broader than Windows Server 2025 / KB5094125.

Environment

| | |
|---|---|
| OS | Windows 11 Home 25H2, Build 26200.8973 |
| Claude Desktop | 1.24012.11.0 (MSIX, Claude_pzs8sxrjxfjjc, SignatureKind: Developer) |
| Recent LCUs | KB5101711, KB5101684 (installed 2026-07-29) |
| Install method | Official installer (not Store) |

Symptom

Package spontaneously transitions from Ok to Modified, NeedsRemediation, after which Windows blocks activation ("無法開啟此應用程式 / This app can't open — go to Advanced options and select Repair") and/or force-closes the running app mid-session. Windows auto-repair then re-adds the package, clearing the flag temporarily, and the cycle repeats.

Occurred 6 times in ~3 hours on 2026-08-04 between 17:52 and 20:36 local time.

Key finding: the flag is set with no file changes and no deployment activity

A polling watcher (15 s interval) captured a transition live:

20:35:54  STATUS CHANGE: Ok -> Modified, NeedsRemediation
  AppX deployment events in prior 6 min : NONE
  AppModel status events in prior 6 min : NONE
  Package files modified in last 10 min : NONE
  Defender detections                   : NONE
  Package processes alive               : NONE
  Preceding signals:
    20:34:41  Kernel-Power 566: system session transitioned 7 -> 9
    20:35:47  DCOM 10016: activation denied for CLSID {2593F8B9-4EAF-457C-B68A-50F6B8EA6B54}
              APPID {15C20B67-12E7-4BB6-92BB-7AFF07997402} running in application container
              Claude_1.24012.11.0_x64__pzs8sxrjxfjjc

The package contents are provably unmodified, so this appears to be the runtime integrity validation (AppxBlockMap.xml / AppxSignature.p7x chain) failing spuriously rather than actual package tampering.

Onset correlates with a deferred-registration self-update

00:56:35  Add operation, Claude-<hash>.msix
          Options: NormalPriorityRequest, DeferRegistrationWhenPackagesAreInUse
          (1.24012.9.0 -> 1.24012.11.0 while the old version was running)
00:56:42  New package status 0x80000; old package 0x200000 (registration pending)
09:15:54  RegisterByPackageFamilyName (ForceTargetApplicationShutdown,
          SkipReregisterIfPackageStatusOk) -> status 0x0, clean
          [app used normally for ~8 hours, no issues]
17:31:17  AppX container destroyed (app closed)
17:52:20  status already 0x2  <-- flag appeared silently, no deployment events in between

Every subsequent repair attempt produced the same triad:

Id=419  0x80073D02: Unable to install because the following apps need to be closed
Id=8107 Illegal non-AppStore or non-AppInstaller package integrity validation
        attempted for package <PKG>. Flags: 0x0
Id=8104 Failed to set the Trust Label on package <PKG> with flags 0x0. Error: 0x80070057

Ruled out on this machine (with evidence)

| Hypothesis | Result |
|---|---|
| Smart App Control interference | Ruled out — VerifiedAndReputablePolicyState = 0 (off) |
| Package files tampered / disk corruption | Ruled out — zero file changes at flag time; no NTFS/disk errors on C: in 7 days |
| Defender quarantine | Ruled out — zero detections |
| Auto-updater installing in a loop | Ruled out — updater logs only "Checking for updates", never downloads |
| Leftover claude.exe processes blocking registration | Insufficient — cleared all processes, registered cleanly to Ok, flag returned ~15 min later |
| CoworkVMService pinning the package | Not the cause — SCM 7034 "Claude service terminated unexpectedly" fires after the package enters remediation, i.e. it is a consequence. Matches #70700's finding that disabling the service does not help |
| Fresh reinstall from a newly downloaded installer | Does not fix it — reinstalled 19:00:02 (ForceApplicationShutdownOption, ForceUpdateFromAnyVersion), package was flagged again by 19:26 |
| Repair (Settings > Apps > Advanced options > Repair) | Temporary only — clears the flag, returns within ~15-30 min |
| Reset | Temporary and destructive — wiped local app data including sidebar session-group assignments (dframe-store.customGroupsByScope[].assignments), which have no server-side backup |

Impact

The force-close arrives without warning and terminates in-progress Claude Code sessions. Losing an agent mid-task is the practical damage, not the dialog itself.

Note for other users hitting this: Reset is offered right next to Repair in the same Windows dialog, and it silently destroys local-only UI state (session groups). Conversation transcripts under ~/.claude/projects are unaffected.

Workaround in use

Running Claude Code via the standalone npm CLI (@anthropic-ai/claude-code, outside the MSIX package) is unaffected by the package state and survives the desktop app being force-closed.

Not attempted

LCU removal (the fix that worked in #70700) — the KBs on this machine differ from the reported one, and removing security updates was not an acceptable tradeoff here.