SQL SERVER – Database Mirroring Login Attempt Failed With Error: ‘Connection Handshake Failed. An OS Call Failed: (80090350)

A client’s availability group showed its secondary replica as disconnected, and the log file on the primary was growing. The error, a connection handshake failure, blamed database mirroring, which they were not using. A reboot of the secondary fixed it. That was the right move on the day, but it is worth knowing what actually broke, so you can check it before reaching for the restart.

The Error

Database Mirroring login attempt failed with error: 'Connection handshake failed.
An OS call failed: (80090350) 0x80090350(The system cannot contact a domain
controller to service the authentication request. Please try again later.).
State 66.'. [SERVER: <primary address>]

Why It Says Mirroring

Availability groups did not get their own transport. They reuse the database mirroring endpoint, the same one that mirroring sessions use. So every connection problem between replicas is logged as a “Database Mirroring login attempt”, even when nobody has set up mirroring. Look at the endpoints on a replica:

SELECT e.name, e.state_desc, t.port, e.role_desc, e.connection_auth_desc
FROM   sys.database_mirroring_endpoints AS e
JOIN   sys.tcp_endpoints AS t ON t.endpoint_id = e.endpoint_id;

On an availability group replica you will find an endpoint there, often named Hadr_endpoint. It is listed as a database mirroring endpoint, because that is what it is. The word mirroring in the error is not a clue about your setup. It is just the name of the door.

What 0x80090350 Means

The code comes from Windows security, not from SQL Server. I asked Windows to translate it:

(New-Object ComponentModel.Win32Exception([int]0x80090350)).Message

The system cannot contact a domain controller to service the authentication
request. Please try again later.

The same words that SQL Server printed. The replicas log in to each other with their service accounts, and to accept a login the receiving server has to check it with a domain controller. The secondary could not reach one. So it refused every login from the primary, and from the primary’s side the secondary simply looked disconnected.

Why the Log File Grew

This is the part that turns an authentication glitch into a disk problem. The primary keeps every log record that a secondary has not yet received, so it can send them later. While the secondary was unreachable, nothing could be sent, so nothing could be cleared, and the log grew.

You can see this directly:

SELECT name, log_reuse_wait_desc
FROM   sys.databases
WHERE  name = 'YourAGDatabase';

AVAILABILITY_REPLICA means exactly this: the log is being held for a replica. It clears on its own once the replica catches up. Do not shrink the log while it says that, because the space is genuinely needed.

What My Client Checked, and What I Would Add

We could log in to the secondary with Windows accounts, and we could ping the domain controller. Both looked fine. They told me there had been network problems, which their network team had since fixed. Rebooting the secondary brought the replicas back together, and it was safe to do because it was the secondary.

A reboot works because it rebuilds the machine’s connection to the domain from scratch. What it hides is whether that connection was the problem. Before restarting, I would now check the machine’s secure channel to the domain:

nltest /sc_verify:MYDOMAIN

A ping only proves the network path exists. A secure channel check proves the machine can actually authenticate against the domain, which is the thing the error is complaining about. If it fails, the fix is on the Windows side, and knowing that stops it happening again next month.

I could not run that check here, because my test machine is not joined to a domain. I ran the endpoint query on SQL Server 2025 and the error translation in PowerShell.

Worth Watching For

After any network work near your domain controllers, look at the availability group dashboard, not just at the applications. A replica can be quietly disconnected while every application carries on writing to the primary, and the first symptom you notice is a full log drive.

0x80090350 is not a mirroring problem, it is a server that could not reach anyone to vouch for its partner.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.