Repository navigation
[BUG] Cannot conect to server using Microsoft Entra - MFA #2184
Description
Activity
Thanks Josh — the screenshot has the whole answer in it, and this is my bug, not your environment.
The load-bearing line is:
Error code 0xwindow_handle_required Failed to acquire access token for ActiveDirectoryInteractive: A window handle must be configured. See https://aka.ms/msal-net-wam#parent-window-handlesRoot cause, confirmed in the code. Current
Microsoft.Data.SqlClientuses the Windows WAM broker (Web Account Manager) forAuthentication=ActiveDirectoryInteractiveon Windows, and WAM requires the calling application to hand MSAL a parent window handle so it can position and own the account picker. An app that never supplies one gets exactly this error instead of a prompt.Lite never supplies one. I grepped the whole repo: there are zero references to
ActiveDirectoryAuthenticationProvider,SqlAuthenticationProvider, orSetParentActivityOrWindowFuncanywhere. So Entra MFA cannot currently work in Lite on any machine — this isn't specific to your tenant or your server.Why your other tools work. This also explains the pattern you noticed:
- SSMS works because it registers its own window handle with MSAL.
- Performance Studio 1.4.3 works because it predates the SqlClient version that made WAM the default; interactive auth fell back to a system/embedded browser, which needs no handle.
- Performance Studio 1.19.1 and Lite 3.4.0 both fail because both are on the newer SqlClient (this repo pins 7.0.2), where WAM is the default path. Same missing registration, two products.
That last point is the useful part of your report — you gave me the version boundary, which is what turns "some auth error" into a specific dependency behavior change. Thank you for including it.
The fix is app-side and small: register an auth provider carrying the WPF main window's HWND before any Entra connection is opened, roughly
var provider = new ActiveDirectoryAuthenticationProvider( parentActivityOrWindowFunc: () => new WindowInteropHelper(mainWindow).Handle); SqlAuthenticationProvider.SetProvider(SqlAuthenticationMethod.ActiveDirectoryInteractive, provider);
It has to be wired for the real top-level window (and re-resolved rather than captured once, since the handle isn't valid until the window is sourced), and it needs the same treatment anywhere Lite opens a connection off the UI thread. I'll take it in the 3.5.0 window and will test it against a real Entra-MFA instance rather than just compiling it.
In the meantime, if you need Lite pointed at that server today, the non-interactive Entra modes don't go through WAM and so aren't affected — Service Principal is the practical one if your tenant allows an app registration with the right SQL permissions. SQL authentication also works if the instance permits it. Neither is as convenient as MFA; I'm not going to pretend there's a good workaround for the mode you actually want.
One question, only because it changes how I test the fix: is that server Azure SQL / Managed Instance, or SQL Server 2022 on a VM with Entra authentication enabled? Your version string says 2022 Enterprise on Windows Server 2022, so I'm assuming the VM case with Entra auth configured — just want to confirm before I go set up the same shape.
Tracking this as the bug it is; I'll post here when the fix is in a build you can try.
- Hello Erik. Thank you for quick response. You are correct. It is SQL Server on Azure VM, with Microsoft Entra MFA enabled for authentication. I'm more interested in Performance Studio because I do more design and performance tuning then monitoring now. But love your work and wanted to dig around. And after seeing your PM presentation I feel like it may well surpass Brent's FRK. I will stay with older version and will be happy to test a build against our environment once you have one available. I appreciate the work you've put into this. Best regards Josh
Thanks Josh — that confirms the shape I'll build against: SQL Server on an Azure VM with Entra MFA authentication, which is the case where SqlClient hands interactive auth to the WAM broker and needs the window handle. Nothing about your setup is unusual; the gap is entirely mine.
Staying on the older Studio build is the right call for now, and I'll take you up on testing — an Entra-MFA-on-VM environment is exactly what I can't fully reproduce from a synthetic test, and "it compiles and the dialog appears on my machine" is not the same as "it authenticates against a real tenant." I'll post here when there's a build worth pointing at your environment.
Worth being straight about the ordering, since you said Studio matters more to you than monitoring: the fix is the same missing registration in both products, but they ship on different cadences. I'll do it in Lite first because that's where the issue is filed and where I can test it end to end, then port it. If Studio is the one you actually need, say so and I'll flip that order — it's the same change either way, and I'd rather sequence it around the tool you're going to use.
And thank you for the kind words. I'd gently push back on the FRK comparison though — Brent's toolkit and this solve genuinely different problems, and "surpass" isn't really the axis. Yours is the more useful contribution here anyway: you gave me the version boundary (1.4.3 works, 1.19.1 doesn't) in your first report, which is what turned a vague auth error into a specific dependency behaviour change I could go find in the code. That saved me a lot of guessing.
I would prefer Studio first. Pleas let me know if you want me to clone this issue in PS page.
Flipped — Studio first, and no need for you to clone anything. Filing my own bookkeeping isn't your job: it's erikdarlingdata/PerformanceStudio#425, cross-linked both ways, and this issue stays open for the Lite half.
Confirmed the same defect is there before filing, rather than assuming it transferred: Studio pins the same SqlClient 7.0.2,
ServerConnection.BuildConnectionStringsetsActiveDirectoryInteractive, and the repo has zero references toActiveDirectoryAuthenticationProvider,SqlAuthenticationProviderorSetParentActivityOrWindowFunc. Same missing registration, same cause.Worth telling you that it's a bit more involved on the Studio side, so you know why it isn't a same-day patch:
- Studio's app is Avalonia, not WPF, so the handle comes from
TopLevel.TryGetPlatformHandle()rather than WPF's helper — and it has to be re-resolved per call, since it isn't valid until the window is sourced. - It has to be Windows-gated. WAM doesn't exist on macOS or Linux, where interactive auth already works via a browser, and registering a handle-supplying provider unconditionally would break the platforms Avalonia is there for.
- The CLI has no window at all, and it accepts
--auth entra. That needs a real answer (device-code flow, or documenting it as unsupported from the CLI with a service-principal pointer) rather than being left to fail the same way. I've filed that as the open question instead of guessing at it.
Your offer to test still stands as the most useful thing here — I can build it and see a picker appear, but only you can tell me it actually authenticates against your tenant. I'll ping you on the Studio issue when there's something worth pointing at it.
(And your 1.4.3-vs-1.19.1 observation is doing real work across two repos now. That's the whole reason this went from "some auth error" to a specific line of code in an afternoon.)
- Studio's app is Avalonia, not WPF, so the handle comes from
Thank you Erik. Just let me know when it's ready for test.
- added 3 commits that reference this issue
on Aug 12, 2026 The Lite half is merged (#2217) — same fix as Studio's, ported to WPF: Lite now hands the WAM broker the window handle it was never supplying, registered once at startup so the Add/Edit dialog's Test Connection and every background collection pass are covered.
It will be in tomorrow's nightly build (the
nightlyprerelease on this repo, unsigned) and in the next stable release. Given what you saw in Studio, expect the same here: no browser window, and possibly no picker at all — your Windows session already satisfies MFA, so the broker connects silently. That silence is the fix working.No obligation to test this half — your Studio verification already proved the seam against a real tenant, and Lite's port is the same registration on the same SqlClient. But if you do point Lite at that VM and anything looks off, this is the right place to say so.
Thanks again, Josh. Your 1.4.3-vs-1.19.1 observation ended up fixing two products.
My pleasure. Thank you for the do you do :)
Will there be any more youtube videos on latest Performance Studio features?@joshdbe I haven't really added new features to it for a bit. I'm pretty happy with it at the moment. If you have any requests, I can take a look at them/improving things. Most of my work these days is going into the monitoring tool.
Reacted by Josh PokrasovClosing this — the fix shipped and I never came back to close the issue.
Both halves are merged: Performance Studio's, and Lite's in #2217. Verified in
dev:App.xaml.csregistersEntraInteractiveAuth.Register(ActiveWindowHandle)at startup, so the WAM broker gets the parent window handle it needs forAuthentication=ActiveDirectoryInteractive, and it is registered once rather than per-dialog — which is what covers both the Add/Edit dialog's Test Connection and every background collection pass.Root cause for the record, since it is a good one to have written down: current
Microsoft.Data.SqlClientroutes interactive Entra auth through the Windows WAM broker, and WAM requires the calling application to supply a parent window handle so MSAL can position and own the account picker. An app that never supplies one gets0xwindow_handle_required— "A window handle must be configured" — instead of a prompt. Nothing to do with the server, the tenant, or your environment; SSMS and Studio 1.4.3 worked because they supply one.Josh — thank you again. Your 1.4.3-vs-1.19.1 comparison was the whole diagnosis: it turned "MFA is broken" into "something changed in the auth path between these two versions", which is what made it findable. That one observation fixed two products.
(And noted on the Studio feature requests — that is a separate conversation, not a reason to keep a fixed bug open.)
Reacted by Josh PokrasovHello Erik. Do you have a build I can dig around?
Sure do — the nightly release always carries a Lite build straight off
dev, and the Entra fix has been in there since it merged:https://github.com/erikdarlingdata/PerformanceMonitor/releases/tag/nightly
Grab
PerformanceMonitorLite-3.4.0-nightly.<date>.zip. A couple of notes:- It's a rolling release — the assets get replaced each build, so the date stamp moves. There's a fresh one publishing within the hour, but today's existing zip already has the fix.
SHA256SUMS.txtsits next to it if you want to verify the download.- It's a plain zip, not an installer — extract and run. Windows may mark the download; right-click the zip → Properties → Unblock before extracting saves some SmartScreen nagging.
The bit you'll want to dig at for the MFA fix specifically:
App.xaml.csregisters the parent-window-handle callback with MSAL once at startup, so the WAM account picker has an owner window on every path — Test Connection in the Add/Edit dialog and the background collection passes both. First interactive prompt should behave exactly like SSMS's.If the picker shows up and signs in but anything downstream looks off, that's exactly the report I want — open a fresh issue and tag it. Thanks again, Josh.
Reacted by Josh Pokrasov- added a commit that references this issue
on Oct 1, 2026
Component
Lite
Performance Monitor Version
3.4.0
SQL Server Version
Microsoft SQL Server 2022 (RTM-CU24-GDR) (KB5089900) - 16.0.4252.3 (X64) Apr 26 2026 07:08:29 Copyright (C) 2022 Microsoft Corporation Enterprise Edition: Core-based Licensing (64-bit) on Windows Server 2022 Datacenter 10.0 (Build 20348: ) (Hypervisor)
Windows Version
Microsoft Windows 11 Enterprise
Describe the Bug
Hello Erik.
Install PM Lite on local pc.
Getting attached error when connecting to server using Microsoft Entra _MFA. Having no issues in SSMS or your Performance Studio 1.4.3. Getting same error in Performance Studio 1.19.1
Please let me know if you need additional information.
Thank you.
Josh
Steps to Reproduce
Expected Behavior
Connect to the server
Actual Behavior
Getting attached error
Error Messages / Log Output
Screenshots
No response
Additional Context
No response