Power BI Gateway Errors: DM_GWPipeline Codes Explained

Gateway errors have a property that makes them more disruptive than most Power BI failures: when one error appears, it usually represents many datasets failing simultaneously. All datasets routed through the affected gateway fail together — not one by one, not in random order. If ten datasets share a gateway and the gateway goes offline, ten refresh failures land in your incident feed at the same time.

This simultaneity is actually diagnostic information. A cluster of refresh failures across datasets that have nothing in common except their gateway is almost certainly a gateway problem, not a per-dataset problem. The DM_GWPipeline error codes are the gateway's way of telling you what kind of gateway problem it is.

The error codes fall into two groups: errors about the connection between Power BI Service and the gateway itself (the cloud-to-gateway link), and errors about the connection between the gateway and the data source (the gateway-to-data link). The fix direction is different for each group.

GatewayUnreachable is a cloud-to-gateway link failure. Power BI Service sent a refresh request to the gateway cluster and got no response. The gateway is not offline from your perspective — the Windows service may be running, the machine is up, the data source is accessible. But the Service Bus relay connection that Power BI uses to communicate with the gateway has been severed.

Common causes: the gateway Windows service stopped (often silently after a Windows update that required a restart but didn't automatically restart the service); outbound traffic from the gateway machine to Azure Service Bus (*.servicebus.windows.net on port 443 or 5671) was blocked by a firewall rule change; the gateway registration was invalidated after a machine name or domain change.

Fix: open the On-premises data gateway application on the gateway machine. If it shows offline, that confirms the issue. Check the Windows Services console and verify the gateway service is started. If the service is running but the gateway is still showing offline, restart it and wait two to three minutes for the Service Bus connection to re-establish. For network-related blocks, run the connectivity diagnostics from the gateway app's Status tab and check outbound firewall rules against *.servicebus.windows.net.

MashupDataAccessError is a gateway-to-data link failure. The gateway received the refresh request from Power BI, but when it tried to query the data source, it failed. The cloud-to-gateway link is working; the problem is between the gateway machine and the database or file server.

This is the most common DM_GWPipeline error in production environments. Common causes: credentials stored in the gateway expired or were reset (the gateway uses a separate credential store from Power BI Service — credentials must be updated in both places); the data source server is temporarily down or its hostname changed; a network policy or firewall rule on the gateway machine's local network is blocking outbound connections to the source host.

Fix: in Power BI Service, go to Settings → Manage gateways and re-enter the credentials for the affected data source — even if they appear correct, re-entering forces a re-validation and often resolves intermittent credential cache issues. Then log into the gateway machine and test connectivity to the source directly (ping, telnet, or SSMS for SQL sources). Check Windows Event Viewer on the gateway machine under Application log, source: On-premises data gateway, for additional error detail that Power BI Service does not surface.

The on-premises data gateway connects to Power BI Service through Azure Service Bus — a persistent relay connection that must be maintained for the gateway to receive refresh jobs. When this connection fails, the gateway is effectively offline even if the gateway machine is running and the data source is accessible.

This is different from GatewayUnreachable. GatewayUnreachable is Power BI's perspective — it can't reach the gateway. ServiceBusCommunicationException is the gateway's own error when it tries to maintain the Service Bus connection and fails.

Common causes: a firewall rule blocking outbound HTTPS (port 443) or AMQP (port 5671/5672) from the gateway machine; a proxy server intercepting and terminating TLS connections before they reach Azure; antivirus or endpoint security software blocking the gateway process's network calls.

Fix: on the gateway machine, open the gateway app and check connection status. If it shows disconnected, run the connectivity test in the diagnostics section — it tests specifically whether the Service Bus endpoints are reachable. If a proxy is in use, configure the proxy settings in the gateway configuration file (Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config). Temporarily disabling antivirus on the gateway machine and testing whether connectivity is restored can confirm whether endpoint security is the cause.

This error is more unusual than the others. Power BI submitted a refresh job to the gateway's queue, but when the processing engine went to retrieve it, the job was gone. The spool — the temporary queue that holds submitted refresh jobs — lost the operation before it could be executed.

The most common cause is a gateway service restart that occurred between job submission and job execution. If the gateway service restarted (because of a Windows update, an antivirus action, or a crash) after Power BI queued the job but before the gateway began processing it, the job is lost. A Service Bus reconnect can also drop in-flight operations.

Fix: trigger a manual refresh immediately — this error is almost always transient, and the refresh succeeds on retry. If the error recurs, check the Windows Event Log on the gateway machine for service restart events around the time of the failures. The root cause is usually gateway instability: the service is restarting, crashing, or being terminated by an external process. Update the gateway to the latest version (Microsoft releases updates monthly and frequently addresses spooling reliability), keep the gateway machine off the patch/reboot schedule during scheduled refresh windows, and review endpoint security logs for process termination events.

DM_GWPipeline_Gateway_UnknownError is the gateway's catch-all error code. It fires when the gateway cannot map the failure to a more specific category — typically because the gateway process crashed, was terminated by security software, or ran out of a resource (memory, disk) during processing.

Unlike most gateway errors, this one does not always indicate a configuration problem. A memory overflow during a large dataset refresh, a disk-full condition on the gateway machine's working directory, or a bug in the installed gateway version can all produce this code without any network or credential issue.

Fix: check Windows Event Viewer on the gateway machine for crash entries at the time of the failure. Review the gateway's own log files (typically in %LocalAppData%\Microsoft\On-premises data gateway\) for the error detail that the generic code hides. Ensure the gateway machine has at least several GB of free disk space. If the error is intermittent and coincides with large dataset refreshes, adding memory to the gateway VM or staggering concurrent refreshes reduces the memory pressure that often causes this error.

Note the subtle difference: DM_GWPipeline_UnknownError (without _Gateway_) is a distinct error from the gateway catch-all above. This one almost always wraps a CryptographicException — the SAML signing certificate or Kerberos certificate used for SSO is not accessible to the gateway service account.

This error appears specifically in environments using SAML-based SSO or Kerberos constrained delegation through the gateway. The SSO configuration requires a certificate whose private key the gateway service account must be able to read. If the service account's permissions on that certificate key are lost — for example, after a certificate renewal that didn't replicate the key permissions — every SSO-based refresh fails with this code.

Fix: inspect the full gateway log. The InnerType and InnerMessage fields in the log entry contain the actual error that the generic code wraps. If InnerType is CryptographicException, verify that the SAML or Kerberos certificate is installed in the correct certificate store on the gateway machine, and that the gateway service account has read access to the private key (use certlm.msc → right-click the certificate → Manage Private Keys). Re-run the gateway SSO configuration wizard after granting key access and restart the gateway service.

MetricSign groups gateway-related failures by the gateway cluster, not by the datasets they affect. One incident covers all datasets that failed together, lists them in the detail view, and includes the gateway error code and the last known gateway health status. The engineer sees the scope immediately and starts the gateway fix — not ten separate per-dataset investigations.