Forum Discussion
Responsive ResidentOn-Prem gatewy: Mashup.Container.NetFX45.exe killing server memory.
Dear colleagues,
Since some weeks ago we are noticing that suddenly the server where our Enterprise On-Premise server is installed get stuck. We are not even able to access server itself due to its lack of resources (RAM mainly) and we need to restart the virtual machine from the VM Center.
Sometimes we have been able to monitor briefly the process while problem does occur and the guilty is quite obvious checking task manager
One of Mashup.Container.NetFX45.exe threads launched by the gateway is consuming more and more memory (around 14 GB when this screenshot was done and it) increased until server finally crashed because of lack of resources
As far a I know Mashup.Container.NetFX45.exe is part of the Power Query engine, enabling users to connect, combine, and shape data from various sources into a unified data model. So, its mainly handling power M requests using the on-premise gateway. Then the root cause has to be on some power bi artifact executing power-M over on-premise data (on our case datamodels and data flow gen 1 items)
My questions are
(1) As we have dozens of processes that are running at the same hour when memory issue occurs. How can we identify which exactly datamodel / dataflow gen 1 is behind this overhelming consumption of memory? That is, who is the guilty?
(2) Does it a way to limit the max amount of memory that this process Mashup.Container.NetFX45.exe might consume to prevent issue appears if somone does a crazy power M query?
(3) We are focusing our investigations on datamodels/dataflow gen1 consuming on-premise data, but could be the case where the on-premise gateway is using when processing cloud data?
Regards,
Note: We have installed Jan 2025 On-Premise Gateway release
You're correct: Mashup.Container.NetFX45.exe is responsible for executing Power Query (M) logic, and when complex or inefficient M scripts run through the On-premises Data Gateway, they can consume significant resources. Let's address your concerns step by step:
🔍 1. How to identify which model/dataflow is consuming excessive memory?
- Enable Gateway Performance Logs: On the Gateway machine, go to:
C:\Program Files\On-premises data gateway\Microsoft.PowerBI.DataMovement.Pipeline.Diagnostics.log
This file tracks queries and their resource usage. Look for logs near the crash timestamp to correlate with the Mashup.Container PID. - Use Gateway Monitoring Features: In the Power BI Service, go to:
Settings > Manage Gateways > Diagnostics
Enable diagnostics and download logs, which will include query names, durations, and related mashup containers. - Correlation ID Tracking: If you enable verbose logging on the gateway (via config.json), you can capture the activity ID or request ID and trace it back to the workspace, report, or dataflow using the Power BI Service logs.
- Cloud Usage Insights: Use Power BI Activity Log or Log Analytics (if enabled) to trace scheduled refreshes and which reports/dataflows ran at the time of memory spikes.
🧩 2. Can we limit the memory usage of Mashup.Container.NetFX45.exe?
Unfortunately, there is no direct way to cap memory usage of this process. However, here are possible mitigations:
- Install the latest gateway version: Always use the latest version, as memory management improvements are continuously added.
- Split heavy refreshes: If a dataset processes many queries at once, split them into smaller refresh partitions.
- Optimize Power Query:
- Avoid nested joins, large in-memory merges, and buffer-heavy operations (like Table.Buffer).
- Use query folding where possible—let the source system do the heavy lifting.
- Use the gateway's MashupMaxContainerPoolSize setting (in Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config) to control the number of parallel mashup containers, thereby indirectly limiting total memory footprint.
☁️ 3. Can the On-Premises Gateway be used for cloud data?
Generally, the On-Prem Gateway is only invoked for sources that reside on-premises. However:
- If the cloud report combines cloud and on-prem data in a single query, Power BI may route everything through the gateway to preserve privacy levels and data joining logic.
- Check if your dataset uses Privacy Levels that force data to be combined at the gateway.
📌 Recommendations
- Upgrade to the latest gateway release.
- Enable diagnostic logging and correlate high-memory PIDs to model/dataflow activity.
- Profile and optimize Power Query scripts.
- Monitor and limit concurrent refreshes during peak hours.
- Investigate Gateway Performance Monitoring tools and Premium Metrics App if you're using capacity.
✔️ If my message helped solve your issue, please mark it as Resolved!
👍 If it was helpful, consider giving it a Kudos!
- Enable Gateway Performance Logs: On the Gateway machine, go to:
2 Replies
- SolomonovAnton
Super User
You're correct: Mashup.Container.NetFX45.exe is responsible for executing Power Query (M) logic, and when complex or inefficient M scripts run through the On-premises Data Gateway, they can consume significant resources. Let's address your concerns step by step:
🔍 1. How to identify which model/dataflow is consuming excessive memory?
- Enable Gateway Performance Logs: On the Gateway machine, go to:
C:\Program Files\On-premises data gateway\Microsoft.PowerBI.DataMovement.Pipeline.Diagnostics.log
This file tracks queries and their resource usage. Look for logs near the crash timestamp to correlate with the Mashup.Container PID. - Use Gateway Monitoring Features: In the Power BI Service, go to:
Settings > Manage Gateways > Diagnostics
Enable diagnostics and download logs, which will include query names, durations, and related mashup containers. - Correlation ID Tracking: If you enable verbose logging on the gateway (via config.json), you can capture the activity ID or request ID and trace it back to the workspace, report, or dataflow using the Power BI Service logs.
- Cloud Usage Insights: Use Power BI Activity Log or Log Analytics (if enabled) to trace scheduled refreshes and which reports/dataflows ran at the time of memory spikes.
🧩 2. Can we limit the memory usage of Mashup.Container.NetFX45.exe?
Unfortunately, there is no direct way to cap memory usage of this process. However, here are possible mitigations:
- Install the latest gateway version: Always use the latest version, as memory management improvements are continuously added.
- Split heavy refreshes: If a dataset processes many queries at once, split them into smaller refresh partitions.
- Optimize Power Query:
- Avoid nested joins, large in-memory merges, and buffer-heavy operations (like Table.Buffer).
- Use query folding where possible—let the source system do the heavy lifting.
- Use the gateway's MashupMaxContainerPoolSize setting (in Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config) to control the number of parallel mashup containers, thereby indirectly limiting total memory footprint.
☁️ 3. Can the On-Premises Gateway be used for cloud data?
Generally, the On-Prem Gateway is only invoked for sources that reside on-premises. However:
- If the cloud report combines cloud and on-prem data in a single query, Power BI may route everything through the gateway to preserve privacy levels and data joining logic.
- Check if your dataset uses Privacy Levels that force data to be combined at the gateway.
📌 Recommendations
- Upgrade to the latest gateway release.
- Enable diagnostic logging and correlate high-memory PIDs to model/dataflow activity.
- Profile and optimize Power Query scripts.
- Monitor and limit concurrent refreshes during peak hours.
- Investigate Gateway Performance Monitoring tools and Premium Metrics App if you're using capacity.
✔️ If my message helped solve your issue, please mark it as Resolved!
👍 If it was helpful, consider giving it a Kudos!
- Enable Gateway Performance Logs: On the Gateway machine, go to:
v-sathmakuriCommunity Support
Hi alfBI ,
Thank you for reaching out to Microsoft Fabric Community.
Thank you SolomonovAnton for the prompt response.
May I ask if you have resolved this issue? If so, please mark the helpful reply and accept it as the solution. This will be helpful for other community members who have similar problems to solve it faster.
Thank you.