Faulting application FabricPipelineWorker.exe
Hello, we installed an On-premise data gateway version 3000.330.1 (August 2026) on a Windows Server 2025. Every time we connect to SAP over SAP Table Application Server to our SAP System on SAP Cloud, we get the following error: Application: FabricPipelineWorker.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: System.InvalidOperationException at Microsoft.DataTransfer.Common.ProcessManagement.Communication.MessageHandlerSet.Dispatch(Microsoft.DataTransfer.Common.ProcessManagement.Communication.IMessageChannel, Microsoft.DataTransfer.Common.ProcessManagement.Communication.Message) at Microsoft.DataTransfer.Common.ProcessManagement.Communication.MultiplexingMessenger.OnMessageToOtherChannel(Microsoft.DataTransfer.Common.ProcessManagement.Communication.IMessageChannel, MessageToOtherChannel) at Microsoft.DataTransfer.Common.ProcessManagement.Communication.MessageHandlerSet.Dispatch(Microsoft.DataTransfer.Common.ProcessManagement.Communication.IMessageChannel, Microsoft.DataTransfer.Common.ProcessManagement.Communication.Message) at Microsoft.DataTransfer.Common.ProcessManagement.Communication.IMessengerExtensions+<WaitForAsync>d__0`1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].MoveNext() at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task) at Microsoft.DataTransfer.Common.ProcessManagement.Communication.IMessengerExtensions+<WaitForAsync>d__1`1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].MoveNext() at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task) at Microsoft.DataTransfer.Common.ProcessManagement.RemoteService.RemoteServiceEnvironment+<DisposeServiceStubsAsync>d__4.MoveNext() at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task) at Microsoft.DataTransfer.DataMovementGateway.WorkerProcess.WorkerContainer+<StartAsync>d__11.MoveNext() at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task) at Microsoft.DataTransfer.DataMovementGateway.WorkerProcess.Program+<Main>d__1.MoveNext() at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(System.Threading.Tasks.Task) at Microsoft.DataTransfer.DataMovementGateway.WorkerProcess.Program.<Main>(System.String[]) AND: Faulting application name: FabricPipelineWorker.exe, version: 5.68.9706.2, time stamp: 0x900a871d Faulting module name: KERNELBASE.dll, version: 10.0.26100.33158, time stamp: 0x4332201f Exception code: 0xe0434352 Fault offset: 0x00000000000c75fa Faulting process id: 0x2234 Faulting application start time: 0x1DD3B1901C52B57 Faulting application path: C:\Program Files\On-premises data gateway\FabricIntegrationRuntime\5.0\Shared\FabricPipelineWorker.exe Faulting module path: C:\WINDOWS\System32\KERNELBASE.dll Report Id: a3bc643f-227b-4f9e-b7b7-45ff005eb05f Faulting package full name: Faulting package-relative application ID: Has anyone an idea? BR Thomas
Bug: QuickBooks connector (QuickBooks for Pipeline) fails OAuth login
When attempting to create a connection of type QuickBooks for Pipeline (Cloud category) via Manage Connections and Gateways in Microsoft Fabric, with the authentication method automatically set to OAuth 2.0, clicking the Edit credentials button results in an error when trying to initiate the OAuth login flow. Error message: Unable to start OAuth login for this data source. Connection string is not supported. Details: Query contains unsupported function. Function name: QuickBooksForPipeline.Contents Session Id: 6fb86dae-dc71-4a06-8f7f-b99aee7885df RequestId: 710bfcb8-ff7a-444d-90dc-c2dcc311e0f9 Cluster URI: https://api.powerbi.com Status code: 400 Time: Fri Sep 11 2026 07:54:51 GMT+0300 (Eastern European Summer Time) Steps to reproduce: In a Fabric workspace, open a Copy Data activity (Source) or go to Manage Connections and Gateways. Click "+ New" to create a new connection. Select connection type Cloud. Search for and select QuickBooks for Pipeline as the data source. Authentication method is automatically set to OAuth 2.0. Click Edit credentials. The error above appears instead of the expected QuickBooks OAuth consent screen. Expected behavior: Clicking Edit credentials should open the standard Intuit OAuth 2.0 consent screen, as described in the QuickBooks connector documentation for Data Factory / Fabric pipelines. Impact: It is currently impossible to create a working QuickBooks Online connection in a Fabric pipeline using this connector, which blocks migrating an existing pipeline (where tokens are currently passed manually as parameters) to native OAuth authentication. Environment: Microsoft Fabric (trial capacity), browser: Chrome, date: 2026-09-11.
Fabric Pipeline stuck on Loading - pipeline editor does not open
Hi, I am facing an issue with Microsoft Fabric Data Pipelines. The pipeline editor remains stuck on Loading and the activities/canvas never appear. The issue happens in multiple workspaces in the same tenant. I also created a new pipeline in another Fabric trial workspace, but it has the same issue. Lakehouse is working normally, but Pipeline remains stuck on Loading. I have tried refreshing and reopening Fabric and testing in another workspace, but the issue persists. Is anyone else experiencing this issue? Could this be a Fabric service-side issue? I have attached screenshots showing the Loading screen. Thanks
Fabric Data Warehouse best practices for medallion architectures
Part three of a series on medallion architecture with Fabric Data Warehouse. Good medallion architecture is mostly operational discipline. In part one of this series, we chose the pattern, and in part two, we filled in the Bronze, Silver, and Gold layers. Now comes the part that usually determines whether the architecture holds up in production: the operating rules. Many medallion architectures look great on paper but become difficult to maintain as data volumes, business requirements, and consumers grow. A medallion pipeline is easy to explain and easy to demo. It is more challenging to keep clean over time. The challenges usually start small: row-by-row loads, report-specific logic in the wrong place, transformations that cannot be safely rerun, or Gold tables that slowly become another staging layer. Why this matters Most medallion problems are not caused by the names Bronze, Silver, and Gold. They happen because the pipeline stops behaving like a pipeline. Bronze starts cleaning. Silver starts serving dashboards. Gold starts compensating for upstream data quality. Before long, nobody knows where a rule belongs, and every change feels risky. The goal of best practices is not to add ceremony. The goal is to make the pipeline predictable: predictable loads, repeatable transformations, trusted outputs, and clear places to look when something breaks. Best practice 1: Batch the writes Fabric DW is built for set-based work. Treat ingestion and transformations as batches, not as a stream of tiny row-by-row operations. In Bronze, that usually means using COPY INTO, Fabric Pipelines, or other bulk-loading patterns to land data in raw tables. If you are loading from files, aim for fewer well-sized files instead of many tiny ones. When practical, files in the 100 MB to 1 GB range are a healthier starting point than a long tail of small files. In Silver and Gold, the same idea applies: prefer set-based T-SQL transformations, CTAS, INSERT...SELECT, and MERGE patterns over procedural row-at-a-time logic. Do this well Load Bronze in batches, and avoid trickle inserts when the source can be staged first. Add ingestion metadata, such as source file name and load timestamp, so every batch is traceable. Keep operational logging lightweight. If you need very high-write audit events, do not turn the warehouse into a single-row logging engine. Let Bronze preserve the batch; let Silver decide what is valid. Rule of thumb: if a load pattern creates a large number of tiny writes, fix the load pattern before tuning the query. Best practice 2: Make Silver rerunnable Silver is where the pipeline earns trust. That means Silver transformations need to be repeatable, testable, and safe to rerun. If an upstream source reloads, or a cleansing rule changes, you should know how to rebuild the affected Silver tables without guessing which reports need to be patched. This is where idempotent design matters: a transformation should produce the same result when run again against the same inputs. In Fabric DW, use CTAS when you want to materialize a clean table from a query, INSERT...SELECT for controlled incremental loads, and MERGE when late-arriving or changed data needs to update existing Silver rows. Do this well Design transformations so they can run again without duplicating or corrupting data. Use staging tables when the logic is complex. A few clear steps are easier to operate than one unreadable query. Put quality gates in Silver: required fields, valid formats, duplicate handling, and reason codes for rejected records. Choose precise data types and lengths. Silver is the right place to turn loose source data into reliable analytical data. Rule of thumb: if a report needs to clean the data again, Silver did not finish its job. Best practice 3: Shape Gold for consumption Gold is not just “the final table.” Gold is the business-facing serving layer. It should be modeled around how people ask questions, not around how the source systems store data. For some workloads, that means a star schema with fact and dimension tables. For others, it means a data mart, a wide reporting table, or a pre-aggregated summary. The pattern matters less than the principle: Gold should make the common analytical path simple, fast, and trustworthy. This is also where you should be careful not to let Gold become a junk drawer. If Gold is full of one-off fixes, report-specific exceptions, and raw technical fields, the layer is doing too much. Do this well Model the grain explicitly. A fact table without a clear grain becomes hard to explain and harder to debug. Pre-aggregate where the business repeatedly asks the same question. Hide technical fields that helped the pipeline but do not help the consumer. Keep Gold dependent on Silver by default. Direct Gold-to-Bronze dependencies should be rare and deliberate. Rule of thumb: Gold should answer the business question quickly without making the report author rediscover the pipeline. Best practice 4: Use Fabric DW defaults, but do not fight the engine Fabric DW gives you a SQL warehouse over Delta data in OneLake. That means you get transactional behavior, optimized storage patterns, and a managed engine that handles many physical decisions for you. The practical advice: do not bring every habit from traditional data warehousing with you. You do not need to micromanage distribution or indexing the same way you would in older platforms. Focus first on healthy data layout, set-based transformations, good table design, and predictable query patterns. At the same time, do not ignore the basics. Query performance still benefits from clean data types, useful statistics, well-shaped Gold tables, and avoiding unnecessary scans. Do this well Keep V-Order and platform optimizations on unless you have a measured reason to change them. Use the performance guidance for Fabric Data Warehouse before inventing custom tuning patterns. Check query behavior when a Gold table becomes critical to many reports. Treat advanced exceptions as exceptions. Most teams should start with the defaults and tune only when evidence says to tune. Rule of thumb: tune from evidence, not from habit. Best practice 5: Monitor by layer A medallion pipeline should be observable at each layer. If a dashboard is wrong or slow, you should be able to tell whether the issue started in Bronze ingestion, Silver transformation, or Gold serving. In Fabric DW, use Query Insights and the warehouse monitoring views to understand query behavior, expensive operations, and refresh patterns. Pair that with pipeline-level monitoring so you can see not only whether a job failed, but where the failure happened. Measure the pipeline in terms the team can act on: Bronze load duration, Silver transformation duration, rejected-record counts, Gold refresh duration, and Gold query performance. Do this well Track load and refresh duration by layer. Log the number of records received, accepted, rejected, and published. Watch critical Gold queries after refresh, especially the ones that feed executive dashboards or widely used semantic models. Keep operational alerts tied to business impact. A failed Gold refresh matters differently from a delayed Bronze load. Rule of thumb: if you cannot tell which layer failed, your monitoring is not layer-aware enough. Before moving a medallion pipeline into production, use the following checklist to verify that each layer is operating as intended. The best-practice checklist Area Bronze Silver Gold Write pattern Batch ingest with metadata Set-based transformations Scheduled refreshes Quality rule Preserve what arrived Validate, conform, and flag Expose trusted fields only Performance focus Avoid tiny writes Keep logic rerunnable Shape for common queries Takeaway Part two of this series was about one job per layer. Part three is about operating each job like it matters. Batch the writes. Make Silver rerunnable. Shape Gold for consumption. Use Fabric DW’s managed engine instead of fighting it. Monitor the pipeline by layer so failures are easy to locate and fixes happen in the right place. If you follow those rules, your medallion architecture becomes less fragile over time, not more. This post is part of our Medallion Architecture on Fabric Data Warehouse series: Choosing your medallion pattern in Fabric Data Warehouse Building the Bronze → Silver → Gold layers Fabric DW best practices for medallion architectures Securing and governing your layers Performance tuning your medallion pipeline Ready to go deeper? Explore the Microsoft Fabric Data Warehouse performance guidelines and ingestion guidance, then stay tuned for Part four of this series, where we’ll cover securing and governing your layers.A bug in the Data pipeline expression builder
Since last week's Fabric update, the Expression Builder is generating incorrect expressions when selecting pipeline parameters. For example, instead of generating: It writes @linkedService().<parameter_name> instead of @pipeline.parameters.<parameter_name>. The expression is immediately flagged with an "UnsupportedConcept" error. Additionally, the value cannot be saved even after manually correcting the expression to the proper pipeline parameter syntax. The issue occurs with both newly created and existing parameters, suggesting a regression introduced in the latest Fabric update.
Passing a bearer token to copy data action using GET
Hi All, Not a question, but something I ran into, as I am just picking up MS Fabric, pipelines etc. I needed to use web request, to get an access token that is valid for 30 minutes. Next I needed to use that token as a bearer token to do a follow up API call to get actual data , there didn't seem to be that much info around, when I tried to google it. Eventually I found a you tube video, that told me what i needed to know. (linked below). Things like apikeys and other credentials will of course vary on the API yo are trying to use. This is my flow. Step 1 Do your web request Step 2 link the Web and copy data action Step 3 In the copy data action set it up as follows: As you can see the value of the Authorization header is dynamic, with in my case, the following expression: Bearer @{activity('Get access token').output.access_token} The part ".access_token" depends on the json you get returned, in my case it was a very flat structure with no above array. { "token_type": "BearerToken", "issued_at": "xxx", "salesforce_id": "xxx", "access_token": "xxx", "application_name": "xxx", "scope": "refresh_token full", "expires_in": "xxx" } Above you can see where i got the parameter access_token from. If this array had been nested in for instance another array called "data" then the value would have been data.access_token in stead of just access_token. I hope this is usefull info to share here. The video I got this from you can find here . Cheers Hans
Workspace Identity works in one workspace but fails in another when executing Notebook Activity
Hi everyone, I'm troubleshooting an issue with Notebook Activity + Workspace Identity (WI) in Microsoft Fabric Data Factory and would like to know if anyone has experienced something similar. Scenario I'm trying to execute a notebook from a pipeline using a Workspace Identity connection. The notebook itself is very simple and does not require: Lakehouse Environment External connections The execution fails before Spark starts. Notebook Error An unexpected error encountered while preparing spark operation execution. The user access token was not found. The user session may have expired or the user is no longer valid. Please sign in again. Additional observations: In the notebook run history, the "Submitted By" column appears as "--" The notebook never reaches Spark execution Pipeline Error Notebook execution failed at Notebook service with http status code - '200' Failed to create session for executing notebook. Notebook execution is in Failed state. What I have already validated ✅ Workspace Identity exists and is active in Entra ID ✅ Workspace Identity is included in the Security Group allowed to use Fabric APIs ✅ Tenant setting "Service principals can call Fabric public APIs" is enabled ✅ Workspace Identity is Workspace Admin ✅ Workspace Identity is successfully used to access Azure Data Lake Storage Gen2 ✅ Notebook Activity is configured to use a Workspace Identity connection ✅ Notebook owner account is active and valid ✅ Pipeline owner account is active and valid ✅ No Environment attached ✅ No Lakehouse attached ✅ No external connections inside the notebook ✅ Created a brand-new notebook containing only: print("hello") ✅ Created a brand-new pipeline containing only a Notebook Activity Same result. ✅ The same Notebook Connection with Workspace Identity works successfully in another workspace Comparison with another workspace I have another workspace with: The same tenant Different Fabric capacity The same geography Different Security Group The same Fabric API tenant settings The same Notebook Connection owner and the exact same configuration works correctly there. Additionally: The same Notebook Connection was tested in both workspaces The same Workspace Identity pattern is used The working workspace can access Key Vault and execute notebooks through pipelines without issues The only variable that seems to change is the workspace itself. Additional Observation The Workspace Identity appears to be functioning correctly because it is already being used successfully to authenticate against Azure resources such as ADLS Gen2. Because of this, the issue does not appear to be related to Entra permissions, Fabric API permissions, or Workspace Identity access to Azure resources. Instead, it seems related to one of the following: Notebook Activity + Workspace Identity integration Session creation Workspace metadata Workspace-specific configuration Question Has anyone encountered a situation where: Workspace Identity authentication works for ADLS and Key Vault The same Notebook Connection works in another workspace Notebook Activity only fails in one specific workspace The error is related to: "The user access token was not found" "Failed to create session for executing notebook" Empty "Submitted By" field I'm trying to determine whether this is: A workspace-specific metadata issue A Notebook Activity bug A Workspace Identity provisioning issue An undocumented prerequisite for Workspace Identity execution Any insights would be greatly appreciated. Thanks!Materialized Lake View Refresh activity Pipeline bug
Hi all, When using the preview feature refresh mlv activity in the pipeline, is do have some major bugs. After saving, it goes back to default, the pipeline does not want to refresh after, and I cannot parametrize it. Is there any workarround, and is this a known bug? Cause this is not workable.
