Access violation and dump files when querying sys.dm_exec_requests during database recovery - SQL Server 2026 updates known issue and trace flag 4696

#Symptom

Right after a service restart or an AG failover:

• A new stack dump appears in the SQL Server Log folder, with an access violation.
• The error log shows the exception around the time a query against sys.dm_exec_requests ran.
• It often coincides with your monitoring tool's polling interval.

#Cause

Microsoft's known-issue text (SQL Server 2025 CU9 / KB5126967, and the September 2026 updates):

Queries against sys.dm_exec_requests might raise an access violation and generate a dump file

when run while a database is in recovery. The cause is "a change that causes internal in-memory structures to be referenced before they're fully initialized." Microsoft says it's investigating a fix.

Recovery happens after every restart, on AG secondaries becoming primary, and on database restore. So in an AG environment, every failover is a chance to hit it.

#Your three options

Microsoft lists these mitigations:

#1. Trace flag 4696

"Enable trace flag 4696 to opt out of the code change that causes this issue."

Side effect: monitoring queries on secondary replicas may return error 976 or 978 again, as they did before the update. Those are the errors about accessing a database on a non-readable or not-yet-available secondary.

Enable it at startup so it survives restarts (recovery happens at startup, so a runtime DBCC TRACEON after a restart is too late for that restart):

• Windows: SQL Server Configuration Manager > SQL Server Services > the instance > Properties > Startup Parameters > add -T4696, then restart in a maintenance window.
• Linux: sudo /opt/mssql/bin/mssql-conf traceflag 4696 on, then sudo systemctl restart mssql-server.
• AGs: set it on every replica, so it's in place whichever one becomes primary.

For immediate effect until the next restart:

DBCC TRACEON (4696, -1);
DBCC TRACESTATUS (4696);

Make sure your monitoring handles 976/978 gracefully on secondaries (treat them as "not readable", not as alerts).

#2. Avoid querying recovering databases

If you control the monitoring queries, skip databases that aren't online:

SELECT r.session_id, r.status, r.command, r.wait_type, DB_NAME(r.database_id) AS db
FROM sys.dm_exec_requests r
JOIN sys.databases d ON d.database_id = r.database_id
WHERE d.state_desc = 'ONLINE';

Note this filter still reads sys.dm_exec_requests. A more reliable approach is to have the monitoring job check first whether any database is in RECOVERING state, and skip the DMV poll entirely until all are online:

IF NOT EXISTS (SELECT 1 FROM sys.databases WHERE state_desc IN ('RECOVERING','RECOVERY_PENDING'))
BEGIN
    SELECT session_id, status, command, wait_type FROM sys.dm_exec_requests;
END

For third-party monitoring tools, ask the vendor whether they have a setting for this, or pause collection during planned failovers.

#3. Uninstall the update

Microsoft lists it as an option. It removes the security fixes too, so use it only if the dumps are causing real instability and options 1 and 2 aren't possible.

#Is it harmful?

An access violation in a DMV query usually kills that query and writes a dump, rather than stopping the instance. But dumps take disk space and time, and repeated dumps during a failover window add noise when you least want it. Watch free space on the log drive.

#Checklist

• Dumps matched to sys.dm_exec_requests queries during recovery
• Mitigation chosen: TF 4696 (startup), skip-during-recovery logic, or uninstall
• Monitoring handles errors 976/978 on secondaries if TF 4696 is used
• Planned failovers include pausing DMV-heavy monitoring
• Watching the KB for Microsoft's fix, then removing the workaround

#Sources

• KB5126967 - SQL Server 2025 CU9 known issues