Windows: ImportError 'DLL load failed while importing _greenlet' with default uvx resolution (greenlet 3.5.4); pinning 3.2.4 fixes it

[singhguri]

Environment

• Windows 10/11 (git-bash), Python 3.11
• Installed via uvx mcp-server-linkedin@latest (uv 0.7.x)

Symptom

The server crashes on startup before doing anything:

ImportError: DLL load failed while importing _greenlet: The specified module could not be found.

Full traceback: patchright.async_api -> patchright._impl._greenlets -> greenlet -> _greenlet C-extension fails to load.

Root cause

uvx mcp-server-linkedin@latest resolves greenlet 3.5.4 whose Windows wheel's _greenlet.pyd fails to import (missing VC runtime dependency / broken wheel for this platform). The same machine works fine with a pinned older greenlet.

Fix that works

uv tool run --with greenlet==3.2.4 --with mcp-server-linkedin mcp-server-linkedin

Verified: server starts, all tools (get_person_profile, search_people, get_company_profile, etc.) work, login flow works.

Suggested fix

• Pin greenlet<3.3 (or >=3.2.4,<3.3) in the package's dependency spec, or
• Investigate why greenlet 3.5.4's Windows wheel fails to load and bump to a fixed release.

Happy to provide more logs. This blocks all Windows users of the server.

[stickerdaniel]

Thanks for the report, the reproduction was precise enough to track this all the way down.

The wheel isn't broken, it gained a system dependency. greenlet moved its Windows builds from Appveyor to GitHub Actions in 3.3.1 and lost the GREENLET_STATIC_RUNTIME flag on the way, so _greenlet.pyd links the C++ runtime dynamically now:

release	_greenlet.cp312-win_amd64.pyd imports
3.2.4	KERNEL32.dll, python312.dll
3.3.0	KERNEL32.dll, python312.dll
3.3.1 through 3.5.4	plus MSVCP140.dll, VCRUNTIME140.dll, VCRUNTIME140_1.dll

MSVCP140.dll comes with the Visual C++ 2015-2022 redistributable, and no Python distribution ships it. The python.org installer and the uv-managed builds both carry vcruntime140.dll and vcruntime140_1.dll and stop there. That is the module the error cannot find.

Installing the redistributable fixes it without any pin, and keeps working as greenlet moves on: https://learn.microsoft.com/en-us/cpp/windows/latest-supported-vc-redist

I'd rather not pin greenlet<3.3 here. The Windows ARM64 wheels only start at 3.3.1, so the pin would send those users into a source build, and it would freeze greenlet at August 2025 on macOS and Linux as well, for something that is local to one machine's configuration.

Filed upstream with the measurements, and the PR restores the flag: python-greenlet/greenlet#525, python-greenlet/greenlet#526. CI there builds clean x64 and ARM64 wheels again.

On this side I'll add a startup check that turns the raw ImportError into a message naming the redistributable, plus a troubleshooting entry. Those older wheels stay on PyPI forever, so the hint stays useful after greenlet ships the fix.

Could you confirm the redistributable route works on your machine?

[stickerdaniel]

greenlet 3.5.5 shipped the upstream fix, so this is resolved at the root: the published Windows wheels link the C++ runtime statically again. win_amd64 and win_arm64 both import python312.dll and KERNEL32.dll alone, no MSVCP140.dll.

uvx mcp-server-linkedin@latest picks that up on its own, no pin needed. The MCPB bundle pins 3.5.5 now too.

Thanks for the report.