December 18, 2025 at 3:47 pm
Environment:
SQL Server: 2019 Enterprise (15.0.4430.1)
OS: Windows Server 2022 Standard (Build 20348)
Virtualization: QEMU/KVM (Standard PC Q35 + ICH9)
Security: Bitdefender GravityZone
Authentication: Active Directory Domain Account
The Problem: I am experiencing a recurring issue where SQL Server intermittently stops responding to queries. The service remains in a "Running" state, but all new and existing connections hang. A service restart usually temporarily resolves the issue.
Error Logs: Just before the freeze, the SQL Error Log is flooded with the following errors:
Error: 18456, Severity: 14, State: 23. - Reason: Access to server validation failed while revalidating the login on the connection.
Error: 18056, Severity: 20, State: 23. - The client was unable to reuse a session with SPID X, which had been reset for connection pooling.
This happens mainly with a specific domain service account.
Secondary Symptom: On some reboots, the MSSQLSERVER service fails to start with the error: "Logon failure: the user has not been granted the requested logon type at this computer" (missing "Log on as a service" right). However, this right is assigned via local policy and no GPOs seem to be stripping it. Re-entering the password in services.msc fixes it temporarily.
What I’ve Checked:
DC Connectivity: nltest /sc_query and dsgetdc return success. Kerberos tickets (klist) appear valid.
Virtualization: Recently reinstalled QEMU Guest Agent and drivers. It stabilized the "Log on as a service" right briefly, but the "State 23" freezes persist.
Connection Pooling: The errors suggest a failure during the revalidation of pooled connections against LSASS/Domain Controller.
Question: Has anyone seen Bitdefender ATC/Exploit Defense or QEMU Guest Agent drivers interfering with LSASS in a way that breaks SQL Server's ability to revalidate domain logins? Are there specific "State 23" triggers in Windows Server 2022 that I should be aware of?
December 19, 2025 at 3:41 pm
What is the account being used to run SQL on the server. If it is the same SVC account then I'd check to see if there are any places where the password has been hardcoded that is incorrect / invalid.
Personally I avoid using the SQL server SVC account for anything else other than running SQL and use a different SVC account for separate processes.
December 19, 2025 at 3:51 pm
Posted on X and go this:
"Initial thoughts without any googleing, is that it could be a long process using a transaction that got deadlock killed mid-flight but not being caught in an error catch block
Basically a procedure that's doing 5 things instead of one where one fails, but the process is continuing not knowing that it is already dead."
January 9, 2026 at 3:47 pm
What could be interesting to see is the entries in the log prior to the error 18456 and 18056 entries.
And I know you said that no GPO's were messing with the account, but might not hurt to run "gpupdate /force" on the machine when logged in as the service account (so the user GPO's for that account get applied) and see if the service will restart successfully or complains about access. If a gpupdate breaks the account, you have a GPO that needs fixing.
If you don't want to do that, you can pick any service you know is safe to restart during uptime (maybe the SQL agent service if you can pick a time when a task isn't scheduled) and restart that one after running the GPUPDATE /force assuming it is the same account as the SQL instance. But I'd work on fixing symptom 2 before symptom 1 as they MAY be related.
Might not hurt to also review the Windows logs (application, security, and system) around the time those errors are popping up to see if anything strange is happening that MAY not be related to SQL but could cause issues on the system (network issues, memory contention, etc.).
The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.
Viewing 4 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply