SQL Server CDC Mirroring – Internal System Error on Init/Resync

[DSZ]

Error: Internal system error occurred. ArtifactId: d89e76f1-6201-4637-94d4-536a653155ae, SequenceNumber: 7

Environment

• Source: Microsoft SQL Server 2016
• CDC: Enabled and verified on both database and table level
• Gateway: On-premises Data Gateway (online, verified)
• All source-side prerequisites confirmed: Primary Keys present, CDC capturing changes correctly, SQL Server Agent running

Symptoms

Two separate scenarios both result in the same Internal System Error:

Scenario 1 – Creating a new mirror:

1. Create a new SQL Server CDC mirrored database in Fabric
2. Add a table that has CDC enabled on the source
3. Mirroring fails immediately with the Internal System Error — the table never initializes

Scenario 2 – Stop and restart an existing, healthy mirror:

1. Take an existing mirror that is running correctly
2. Stop mirroring and start it again
3. All tables fail with the Internal System Error — none of them recover

Source-Side Verification

We have thoroughly tested the source SQL Server and everything works as expected:

• CDC is enabled at both database and table level
• INSERT and UPDATE operations are correctly captured by CDC
• cdc.fn_cdc_get_all_changes_* returns changes as expected
• DBCC CHECKDB reports no issues
• No unsupported data types (text, ntext, image, etc.)
• No DDL changes since CDC was enabled

The source side is healthy. The issue appears to be entirely on the Fabric platform side.

Impact

This is effectively blocking us from:

• Creating any new CDC mirrors
• Recovering or reseeding any existing mirrors

Our current workaround is to leave the existing running mirrors untouched and not stop/start them, as doing so triggers the error. This is not sustainable. For our team this is a P1 severity issue as we cannot initialize or recover any mirrored databases.

Questions for the Community / Microsoft

1. Is anyone else experiencing this right now? This feels like a recent platform-side regression.
2. Is there a known incident or degradation on the Fabric Mirroring service?
3. Is there any workaround to force a clean re-initialization without triggering this error?
4. Should this be escalated directly to Microsoft Support with the ArtifactId?

Any help or confirmation from others experiencing the same issue would be greatly appreciated. Thank you.

[DSZ]

I profiled the activity on the MSSQL side to understand what Fabric is sending. It appears that the pool script has changed and is now using DMVs or system tables that require elevated permissions.

On our side, we have adjusted the configuration to avoid granting sysadmin, as this led to unintended side effects. In particular, it caused automatic addition of tables to the source that should not have been included.

This is the right which one resolved this issue. The problen has been discussed with microsoft also 
VIEW SERVER STATE

[V-yubandi-msft]

Thank you for confirming the fix and sharing the details. It's useful to know that granting VIEW SERVER STATE resolved the issue.

Your feedback will help others avoid similar problems. Thanks for sharing the solution with the community.

[V-yubandi-msft]

Hi @DSZ ,

Thank you for the update. If you receive any response or update from the Microsoft team regarding this issue, please consider sharing it here. It may be helpful for other community members who are experiencing the same problem.

Thanks.

[DSZ]

Some information :

I figured out what is the problem. The last 2 weeks probably microsoft had a release and changed the way of work probably because the mirror +cdf feature. If I elevate to sysadmin or db_owner the rights starts snapshot. This is horrible idea. In fabric should't have any write administrative rights to force to read data this is nosense. This is super dangerous.I rised a ticket to the support and the investigation has been started.

[V-yubandi-msft]

Thanks for sharing the details and confirming you’ve already contacted Microsoft Support. If you get any updates or guidance from them, please share here it will help other members who may be facing the same error.

[Shai_Karmani]

Hey, quick thoughts.

No active Fabric outage showing as of yesterday, so it's probably not a declared platform incident, though a targeted Mirroring regression isn't fully ruled out.

The first thing I'd check: Microsoft changed varchar handling on Nov 18, 2025. Tables created before that only support varchar(8000), and on restart a mirror may try to re-init under the new rules and choke. That fits your weird pattern. Running mirrors are fine, but stop/start blows up. Mirrored SQL Server also caps at 1 MB per column.

Second, check the tenant setting "Users can access data stored in OneLake with apps external to Fabric." If that got flipped off, the replicator can't reach replicating status and every table fails at once, which matches your Scenario 2.

Also worth confirming your SQL 2016 build is on a supported CU, since version-level support has tightened.

Then escalate to MS Support with the ArtifactId, mirror URL, failing table, and timestamp. Pull the Eventstream and monitoring logs first so you know whether it's failing at the replicator or a specific table.

Honest take: I can't say for certain which one it is. The varchar cutoff and the tenant setting are my best guesses because they explain "healthy until restarted" better than anything source-side, and you've already cleared the source side.
But the logs plus the ArtifactId are what will give you the real answer.

If this works for you, kindly mark it as the solution and give a thumbs up.

Best,
Shai Karmani

Let's connect in LinkedIn

[DSZ]

Thank you for your response. The migration was configured last month, so there should not be anything unsupported. At the moment, I am working with a single table as a test.

The setting “Users can access data stored in OneLake with apps external to Fabric” is enabled at the tenant level.

We have started escalating the issue to Microsoft.