Activity

1. erngab

   added

   bugSomething isn't workingSomething isn't working

   on Jun 25, 2026
2. github-actions

   added

   invalidIssue doesn't seem to be related to Claude CodeIssue doesn't seem to be related to Claude Code

   on Jun 25, 2026
3. github-actions commented on Jun 25, 2026

   

   github-actionsbot

   on Jun 25, 2026 – with GitHub Actions

   More actions

   Found 1 possible duplicate issue:

   1. [BUG] error code 0x80073CF6 for Claude Desktop with Cowork on Windows 11. #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

   👎React with 👎1Reacted by Erngab
4. erngab commented on Jun 25, 2026

   

   erngab

   on Jun 25, 2026

   Author

   More actions

   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.
5. erngab

   changed the title [-][BUG] [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[/-] [+][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[/+] on Jun 25, 2026
6. vucko211212 commented on Jul 23, 2026

   

   vucko211212

   on Jul 23, 2026

   More actions

   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//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".
   2. 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.
   3. 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.
   4. 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.
7. erngab commented on Jul 27, 2026

   

   erngab

   on Jul 27, 2026

   Author

   More actions

   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.
8. kevinandjacy-pixel commented on Aug 4, 2026

   

   kevinandjacy-pixel

   on Aug 4, 2026

   More actions

   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.
9. github-actions

   added

   staleIssue is inactiveIssue is inactive

   on Aug 24, 2026
10. github-actions commented on Sep 8, 2026

    

    github-actionsbot

    on Sep 8, 2026 – with GitHub Actions

    More actions

    Closing for now — inactive for too long. Please open a new issue if this is still relevant.
11. github-actions

    closed this as not plannedon Sep 8, 2026