When Az CLI and Windows Stop Playing Nice

Shannon's Disclaimer: All code for this blog can be found here. I'm going to start out code based blogs with their own repo and will clean up older blog posts as time allows.

If you spend enough time working in the cloud, you get used to things breaking in ways that make no sense. Case in point: the other day my Azure CLI on Windows decided it was going to stop working.

I started in WSL because that is usually where things behave the best. I ran az login and instead of the normal browser popup, I got a Python traceback referencing win32file. Not exactly what you want to see when you are just trying to log into Azure.

Here is what it looked like:

Traceback (most recent call last): File "<frozen runpy>", line 198, in _run_module_as_main File "<frozen runpy>", line 88, in _run_code File "D:\a\_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/__main__.py", line 13, in <module> File "D:\a\_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/core/telemetry.py", line 19, in <module> File "D:\a\_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\azure/cli/telemetry/__init__.py", line 9, in <module> File "D:\a\_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\portalocker/__init__.py", line 4, in <module> File "D:\a\_work\1\s\build_scripts\windows\artifacts\cli\Lib\site-packages\portalocker/portalocker.py", line 11, in <module> ImportError: DLL load failed while importing win32file: The specified module could not be found.

So I thought, “Alright, let’s try Git Bash.” Same error. Finally, I moved over to PowerShell, thinking I should cover all my proverbial bases. Nope. Same traceback again, line for line. At that point the only thing in common was my Windows environment (I know, I should just be on Mac...I get it).

And let’s be honest, Windows has a special sense of timing. Windows waits until you are fully invested in doing something useful, then taps you on the shoulder and says, “I thought you liked debugging random DLL errors.” If cloud platforms coined the term "chaos engineering", know Windows has been doing it for decades.

The Real Culprit

The short version is that Windows was picking up the wrong az executable. When you install the Azure CLI on Windows, it drops two files in the install directory:

• az.cmd → the one you actually want (a wrapper that launches the CLI correctly)

• az → the imposter that drags Python into the mix and immediately falls over itself

Guess which one my system decided to call first? Of course, the imposter.

The Fix

It took a bit of digging, but here is what cleared everything up:

1. Uninstall everything Azure CLI related. The usual uninstall did not cut it for me. I had to run:

winget uninstall Microsoft.AzureCLI --all-versions

2. That flushed out multiple copies of the CLI I did not even realize were on my machine (thanks, Windows).

3. Remove the leftovers manually...because Windows is about as thorough at cleanup as a raccoon in a kitchen.

Remove-Item -Recurse -Force "C:\Program Files (x86)\Microsoft ` SDKs\Azure\CLI2" -ErrorAction SilentlyContinue Remove-Item `      -Recurse -Force "C:\Program Files\Microsoft SDKs\Azure\CLI2" `    -ErrorAction SilentlyContinue 
Remove-Item -Recurse -Force ` "$env:USERPROFILE\AppData\Local\AzureCLI" -ErrorAction ` SilentlyContinue

4. Reinstall fresh with Winget:

winget install Microsoft.AzureCLI 

5. Verify the right path is being used:

where.exe az

6. This time the output showed only:

C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\wbin\az.cmd

7. Notice the .cmd. That is the one you actually want.

8. Log back in:

az login

9. And finally, the normal login flow returned.

   
   

Lessons Learned

• If you see win32file errors when using Az CLI on Windows, it is not Python’s fault. It is Windows choosing the wrong executable.

• Run where.exe az to confirm what is being executed. If you see multiple entries, one of them is probably sabotaging you.

• Use --all-versions when uninstalling. Otherwise, stale installs stick around like ghosts.

• Most importantly, do not underestimate Windows. It does not crash, it just runs its own brand of chaos testing at your expense.

  
  

Back in Business

Now that it is fixed, az login works again in WSL, Git Bash, and PowerShell. I would love to say I was surprised, but this feels like a rite of passage for anyone trying to wrangle cloud tooling on Windows.

The moral of the story? Assume Windows has a prank ready for you. And when it springs up, laugh, clean up the mess, and move on. Because in the end, half the battle with the cloud is convincing your local machine to play along.