Azure CLI 2.77.0 Broken on Windows

Symptom

After updating Azure CLI to version 2.77.0 (or nearby versions), any az command produces a Python traceback:

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

The traceback chains through:

• azure/cli/__main__.py
• azure/cli/core/telemetry.py
• portalocker/__init__.py
• portalocker/portalocker.py (line 11)

Commands like az login, az version, or az --version all fail identically.

Root Cause (Unclear)

The exact mechanism remains ambiguous. What’s clear: after upgrading to 2.77.0, some corrupted or invalid state emerged in the installation. Possible factors:

• Stale or corrupted binaries from previous installations shadowing fresh ones
• Version skew between portalocker and pywin32 dependencies
• Python environment or site-packages corruption

Important caveat

This reference blog post attributes the issue to PATH precedence (bare az shadowing az.cmd). However, post-fix inspection contradicts this. After reinstalling, both az (a bash script) and az.cmd coexist in PATH with az listed first—yet the system works. This suggests the root cause was not binary precedence per se, but something about the content or state of those binaries before reinstall. Without the broken files, the diagnosis cannot be verified.

Alleged Diagnostic

Run:

where.exe az

This performs the actual Windows PATH search (unlike where, which is a PowerShell alias). If you see multiple paths listed, or if the path ends with az instead of az.cmd, you’ve found the problem.

Do not use gcm or Get-Command to debug

Get-Command returns a result (often az.cmd) but doesn’t show all PATH entries or their precedence order. See Get-Command vs where vs where.exe

Fix

Complete uninstall and reinstall to purge stale binaries:

# Uninstall all versions
winget uninstall Microsoft.AzureCLI --all-versions
 
# Reinstall fresh
winget install Microsoft.AzureCLI
 
# Verify installation succeeded
where.exe az

If multiple paths appear, don’t worry—that’s normal. The reinstall will have refreshed the binaries, and az login should now work.

Why not manual cleanup?

The blog post included manual Remove-Item commands. In practice, winget uninstall --all-versions followed by reinstall is sufficient to fix the issue.

Once reinstalled, az login should work normally.