Fix SEC_I_COMPLETE_AND_CONTINUE 0x00090314 on Windows

Quick answer: This isn't an error you need to fix—it's an informational status code that means the TLS handshake isn't finished yet. If your app or browser hangs with it, check your Schannel registry settings or update TLS 1.2 support.

What the heck is SEC_I_COMPLETE_AND_CONTINUE?

I remember the first time I saw this in a Windows 7 event log back in 2012. Thought the machine was dying. Turns out it's just Schannel—Windows' security provider—telling the application: "Hold on, I need more data from the remote server before I can finish the handshake."

This code (0x00090314) pops up when an app uses SSPI (Security Support Provider Interface) for TLS. You'll see it in logs from Internet Explorer, Edge, Outlook, or even SQL Server Management Studio. It's not a crash. But when the handshake never completes, you get a timeout or a weird "The message received was unexpected or badly formatted" error.

Most of the time, the root cause is one of three things:
- The remote server requires TLS 1.2 but your system only has TLS 1.0 enabled.
- The server demands a client certificate and your client doesn't have one.
- A misconfigured proxy or antivirus is interfering with the TLS negotiation.

How to fix this (in 2 minutes)

Enable TLS 1.2 system-wide. Open Registry Editor (regedit), go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client. Create a DWORD (32-bit) named DisabledByDefault and set it to 0. If the TLS 1.2 folder doesn't exist, create it.
```
Windows Registry Editor Version 5.00 

 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client] 
 "DisabledByDefault"=dword:00000000 
 "Enabled"=dword:ffffffff 
```
Reboot after this.
Check your date and time. If your system clock is off by more than a few minutes, certificate validation fails. Sync with time.windows.com.
Disable antivirus SSL scanning temporarily. I've seen Norton, McAfee, and even Windows Defender's network inspection block the handshake. Turn off real-time protection for 30 seconds and test again.
Update Windows and .NET Framework. Older versions of .NET (3.5, 4.0) don't support TLS 1.2 by default. Install KB update 3140245 for .NET 4.6 and higher.

Alternative fix if the first one doesn't work

If you're still seeing this in a custom app or PowerShell script, force the TLS version in code. For .NET apps, add this at the start of your script:

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

For SQL Server, make sure your connection string includes TrustServerCertificate=True if you're using a self-signed cert on the server.

If the error appears in Outlook connecting to Exchange, check if your email server requires a client certificate. Ask your admin to issue one or change the server setting to accept anonymous connections.

How to prevent this from happening again

Once you've enabled TLS 1.2 and updated everything, this code becomes a ghost—it'll still appear in logs but won't cause trouble. The real prevention is keeping Windows Update current. Microsoft rolls out Schannel improvements regularly. Also, if you manage multiple machines, push the TLS 1.2 registry keys via Group Policy.

One last thing: If you see SEC_I_COMPLETE_AND_CONTINUE followed by SEC_E_INCOMPLETE_MESSAGE (0x80090326), that's a different beast—usually means the remote server sent a broken packet. That's when you need to check firewall rules or the server's certificate chain.

Hope that saves you the hour of digging I wasted back in 2012.