fix-debugpy-wmi

Fixes the first-launch debugpy KeyboardInterrupt crash on Windows by pre-warming WMI via sitecustomize.py.

5|1|Updated Aug 18, 2023
One-click install
npx skills add https://github.com/thpoll83/PolyKybdHost --skill fix-debugpy-wmi-thpoll83
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: fix-debugpy-wmi
Source: https://github.com/thpoll83/PolyKybdHost/tree/main/.claude/skills/fix-debugpy-wmi
Command: npx skills add https://github.com/thpoll83/PolyKybdHost --skill fix-debugpy-wmi-thpoll83

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? On Windows with Python 3.13, the first VS Code debug launch fails with a KeyboardInterrupt inside platform._wmi_query because the WMI COM subsystem is not yet initialized when debugpy calls platform.platform(). This Skill applies a permanent fix so the first debug launch succeeds instead of only working from the second attempt onward. ## Core Features & Use Cases - Root-cause fix: Creates or updates sitecustomize.py in the venv's site-packages so platform.uname() pre-warms WMI before debugpy initializes. - Idempotent application: Detects an existing sitecustomize.py, skips if the fix is already present, or appends the pre-warm block without clobbering existing content. - Use Case: A developer on Windows with Python 3.13 sees every first VS Code debug session of the PolyKybdHost app crash with KeyboardInterrupt in platform.py; after applying this fix, the first launch attaches cleanly with no venv reinstall. ## Quick Start Fix the debugpy KeyboardInterrupt crash on my Windows Python 3.13 venv by adding the WMI pre-warm sitecustomize.py.

Frequently Asked Questions about fix-debugpy-wmi

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I fix KeyboardInterrupt in platform._wmi_query on first debugpy launch?

Create a sitecustomize.py in your venv's Lib\site-packages directory that imports platform and calls platform.uname() at interpreter startup. This pre-warms the WMI COM subsystem before debugpy initializes, so the first VS Code debug launch succeeds.

Why does my first VS Code debug session crash but the second one works?

This is a Python 3.13 race condition on Windows: the WMI COM subsystem is not yet initialized when debugpy's log.py calls platform.platform() on first attach. By the second launch the subsystem is warm, so the call succeeds.

Does this debugpy WMI bug affect Linux or macOS?

No, the bug is Windows-only because it involves the WMI COM subsystem in CPython's platform module. On Linux or macOS the equivalent sitecustomize.py path would be .venv/lib/pythonX.Y/site-packages/, but the fix is unnecessary there.

Will pip install or recreating the venv remove sitecustomize.py?

No, sitecustomize.py is a standard Python startup hook that is not tracked by pip, so package installs will not overwrite it. However, deleting and recreating the entire venv removes it, requiring the fix to be reapplied.

What if sitecustomize.py already exists in my venv?

The fix checks the existing file first: if the pre-warm block is already present it does nothing, and otherwise it appends the block at the end with a blank line separator, preserving any existing content.