Fixing Azure Storage Explorer Hub Controller Crash (Apple Silicon)

A step-by-step fix for Azure Storage Explorer failing to launch or authenticate on Apple Silicon Macs.

If Azure Storage Explorer crashes on launch or during sign-in on an M-series Mac with the error “Hub Controller process exited prematurely with exit code 131”, this walks through the exact fix — from reinstalling the correct build through to a working sign-in.

Root Cause

Two separate problems were stacked on top of each other, and both needed fixing before sign-in would work.

Working definition

The error is a symptom, not a single cause. On Apple Silicon it typically means an x64 build is running under Rosetta, that the required .NET 10 runtime is missing from a fixed path, or that a known native Authentication Broker bug is intercepting sign-in — sometimes all three.

Wrong build architecture. An x64 (Intel) build was running under Rosetta on Apple Silicon — a common source of native-library crashes.
Missing .NET 10 runtime. Storage Explorer’s authentication component (“Hub Controller”) requires the .NET 10 runtime installed at a specific, fixed path. Without it, the app crashes with the exit code 131 error above.
Native auth broker bug. Even after installing .NET, a known bug (tracked in the Azure Storage Explorer GitHub repo — issues #8997, #9002, #9008, #9154) affects the native Authentication Broker component on recent macOS versions. The documented workaround is to force Storage Explorer to use the system browser for sign-in instead of its native broker.

Step 1 — Uninstall the Old Build

Quit Storage Explorer completely.
Delete Microsoft Azure Storage Explorer.app from /Applications.
Empty Trash.
Restart the Mac (not strictly required, but rules out stale state).

Step 2 — Download the Correct Installer (.pkg, ARM64)

Go directly to the official GitHub releases page rather than the Azure marketing page — it has direct download links per platform and architecture:

URL: github.com/microsoft/AzureStorageExplorer/releases/latest
Expand the Assets section
Download StorageExplorer-darwin-arm64.pkg — not the .zip. The .pkg installer handles installation and permissions more cleanly than manually unzipping and dragging into /Applications.

This lands in ~/Downloads/StorageExplorer-darwin-arm64.pkg (roughly 301.6 MB).

Step 3 — Run the .pkg Installer

Open Finder → ~/Downloads
Double-click StorageExplorer-darwin-arm64.pkg
In the Installer app: Continue → Continue (Standard Install on “Macintosh HD”) → Install
Enter the Mac account password when the system authorization prompt appears — this step has to be done by the Mac’s own user, it can’t be automated
Confirm the installer reports: “The installation was successful.”

This installs to /Applications/Microsoft Azure Storage Explorer.app.

Step 4 — Confirm the Real Root Cause

Open the newly installed app. If it still fails immediately with the same error —

“The authentication library used by Storage Explorer has failed to start properly. Please ensure you have .NET 10 installed… Error: Hub Controller process exited prematurely with exit code 131.”

— that rules out wrong architecture and a corrupted download as the cause, and points at a missing .NET 10 runtime (per Storage Explorer GitHub issue #8997).

Step 5 — Install the .NET 10 Runtime (ARM64)

Download from the official Microsoft .NET download page — not Homebrew or mise, since those install to non-standard paths that Storage Explorer doesn’t check:

URL: dotnet.microsoft.com/en-us/download/dotnet/10.0
Under the “.NET Runtime 10.0.12” section — not the SDK — choose macOS → Arm64 installer

This downloads dotnet-runtime-10.0.12-osx-arm64.pkg (32.3 MB) to ~/Downloads. Run it the same way as Step 3:

Double-click the .pkg in Finder
Continue → Continue (Standard Install, 86.9 MB) → Install
Enter the Mac password when prompted
Confirm: “The installation was successful.”

Verification

Open Terminal and run:

dotnet --list-runtimes

The output should confirm the correct install location:

Microsoft.NETCore.App 10.0.12 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

/usr/local/share/dotnet is exactly the path Storage Explorer’s installer checks first, which also rules out a wrong-path problem.

Step 6 — Relaunch Storage Explorer

Relaunch the app. The main window should now load properly — a real improvement over the previous full-app failure. But clicking “Sign in with Azure” can still trigger the same Hub Controller crash dialog. That confirms the .NET runtime is correctly installed, but a separate bug in the native Authentication Broker / Hub Controller component — a known open issue on recent macOS versions, e.g. GitHub issue #9154 — is still causing the crash specifically during sign-in.

Step 7 — Force System-Browser Sign-In

This bypasses the broken native auth broker entirely by having Storage Explorer hand off sign-in to the default web browser instead.

In Finder, press Cmd+Shift+G (“Go to Folder”) and navigate to ~/Library/Application Support/StorageExplorer
Find settings.json in that folder — it’s created automatically by Storage Explorer on first launch
Open it with TextEdit (right-click → Open With → TextEdit)
Add a new key, application.signIn.signInUsing, set to "systemBrowser"
Save the file (Cmd+S)

Before:

{
  "application.telemetry.userId": "25190084-dad6-42a5-bd81-a8adab5f968f",
  "application.signIn.verboseLogging": true
}

After:

{
  "application.telemetry.userId": "25190084-dad6-42a5-bd81-a8adab5f968f",
  "application.signIn.verboseLogging": true,
  "application.signIn.signInUsing": "systemBrowser"
}

If settings.json doesn’t already exist — for example on a first-ever launch — create it in the same folder with just:

{
  "application.signIn.signInUsing": "systemBrowser"
}

Step 8 — Quit and Relaunch

Quit the app fully, then reopen it (Applications → Microsoft Azure Storage Explorer, or Spotlight).

The app should load cleanly, with no error dialog.
Click “Sign in with Azure” → Select Azure Environment (leave “Azure” selected) → Next.
The Sign In screen should show: “Your browser should now open and redirect you to a login page. Waiting for authentication…”
The default browser opens to the Microsoft login page, and sign-in completes there normally, with no crash.

Modern Lens

A crash dialog that names a process and an exit code is not the same as a root cause. This one had three independent causes stacked on top of each other — wrong architecture, a missing runtime at a fixed path, and a native component bug — and each had to be ruled out in order before the actual fix was clear. That is a useful discipline whenever a tool fails at a well-known step: fix the improbable first, then let the real error surface.

Summary of Changes

/Applications/Microsoft Azure Storage Explorer.app — old x64 build deleted, ARM64 build reinstalled via .pkg
~/Downloads/StorageExplorer-darwin-arm64.pkg — downloaded installer (can be deleted after install)
~/Downloads/dotnet-runtime-10.0.12-osx-arm64.pkg — downloaded installer (can be deleted after install)
/usr/local/share/dotnet/ — created by the .NET runtime installer
~/Library/Application Support/StorageExplorer/settings.json — edited to add "application.signIn.signInUsing": "systemBrowser"

No environment variables ($PATH, shell profile, etc.) were changed — only the two .pkg installs and the one JSON settings edit above.

This article documents a specific troubleshooting sequence for educational reference. Product behavior, download locations and open-source issue numbers may change over time; verify current file paths and GitHub issue status against the official Microsoft and Azure Storage Explorer sources before relying on this sequence.

Fixing Azure Storage Explorer’s Hub Controller Crash on Apple Silicon Macs