[BUG] WMI Corrupted by thread killing at Rate-Limit being hit

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?

My Windows WMI was corrupted by abrupt thread termination at rate-limit,
I rebooted with a full reboot, not fast, and the WMI was still corrupted.
I ended up working on it for 2 hours to get my computer running normal again.
(for a simple rate-limit you need to behave better as a software on my computer!)

What Should Happen?

At rate-limit allows for graceful thread termination, perhaps allow for theads to wait and resume at timeout or other logical way of not hard crashing all the threads.

Error Messages/Logs

You're right. I'll stop and wait for you to reboot. After reboot, we can:

  1. Test if python -c "import tensorflow" completes
  2. If yes, run the integration test: pytest tests/integration/comsol/test_java_round_trip_comsol.py -v -s
  3. If TF is still broken, reinstall it: uv pip install --reinstall tensorflow

  All the code changes (dispatcher gaps, format_report, test updates) are ready. Just need TF to unstick.
  
  =================
  
  $env:TF_ENABLE_ONEDNN_OPTS = "0"
   $env:CUDA_VISIBLE_DEVICES = "-1"
   .venv\Scripts\python.exe -c "import tensorflow as tf; print(tf.__version__); print('OK')"
   
   
   If that works, try removing CUDA_VISIBLE_DEVICES=-1 to see if the GPU itself is the issue, or if it was just the zombie process pileup.

Also worth noting — your set command didn't actually take effect (the oneDNN message still said "on"). That's because PowerShell's set is an alias for Set-Variable, not for setting environment variables. That's why it was still hanging the same way.
Want me to investigate the TF double-import issue in your codebase (core/__init__.py line 40 and the second import path) while you reboot? That way we can also prevent TF from loading twice, which will help avoid this pileup in the future.

 WMI is so stuck it can't even stop gracefully. You'll need to force-kill it. In that same admin PowerShell:

  # Kill the WMI host process directly
  Stop-Process -Name "WmiPrvSE" -Force -ErrorAction SilentlyContinue
  taskkill /F /FI "SERVICES eq Winmgmt"

  If that still doesn't work, the nuclear option:

  # Kill all stuck Python processes first, then force-stop WMI
  Get-Process python* -ErrorAction SilentlyContinue | Stop-Process -Force
  sc.exe stop Winmgmt
  sc.exe start Winmgmt

  If even sc.exe stop hangs, you may need to kill the svchost.exe instance hosting WMI:

  # Find which svchost hosts Winmgmt
  tasklist /SVC /FI "SERVICES eq Winmgmt"
  # Then kill that PID (replace XXXX with the actual PID)
  taskkill /F /PID XXXX
  # WMI should auto-restart since it's set to Automatic

  Worst case: a full shutdown (not restart — hold Shift while clicking Shutdown to bypass Fast Startup) and cold boot
  may be needed since WMI is deeply stuck.

● Background command "Test WMI query from PowerShell" failed with exit code 1
  ⎿  UserPromptSubmit hook error

● That was the background WMI PowerShell test from earlier — it finally timed out an


this worked on Admin PS

PS D:\LocalGitRepos\OCD-Local> Stop-Process -Name "WmiPrvSE" -Force -ErrorAction SilentlyContinue
PS D:\LocalGitRepos\OCD-Local>

Steps to Reproduce

At rate-limit dialog
Choose: Stop and Wait for Limit to Reset

Claude will hard crash all active threads and sub-threads without regard for consequences.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

v2.1.90

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_