SEC_E_CANNOT_PACK (0x80090309) — fix for SSPI logon buffer marshal failure

Quick answer

klist purge in an admin command prompt, then reboot. 90% of the time that's it.

Why this happens

What's actually happening here is that the Windows Security Support Provider Interface (SSPI) is trying to marshal your logon credentials into a buffer for authentication — usually against a domain, a network share, or a remote desktop session — and something in that chain fails. The error text says it can't pack the buffer. The real reason is almost always a corrupted Kerberos ticket in your session's ticket cache, or a network adapter configuration that confuses the security package negotiation.

I've seen this most often when you're on a domain-joined machine trying to access a network resource via RunAs or Enter-PSSession, or when using Remote Desktop to a server that's on a different domain trust. Another common trigger: you just changed your domain password, but the cached ticket still has the old hash. The system tries to pack that stale ticket, fails, and throws 0x80090309.

Less common but real: your network adapter has IPv6 enabled and your DNS doesn't properly handle IPv6 records, causing Kerberos to time out during the marshal attempt. Or the MSSQL$ service account context gets tripped up — I've debugged this exact error on SQL Server linked server queries using Windows Auth.

Step-by-step fixes

1. Clear Kerberos tickets — Open an admin command prompt and run klist purge. This flushes all cached tickets. Then reboot. On reboot, Windows re-authenticates with the domain controller fresh. This is the fix, not a workaround.
2. Disable IPv6 on the network adapter — If step 1 didn't stick, go to Control Panel > Network and Sharing Center > Change adapter settings. Right-click your active adapter, go to Properties, uncheck Internet Protocol Version 6 (TCP/IPv6). Reboot. What's happening here is that your DNS returns an AAAA record for the target server, but your network path or firewall drops IPv6 traffic. Kerberos tries to use IPv6 for the ticket exchange, times out, and the marshal fails. Disabling IPv6 forces IPv4-only, which usually works.
3. Check time sync — Run w32tm /query /status. If your clock is more than 5 minutes off from the domain controller, Kerberos tickets won't validate. Fix with w32tm /resync and reboot.
4. Reset Winsock and TCP/IP stack — In admin command prompt, run netsh int ip reset followed by netsh winsock reset. Reboot. This clears any corrupted socket state that might interfere with SSPI marshaling.

If those don't work

Try these less common fixes:

• Rejoin the domain — Remove the machine from the domain, reboot, rejoin. This rebuilds the machine account's Kerberos trust. Only do this if you're absolutely sure step 1 and 2 didn't help — it's disruptive.
• Check for third-party LSA plugins — Some security software (like older Symantec Endpoint Protection or McAfee) installs LSA notification packages that interfere with SSPI. Check HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Notification Packages — if you see a non-Microsoft DLL there, that's your culprit.
• Use NTLM fallback — If this is for a specific application (like SQL Server), you can force NTLM instead of Kerberos by configuring the SPN or using net use with explicit credentials. Not ideal, but gets you working.

Prevention tip

Keep your system clock synced to the domain controller via w32tm /config /syncfromflags:domhier /update. And if you regularly use RunAs with different credentials, make a habit of running klist purge before those login attempts — it stops stale tickets from building up.