workiq mcp server crashes repeatedly in msalruntime.DLL during WAM token acquisition

Summary

The workiq mcp server process crashes repeatedly with an unhandled stowed exception in msalruntime.DLL during WAM (Windows Account Manager) token acquisition. All 7 crashes over 3 days hit the exact same instruction (msalruntime.DLL+0x52214, exception 0xc000027b), indicating a deterministic bug in the MSAL native runtime's headless auth path.

Impact

• The MCP stdio server becomes unresponsive after a token expires, requiring manual process kill and restart.
• Auth popups appear repeatedly because the process crashes before it can cache a refreshed token.
• Downstream MCP clients (e.g., GitHub Copilot CLI) receive Authentication failed or TypeError: fetch failed errors.

Reproduction

1. Start the MCP server: workiq --account user@microsoft.com mcp
2. Wait for the initial MSAL token to expire (~1 hour), or run several queries to accelerate token refresh
3. The process crashes during the next token acquisition attempt
4. A crash dump is written to %LOCALAPPDATA%\CrashDumps\workiq.exe.<pid>.dmp

Frequency: 7 crashes in 3 days (Apr 28–30, 2026). 100% identical crash signature.

Crash Details (from Windows Event Log — Application Error)

All 7 events are identical except for PID and timestamp:

Faulting application name: workiq.exe, version: 0.4.1.19742
Faulting module name:      msalruntime.DLL, version: 0.0.0.0
Exception code:            0xc000027b (STATUS_STOWED_EXCEPTION)
Fault offset:              0x0000000000052214

Crash Timeline

Observations

• msalruntime.DLL is versioned 0.0.0.0 — this may indicate a debug, pre-release, or improperly versioned build of the MSAL native runtime bundled with WorkIQ.
• The exception code 0xc000027b (STATUS_STOWED_EXCEPTION) is a COM/WinRT async exception, suggesting the WAM broker throws an error that is not caught by the calling code.
• Hypothesis: When running as a headless stdio server (no interactive window), msalruntime.DLL cannot fall back to interactive browser auth and instead throws an unhandled stowed exception. The WorkIQ process does not catch this and crashes.
• After a crash, the process sometimes restarts but remains in a degraded state (3 MB working set vs. normal 28 MB), serving as a zombie that returns auth errors.

Environment

• WorkIQ version: 0.4.1.19742
• OS: Windows 11 (NT 10.0.26200.0)
• Node.js: v22.18.0
• Install method: npm install -g @microsoft/workiq
• Binary path: ~\.agency\WorkIQ.Cli.win-x64\0.4.1.19742\tools\workiq.exe
• msalruntime.DLL path: ~\.agency\WorkIQ.Cli.win-x64\0.4.1.19742\tools\msalruntime.DLL

Crash Dumps

7 dump files are available at %LOCALAPPDATA%\CrashDumps\workiq.exe.*.dmp (each ~5 MB). Happy to share if needed.

Suggested Fix

• Catch the stowed exception from msalruntime.DLL during token acquisition and fall back gracefully (e.g., return an auth error to the MCP client rather than crashing the process).
• Consider adding a --no-wam or --use-device-code flag for headless/MCP scenarios where interactive WAM auth is not possible.
• Version the bundled msalruntime.DLL properly (currently reports 0.0.0.0).

Start by reproducing workiq --account user@microsoft.com mcp on Windows and inspect the matching files in %LOCALAPPDATA%\CrashDumps, along with the Windows Event Log details. Trace token acquisition around the WAM failure; done means token refresh no longer crashes the process and the MCP client receives a controlled authentication result or supported headless-auth path.