Share via

Power BI Desktop "Cannot establish connection" - msmdsrv.exe listening but connection timeout

兴烨 姚 0 Reputation points
2026-06-02T13:27:29.3566667+00:00

Hello,

I'm experiencing a persistent issue with Power BI Desktop failing to start. The error message is:

"Cannot establish connection. Please verify that the server is running."

Environment

  • OS: Windows 11 Pro (10.0.26200)
  • Hardware: Intel Core i5-12400F, AMD Radeon RX590 GME
  • Power BI version: 2.154.1260.0 (May 2026)
  • Also tried older versions (including 2022 releases) – same error.

Observed Behavior

  1. When launching PBIDesktop.exe, the splash screen appears, then the error pops up.
  2. Using Process Explorer, I can see that msmdsrv.exe (the embedded Analysis Services engine) does start and listens on a random port on localhost (e.g., 127.0.0_ipam_placeholder_ 127.0.0_ipam_placeholder_ 127.0.0_ipam_placeholder_ 127.0.0_ipam_placeholder_ 127.0.0_ipam_placeholder_ 127.0.0_ipam_placeholder_
  3. However, PBIDesktop.exe cannot connect to that port – the connection attempt times out.

Troubleshooting Already Performed

I have spent many hours investigating and ruled out the following:

  • ✅ Third-party antivirus/interception: Uninstalled Tencent PC Manager (QQPCRTP service) that was intercepting localhost TCP connections. Also removed AlibabaProtect service (Alibaba security component) and its folder.
  • ✅ AMD Crash Defender Service: Disabled.
  • ✅ Windows Firewall: Checked inbound rules – no blocking rules found.
  • ✅ Windows Defender Real-time Protection: Turned off – no effect.
  • ✅ Third-party kernel filter drivers: Checked with Get-WmiObject Win32_SystemDriver – only Microsoft built-in drivers present.
  • ✅ Winsock LSP: Catalog is clean – all Microsoft (mswsock.dll) providers, no third-party LSP.
  • ✅ Network stack: Performed netsh winsock reset and rebooted – issue remains.
  • ✅ Hosts file, proxy settings, network adapters: Verified no anomalies.
  • ✅ Multiple reinstalls: Including older versions of Power BI Desktop.
  • ✅ .NET Framework / VC++ runtimes: Repaired / reinstalled.
  • ✅ Local group policy: No restrictions found on TCP connections.

Additional Diagnostics

  • Test-NetConnection -ComputerName 127.0.0_ipam_placeholder_-Port <port> returns TcpTestSucceeded: False.
  • Event Viewer shows no relevant errors for msmdsrv or PBIDesktop.
  • No FrownLogs generated (Power BI doesn't reach the logging stage).

Suspected Cause

Something on the system is silently blocking/intercepting TCP connections to localhost, but all common culprits have been eliminated. It might be a corrupted user profile, a group policy object, or a low-level system component that I haven't identified.

Request for Help

Has anyone encountered this specific issue? Any suggestions on what else to check? Could it be a user-profile corruption? Would using Process Monitor (Sysinternals) help pinpoint the failure?

Any guidance would be greatly appreciated. Thank you!

Additional notes:

  • I do have administrator privileges on this machine.
  • No VPN or proxy software is installed.
  • The issue started recently after a system update (maybe?).

Please let me know if you need any logs or additional information.

SQL Server | Other
SQL Server | Other

Additional SQL Server features and topics not covered by specific categories

0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Deepesh Dhake 80 Reputation points
    2026-06-04T17:42:40.1233333+00:00

    You can try following steps to test:

    1. Run the bare loopback test: Start any listener not related to Power BI and test it:

    $l = [System.Net.Sockets.TcpListener]8765; $l.Start(); Write-Host "listening"; Read-Host

    then in another window:

    Test-NetConnection 127.0.0.1 -Port 8765

    If this fails too, the problem is your Windows TCP loopback stack, not Power BI. If it succeeds, the problem is specific to how Power BI/msmdsrv bind or talk to each other.

    1. Check what msmdsrv is actually bound to.: Your symptom (listener confirmed, but connect times out) is exactly what you see when the client and server use different loopback addresses (127.0.0.1 vs ::1).

    netstat -ano | findstr <port>

    Confirm the PID matches msmdsrv and note whether it's 127.0.0.1, 0.0.0.0, or [::1]. This is a factual check that will tell you something real.

    1. Check the excluded port range: This is a known, documented cause of "listener exists but can't connect" on Windows, and it fits your "started after an update" note:

    netsh int ipv4 show excludedportrange protocol=tcp

    If msmdsrv's random port falls inside a reserved range, the connection fails silently. Reservations from Hyper-V/WSL2/Docker/Fast Startup get re-triggered by updates.

    1. A timeout means dropped packets, not refusal: A refused connection returns immediately and a timeout means the SYN is going somewhere with no response. That genuinely narrows it toward a binding mismatch or something dropping the packet, and away from "nothing is listening."

    Your symptom localizes the failure to the loopback connection path, and the tests above will identify which layer there is an issue.

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-06-02T13:27:59.9733333+00:00

    Power BI Desktop relies on a local Analysis Services (msmdsrv.exe) instance and a WebView2-based shell. When Desktop cannot connect to its own local engine, Microsoft guidance is to treat this as a startup/launch issue and collect diagnostics rather than continue ad‑hoc OS/network debugging.

    From the documented troubleshooting steps, the following actions are supported and recommended:

    1. Verify WebView2 and security software
    • Startup failures and connection issues are often caused by security/antivirus products interfering with WebView2 or the embedded engine.
    • Add the environment variable WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS with value --disable-features=RendererCodeIntegrity under Settings > System > About > Advanced system settings > Environment Variables > User variables, then start Power BI Desktop again.
    • If Desktop starts successfully with this variable, remove the variable and configure any security software to exempt the WebView2 process and Power BI Desktop.
    1. Reinstall WebView2 (Store version scenario)
    • If using the Microsoft Store version and seeing startup/connection issues, uninstall WebView2 and reinstall it using the documented WebView2 installation link.
    • This is the supported way to repair WebView2 without requiring administrative permissions.
    1. Collect WebView2 and startup diagnostics for support If the problem persists, Microsoft guidance is to open a support incident and provide detailed traces:
    • WebView2 error reports
      • For Store version: collect reports from
        • c:\Users\<username>\Microsoft\Power BI Desktop Store App\WebView2\EBWebView\Crashpad\reports
        • c:\Users\<username>\Microsoft\Power BI Desktop Store App\WebView2Elevated\EBWebView\Crashpad\reports
      • For EXE version: collect reports from
        • c:\Users\<username>\AppData\Local\Microsoft\Power BI Desktop\WebView2\EBWebView\Crashpad\reports
        • c:\Users\<username>\AppData\Local\Microsoft\Power BI Desktop\WebView2Elevated\EBWebView\Crashpad\reports
    • Installer and update logs
      • From the documented locations (copy these paths into File Explorer and copy out the logs):
        • %temp%\msedge_installer.log
        • %ProgramData%\Microsoft\EdgeUpdate\Log\MicrosoftEdgeUpdate.log
        • %windir%\Temp\MicrosoftEdgeUpdate.log
        • %allusersprofile%\Microsoft\EdgeUpdate\Log\MicrosoftEdgeUpdate.log
        • %systemroot%\Temp\msedge_installer.log
        • %localappdata%\Temp\msedge_installer.log
        • %localappdata%\Temp\MicrosoftEdgeUpdate.log
    • Event Viewer logs
      • In Event Viewer:
        • Go to Applications and Services log > Microsoft > Windows > CodeIntegrity > Operational and Save All Events As.
        • Also save Windows Logs > Application.
    • Registry ClientState key
      • Open regedit and export:
        • HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\EdgeUpdate\ClientState
    • Process traces
      • Use Process Monitor (Procmon) as documented to capture process traces while starting Power BI Desktop.
    • Windows Performance Recorder trace for WebView2
      • Download the EdgeWebView2_General_EventsOnly.wprp profile.
      • In Windows Performance Recorder, choose More options, then Add Profiles and load the profile.
      • Start recording, reproduce the startup failure, then Save the trace.
    1. Escalate to Power BI support
    • If the above steps (WebView2 repair, security exclusions, and diagnostics) do not resolve the issue, open a support incident with Power BI support and provide:
      • WebView2 crash reports
      • Device ID (from Settings > System > About)
      • Installer/update logs
      • Event Viewer exports
      • Registry export and Procmon/WPR traces

    This is the documented path for persistent startup/connection issues where Power BI Desktop cannot successfully initialize its local engine.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.