Error 8624, Severity 16: Internal Query Processor Error: The query processor could not produce a query plan.

Question

Error 8624, Severity 16: Internal Query Processor Error: The query processor could not produce a query plan.

Mohanraj Selvarasu 20

Hi,

Environrment : SQL Server 2022, build 16.0.4252.3 (CU24 + GDR, May 2026)

We are experiencing an intermittent issue on Microsoft SQL Server 2022 Enterprise Edition running in an Always On Availability Group environment.A specific stored procedure SP_XXXX_NAME executes successfully most of the time (approximately every 15–30 minutes). However, intermittently, the execution results in an internal Query Processor error, and SQL Server generates a dump file.

In most cases, SQL Server continues running after the dump is generated, and the Availability Group remains online. However, on a few occasions, the Availability Group transitions to the secondary replica without the SQL Server service restarting.

The SQL Error Log records the following:

ex_dump_if_requested: Exception raised, major=86, minor=24, state=246, severity=16

followed by:

Internal Query Processor Error:
The query processor could not produce a query plan.
For more information, contact Customer Support Services.

Windows Error Reporting captures:

Fault bucket: INVALID_REQUEST
Event Name: SQLException64

Problem signature:
P1: sqlservr.exe
P2: 0.0.0.0
P3: 0000000000000000
P4: sqllang.dll
P5: 16.0.4252.3
P6: 0000000069EE2EEE
P7: 17068
P8: 00000000003D9476
P9: 00000000C1FA39D3

A SQL dump is generated every time this issue occurs (SQLDumpxxxx.mdmp, SQLDumpxxxx.txt, and SQLDumpxxxx.log).

AG behavior

We have observed the following behavior:

Every occurrence generates a SQL dump.
Most dump events do not trigger an Availability Group failover.
Occasionally, the Availability Group transitions to the secondary replica.
The SQL Server service does not restart during these events (the SQL Server start time remains unchanged).

During the failover scenario, the SQL Error Log contains messages similar to:

Always On: The local replica of availability group '<AG_Name>' is preparing to transition to the resolving role.

The availability group '<AG_Name>' is being asked to stop the lease renewal because the availability group is going offline.

Remote harden of transaction failed.

However, we do not observe explicit lease timeout or HealthCheckTimeout messages in the SQL Server Error Log or Windows Failover Cluster Event Viewer. The cluster logs mainly contain Event IDs 1069 and 1025 during the failover.

Pls suggest whether this is a known issue or defect in SQL Server 2022 (build 16.0.4252.3), particularly within sqllang.dll or the Query Optimizer/Query Processor.

Explain why the same exception sometimes only generates a dump, while in other cases it causes the Availability Group to transition to the secondary replica even though the SQL Server service remains running.

Advise whether there are any available hotfixes, cumulative updates, or recommended workarounds.

Confirm whether this behavior is related to the database compatibility level (currently 120) or a known optimizer issue.

We appreciate your assistance and look forward to your analysis and recommendations.

0 comments

Answer recommended by moderator

Mohanraj Selvarasu 20

Hi,

Microsoft has confirmed that this is a product bug affecting SQL Server 2022. However, the permanent fix and corresponding build/release have not yet been made available by Microsoft.

As a workaround, Microsoft recommended enabling Trace Flag 9265 to suppress dump generation and prevent AG failover issues. Since enabling this trace flag, we have not experienced any AG failovers or dump generation events. However, the Error 8624 continue to occur on the server.

We are currently awaiting a permanent fix from Microsoft to fully resolve this issue and eliminate the recurring Error 8624 occurrences.

0 comments

1 additional answer

Your answer

Answer 1

Erland Sommarskog 137.7K MVP Volunteer Moderator

I would guess the reason that you sometimes get a failover and sometimes not is due to some timing issue. Sometimes, the error triggers the monitoring, and sometimes not. Maybe because if the errors occur close enough to each other, the cluster thinks the replica is not healthy and decides to fail over. To address this, you could change the FAILURE_CONDITION_LEVEL for the AG. The default level is 3, for which the documentation says (emphasis mine):

Specifies that an automatic failover should be initiated on critical SQL Server internal errors, such as orphaned spinlocks, serious write-access violations, or too much dumping.

However, I would not recommend taking this step. Rather, you need to work with the root cause, which is the failing query. It is interesting that the procedure sometimes succeeds, and sometimes fails with this error. Normally, when you get this error, you get it constantly. However, if the problematic query has OPTION (RECOMPILE) or the procedure is constructing dynamic SQL, there is compilation every time and depending on the values, a plan may or may not be possible to construct. It is not uncommon that this due to that hints that have been added to the query.

So what you need to do is to track down exactly what query/queries that are failing. Once you know the query, you can try to get an understanding of why the compilation fails and from this make the required changes.

Mohanraj Selvarasu 20 Reputation points

2026-07-05T17:14:02.44+00:00

@Erland Sommarskog Thanks for your valuable time and suggestions.

I have already captured the execution parameters of the stored procedure that is consistently associated with this issue using Extended Events. I tested the same stored procedure in our pre-production environment with multiple parameter variations and a configuration matching Production (including the same compatibility level), but I was unable to reproduce the issue.

I also reviewed Query Store. Each statement within the stored procedure has only a single Plan ID, so there is no evidence of plan regression or multiple cached plans. However, the stored procedure appears in both the Regressed Queries and Top Resource Consumers reports due to its execution characteristics.

Another observation is that, during some dump generation events, the SQL Server engine becomes temporarily unresponsive for a few seconds, even though no Availability Group failover occurs. During this period, application connections to the AG database fail briefly, after which SQL Server recovers automatically.

In the failover scenarios, the SQL Error Log shows that the Availability Group is asked to stop lease renewal because the availability group is going offline, followed by the replica transitioning to the RESOLVING state. However, I do not see explicit lease timeout or HealthCheckTimeout messages in the SQL Server Error Log or Windows Failover Cluster logs.

Since the issue is intermittent, has persisted for several months, cannot be reproduced in UAT, and consistently generates an Internal Query Processor Error (8624) with a dump in sqllang.dll, I suspect this may be an internal SQL Server engine or Query Optimizer issue rather than a stored procedure coding problem.

Could you please advise if this behavior matches any known SQL Server 2022 issues or whether additional diagnostics should be collected to determine why the SQL engine occasionally becomes temporarily unresponsive and, in some cases, causes the Availability Group to transition offline?
Erland Sommarskog 137.7K Reputation points MVP Volunteer Moderator

2026-07-05T17:36:31.4633333+00:00

Would it be OK for you to share the code of the stored procedure? I guess not, but I could at least ask.

Not that I believe that seeing the code would make it is possible for me to say "this is the issue!", but at least I would be able rule out a few things.

Overall, I feel that there are so many unknowns here that it makes it difficult to say something useful without access to the environment. I could make speculations, but I am not sure they would be helpful.

Maybe the best is to open a support case, as with a support engineer you can share a lot more data than you can share in a public forum.

I suspect this may be an internal SQL Server engine or Query Optimizer issue rather than a stored procedure coding problem.

Certainly, one possible reason for error 8624 is that there is a bug in the optimizer, triggered by some query pattern. Still strange that it would appear intermittently. Unless there is some dynamic SQL in the mix, that is.
Erland Sommarskog 137.7K Reputation points MVP Volunteer Moderator

2026-07-05T18:34:07.3933333+00:00

By the way, you say that you were unable to reproduce the issue in UAT. Do you have the same data in UAT? Best for such investigations is that UAT has a copy of production, but this is not always possible.
Mohanraj Selvarasu 20 Reputation points

2026-07-06T06:13:22.8466667+00:00

Hi @Erland Sommarskog Thanks again!

Yes, the stored procedure contains three dynamic SQL queries, and I suspect this may be related to a SQL Server 2022 Query Optimizer/Query Processor issue rather than a stored procedure coding issue.

Therefore, I have raised a Microsoft Support case to investigate the issue in detail. Once Microsoft completes the dump analysis and provides their findings or a recommended solution, I will share the update with you.

Thank you for your valuable time and feedback.
Erland Sommarskog 137.7K Reputation points MVP Volunteer Moderator

2026-07-06T09:40:33.55+00:00

Yes, the stored procedure contains three dynamic SQL queries, and I suspect this may be related to a SQL Server 2022 Query Optimizer/Query Processor issue rather than a stored procedure coding issue.

Then from my perspective it is not that strange that the behaviour is transient. Depending how that dynamic SQL is generated, the optimizer may or may not be able to produce a plan. As for why the optimizer cannot produce a plan, it may be a bug/limitation in the optimizer. But it may also be that the developers have been too smart for their own good and added hints that do not work with the query they have generated. The fact that it does not appear in UAT could be because data there is different, and queries therefore are generated in a different way.

As I said earlier, you would need to track down the exact statements that fail, and my guess it is one of these dynamic SQL statements that fail. A way to do this is to set up an extended-events session that captures the event error_reported. I have an article about this on my web site, https://www.sommarskog.se/Short%20Stories/trace-exceptions.html, where I show how to do this and I also present a view and a stored procedure to easily analyse the data.

If you also add some logging to the procedure to log all generated statements, you can see which statements that succeed and which fails.

Good call to open a support case! Microsoft support can analyse those dumps since they have access to the source code, which is something no one here can help with. The logging and monitoring I suggested that might still be helpful.

Please keep us updated about the outcome!
Erland Sommarskog 137.7K Reputation points MVP Volunteer Moderator

2026-09-24T21:14:58.95+00:00

Thanks for the update! I will convert your comment and recommend this as the Answer. (You cannot accept your own posts as the answer.)
Maraiah Kasetti (Wipro Limited) 85 Reputation points Microsoft External Staff Moderator

2026-09-25T09:22:36.8666667+00:00

Hello @Mohanraj Selvarasu ,

Welcome to the Microsoft Q&A Platform! Thank you for asking your question here.
Thank you for confirming that the community solution resolved your issue. If you need any further assistance, please feel free to reach out to the support team. We will be happy to help.