On-premises Data Gateway 3000.314.5 - Microsoft.Mashup.Container.NetFX45.exe crashes on Virtual Mach

[pfarias]

Environment

• OS: Windows Server 2019 (Build 17763) 
• Gateway version with issue: 3000.314.5 (April 2026)
• Gateway version working: 3000.306 (February 2026)

Problem During installation, the service PBIEgwService fails to start with Error 1920. The root cause is that Microsoft.Mashup.Container.NetFX45.exe crashes repeatedly with the following error:

• Exception: System.Environment.FailFast
• Message: Unexpected exception in background thread of Mashup container (error code -2146233088)
• Event: CLR20r3 — FatalError

The process crashes within seconds of being launched, preventing the service from starting and causing the installer to roll back.

What was already checked

• .NET Framework 4.8 installed
• Windows Defender exclusions added for gateway folder and process
• Visual C++ Redistributable updated to 14.44.35211
• WebView2 Runtime installed (147.0.3912.86)
• FIPS disabled
• Performance counters rebuilt with lodctr /R
• Windows fully updated (latest patch: KB5082414, April 2026)

Partial workaround Setting the following system environment variable before installation resolves the crash on version 3000.306 but does NOT fix version 3000.314.5:

WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS = --disable-gpu --no-sandbox --disable-software-rasterizer

Conclusion Version 3000.314.5 introduced a breaking change in Microsoft.Mashup.Container.NetFX45.exe that causes it to crash on virtual machines without GPU acceleration, even with the WebView2 GPU workaround applied. Version 3000.306 works correctly with the same workaround.

Has anyone else experienced this issue with the latest Gateway version on a VM environment? Is there a known fix or configuration to make 3000.314.5 work?

[pfarias]

Update: Tested version 3000.318.9 (May 28, 2026)
A new Gateway version (3000.318.9) was released today and we tested it on the same VM environment.

Result: Installation failed with the same error.
Microsoft.Mashup.Container.NetFX45.exe continues to crash during service initialization with the same FatalError -2146233088 pattern, even with all previously documented workarounds applied:

WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS = --disable-gpu --no-sandbox --disable-software-rasterizer --use-gl=swiftshader
WEBVIEW2_USER_DATA_FOLDER = C:\GatewayWebView2Data with full permissions for NT SERVICE\PBIEgwService

Current status:
Staying on version 3000.310.1 (March 2026) which continues to work correctly. The Gateway is online and operational on this version.

This confirms the issue is a persistent regression present in versions 3000.314.5 and 3000.318.9. The fix has not been included in the latest release.

We will continue monitoring future releases and update this thread when a fix is confirmed.

[lbendlin]

Thank you for finding this.

If you have a Pro license you can open a Pro ticket at https://admin.powerplatform.microsoft.com/newsupportticket/powerbi
Otherwise you can raise an issue at https://community.fabric.microsoft.com/t5/Issues/idb-p/Issues .

[pfarias]

Gateway 3000.314.5 - Microsoft.Mashup.Container.Ne... - Microsoft Fabric Community

[v-veshwara-msft]

Hi @pfarias ,

Thanks for reaching out to Microsoft Fabric Community. The details and workarounds you've shared really help in understanding the issue better.

Since 3000.314.5 only released on April 27th, there's no confirmed fix from Microsoft yet for this on GPU-less VMs, so staying on 3000.306 for now is the right call while this gets tracked.

That said, a couple of things are worth trying on 3000.314.5.

On top of your existing WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS flags, try adding --use-gl=swiftshader. WebView2 is built on Chromium and SwiftShader is its documented CPU fallback for GPU-less environments --not confirmed specifically for this gateway version but worth trying given the crash pattern.

Also try setting WEBVIEW2_USER_DATA_FOLDER explicitly to a path like C:\GatewayWebView2Data and give NT SERVICE\PBIEgwService full control on it before running the installer.

Microsoft's documentation specifically flags this service account as one that can silently fail to write to the default WebView2 profile path when running in service context

Troubleshooting the Power Query Web connector - Power Query | Microsoft Learn

If the installer keeps rolling back at the service start step, there's a workaround others have used for Error 1920 --> when the progress bar hits around 90%, manually open PBIEgwService properties, clear the password on the Log On tab, and start the service yourself. This lets the installer complete without the container crash blocking it

Solved: Re: Power BI Gateway Installation issues - Microsoft Fabric Community

Similar thread for reference : Solved: Gateway Error .Net Framework 4.30319 yet 4.8 is in... - Microsoft Fabric Community

Hope this helps. Please reach out for further assistance.
Thank you.

[pfarias]

Update — Additional tests performed based on your recommendations

Thank you for the suggestions! Here is what happened after testing each one:

1. --use-gl=swiftshader flag Added to the existing WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS variable. The Gateway Updater installed successfully, but Microsoft.Mashup.Container.NetFX45.exe still crashes during the GatewayComponents installation step.

2. WEBVIEW2_USER_DATA_FOLDER environment variable Created C:\GatewayWebView2Data, granted full control to NT SERVICE\PBIEgwService, and set the variable. No change in behavior, crash persists.

3. Error 1920 workaround (clearing password on Log On tab) Windows does not allow saving the service properties without a password when using a service account, so this workaround could not be applied as described.

4. Switching to Local System account Changed PBIEgwService to run as Local System during installation. A new error appeared: "The service is marked as an interactive service. However, the system is configured to not allow interactive services." The crash continued regardless.

Current status: Version 3000.314.5 remains uninstallable on this VM environment. The crash pattern suggests the Microsoft.Mashup.Container.NetFX45.exe requires an interactive desktop session that is not available in this virtual machine configuration.

We are staying on version 3000.310.1 for now. If Microsoft releases a fix or a new version addresses this, we will test again and update this thread.

Thanks again for the support, this is clearly a bug introduced in 3000.314.5 on GPU-less virtual machines.

[v-veshwara-msft]

Hi @pfarias ,

Thanks for sharing the detailed test results and confirming the behavior.

Also appreciate you raising this in the Issues section and sharing the link here. That will help with visibility and tracking for others seeing the same issue.