[BUG] Claude Desktop install causes Windows 10 Task Manager to crash when switching to More details

Update: Exact trigger narrowed down in comments. The crash is caused by the malformed / extra-quoted HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Claude startup registry value.

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Note: This is a Claude Desktop issue, not a Claude Code issue. Anthropic support directed me to file it here.

Installing Claude Desktop causes Windows 10 Task Manager to crash when switching from compact view to "More details".

The issue persists even after terminating all visible Claude-related processes. Task Manager only returns to normal after uninstalling Claude Desktop.

This appears to be related to something Claude Desktop installs or registers on the system/user profile, not simply the running Claude app process.

What Should Happen?

Installing Claude Desktop should not affect Windows Task Manager.

Task Manager should switch to detailed view normally regardless of whether Claude Desktop is installed or whether Claude-related processes are running.

Error Messages/Logs

Application Error:

Faulting application name: Taskmgr.exe
Faulting application version: 10.0.19041.6280
Faulting module name: Taskmgr.exe
Faulting module version: 10.0.19041.6280
Exception code: 0xc0000005
Fault offset: 0x00000000000748a1
Faulting application path: C:\Windows\system32\Taskmgr.exe
Faulting module path: C:\Windows\system32\Taskmgr.exe

Windows Error Reporting:

Event name: APPCRASH
P1: Taskmgr.exe
P2: 10.0.19041.6280
P4: Taskmgr.exe
P5: 10.0.19041.6280
P7: c0000005
P8: 00000000000748a1

Crash dump collected:

Taskmgr.exe.10212.dmp
Size: 162,575,208 bytes
Created: 2026-04-15 00:06:59 KST

Steps to Reproduce

1. Start from a state where Claude Desktop is not installed.
2. Open Windows Task Manager.
3. Click "More details".
4. Confirm Task Manager works normally.
5. Install Claude Desktop.
6. Ensure no visible Claude-related processes are running.
7. Open Windows Task Manager.
8. Click "More details".
9. Task Manager immediately crashes.
10. Terminate visible Claude-related processes and try again.
11. Task Manager still crashes.
12. Uninstall Claude Desktop.
13. Open Windows Task Manager again.
14. Click "More details".
15. Task Manager works normally again.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

Unknown

Claude Code Version

N/A - this issue is about Claude Desktop, not Claude Code. Anthropic support directed me to file it here.

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

Environment:

• Product: Claude Desktop
• Claude Desktop version: TODO: add version from About screen
• Installation note: I installed Claude Desktop for the first time yesterday from the official download page, so the installed build should be recent.
• OS: Windows 10 Pro 22H2
• OS build: 19045.6466
• Locale: Korean / ko-KR
• Time zone: Asia/Seoul
• Task Manager path: C:\Windows\System32\Taskmgr.exe
• Taskmgr.exe version: 10.0.19041.6280

Important observations:

• Task Manager works normally before Claude Desktop is installed.
• Task Manager crashes after Claude Desktop is installed.
• Killing visible Claude-related processes does not fix the issue.
• Uninstalling Claude Desktop fixes the issue.
• Resetting Task Manager preferences does not fix the issue.
• The Microsoft Authenticode signature for Taskmgr.exe is valid.
• The crash signature is consistent across reproductions.

Things already tried:

• Terminated visible Claude-related processes.
• Result: Task Manager still crashes.
• Reset Task Manager user preferences:
• HKCU\Software\Microsoft\Windows\CurrentVersion\TaskManager\Preferences
• Result: Task Manager still crashes.
• Verified Taskmgr.exe Microsoft Authenticode signature.
• Result: Signature is valid.
• Uninstalled Claude Desktop.
• Result: Task Manager works normally again.

This suggests an installer-side or registration-side compatibility issue, possibly involving something that remains registered after installation.

Possible areas to investigate:

• WindowsApps registration
• PATH / App Execution Alias behavior
• updater registration
• shell or protocol registration
• scheduled task
• per-user registry entry
• Electron / Chromium runtime side effect
• helper component or integration left registered after installation

====================================================================

Update: exact trigger identified

I narrowed this down further using ProcMon and A/B testing.

The crash is caused by the exact formatting of the Claude Desktop startup registry value.

Registry path:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Claude

The problematic value created by Claude Desktop was:

"\"C:\Users\wildphs\AppData\Local\AnthropicClaude\claude.exe\" --startup"


A normal Run value that does not crash Task Manager is:

"C:\Users\wildphs\AppData\Local\AnthropicClaude\claude.exe" --startup


A/B test results

1. Claude Desktop installed with the original extra-quoted Run value:
   "\"C:\Users\wildphs\AppData\Local\AnthropicClaude\claude.exe\" --startup"

   Result:
   Task Manager crashes when clicking "More details".

2. Delete only the Run\Claude value:

   Result:
   Task Manager works normally.

3. Recreate Run\Claude manually with normal quoting:
   "C:\Users\wildphs\AppData\Local\AnthropicClaude\claude.exe" --startup

   Result:
   Task Manager works normally.

4. Recreate the original extra-quoted value:
   "\"C:\Users\wildphs\AppData\Local\AnthropicClaude\claude.exe\" --startup"

   Result:
   Task Manager crashes again.

So the issue is not caused by the Claude process running. It is triggered by the malformed / extra-quoted startup command registered under:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Claude


ProcMon observation

ProcMon showed Taskmgr.exe reading this value shortly before the crash:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Claude


Shortly after that, WerFault.exe was launched and Taskmgr.exe threads began exiting.

The BUFFER OVERFLOW result shown by ProcMon on the registry query is likely the normal Windows registry query pattern where the caller first receives the required buffer size and then retries successfully. I do not believe BUFFER OVERFLOW itself is the bug.

The important observation is that Task Manager reads the malformed Claude startup value immediately before Windows Error Reporting starts handling the Task Manager crash.

The later Thread Exit events appear to be a consequence of the crash, not the cause.

Exit status

ProcMon also showed Taskmgr.exe exiting with:

Exit Status: -1073741819

This corresponds to:

0xC0000005

which matches the Event Viewer access violation crash code.

Workaround

Recreate the startup entry with normal quoting:

Set-ItemProperty `
  -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run' `
  -Name 'Claude' `
  -Type String `
  -Value '"C:\Users\<your-user>\AppData\Local\AnthropicClaude\claude.exe" --startup'

Or remove the startup entry entirely:

Remove-ItemProperty `
  -Path 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run' `
  -Name 'Claude'

This keeps Claude Desktop installed. It only fixes/removes the startup registry entry.

Updated conclusion

The issue appears to be caused by the malformed / extra-quoted Claude Desktop startup registry value, not by the Claude Desktop process itself.

On my Windows 10 build, Windows Task Manager appears to crash while parsing or displaying this startup entry during detailed view / Startup tab initialization.

================================================

(2026/04/30)
After reinstalling Claude Desktop later, it appeared that the installation method had changed.

Previously, Claude used a startup registration under:
HKCU\Software\Microsoft\Windows\CurrentVersion\Run\Claude

That malformed startup string was the trigger for the Windows 10 Task Manager crash.

In the current installation, however, the Run\Claude value was no longer created.
Instead, Get-AppxPackage *Claude* showed Claude installed under
C:\Program Files\WindowsApps\...,
suggesting an MSIX/AppX-style packaged install.

A follow-up check with Process Monitor also showed that Task Manager was no longer reading the old Run\Claude startup string path.
Instead, it was querying AppModel / AppContainer package metadata.

So at least based on what I observed, the installation / registration path seems to have changed, and the old Task Manager crash trigger appears to be gone.