STATUS_NO_SUCH_PACKAGE (0XC00000FE) – Authentication Package Unknown

Cause #1: Corrupted Kerberos or NTLM Registry Entries

What's actually happening here is that the Local Security Authority (LSA) can't find the DLL for the Kerberos or NTLM authentication package. When Windows boots and tries to initialize security packages, it reads the Authentication Packages value under HKLM\SYSTEM\CurrentControlSet\Control\Lsa. If those entries point to a missing or corrupted file—like after a failed Windows Update, antivirus cleaning, or manual registry editing—you get 0XC00000FE.

This shows up right at logon, sometimes even before you enter a password. You'll see a black screen or a message box saying "A specified authentication package is unknown." On domain-joined machines, it's often Kerberos that's broken. On workgroup systems, it's usually NTLM.

Fix: Restore the Authentication Packages Registry Values

1. Boot from Windows installation media or a recovery drive. You can't fix this from inside the broken OS because you can't log on.
2. Press Shift + F10 at the setup screen to open a command prompt.
3. Run regedit and select the HKEY_LOCAL_MACHINE hive. Go to File > Load Hive and load the C:\Windows\System32\config\SYSTEM file from your broken installation. Give it a temporary name like BrokenSys.
4. Navigate to BrokenSys\ControlSet001\Control\Lsa. Look at the Authentication Packages multi-string value. You should see msv1_0 as the first entry. Some systems also have kerberos after it. If the entry is empty, missing, or has garbage like msv1_0.dll (with the extension—it shouldn't have one), that's your problem.
5. Set Authentication Packages to exactly this, one entry per line:

   msv1_0

   If you're on a domain-joined system, add kerberos on a second line. Also check Security Packages in the same key—it should contain just negoexts.
6. Unload the hive: select BrokenSys, then File > Unload Hive.
7. Reboot normally.

The reason step 3 works is that you're bypassing the broken OS's security stack entirely. The registry hive is just a file at that point. Loading it into a running regedit instance lets you edit it as raw data.

Cause #2: Missing or Corrupted Security Package DLLs

Sometimes the registry entries are fine, but the actual DLLs—msv1_0.dll, kerberos.dll, or negoexts.dll—are missing or damaged. This happens more often than you'd think after antivirus tools quarantine a "suspicious" system file, or after a botched hotfix uninstall.

The error is identical: 0XC00000FE. But the registry looks correct. You need to verify the files exist and are signed.

Fix: Replace Missing DLLs from a Known-Good System

1. Boot from Windows installation media again.
2. Open command prompt with Shift + F10.
3. Run sfc /scannow /offbootdir=C:\ /offwindir=C:\Windows. Replace C: with your actual system drive letter.
4. If SFC can't fix it, manually copy these DLLs from a matching Windows version (same build number, same architecture):

   copy D:\Windows\System32\msv1_0.dll C:\Windows\System32\msv1_0.dll
   copy D:\Windows\System32\kerberos.dll C:\Windows\System32\kerberos.dll
   copy D:\Windows\System32\negoexts.dll C:\Windows\System32\negoexts.dll

   Where D: is the drive with the good Windows installation.
5. Also check C:\Windows\SysWOW64 if you're on a 64-bit system copy the 32-bit versions too.

Don't skip checking the SysWOW64 folder. The 32-bit LSA process uses those on 64-bit Windows, and missing 32-bit DLLs cause the exact same error on logon.

Cause #3: Third-Party Security Software Interference

Some enterprise endpoint protection—Symantec Endpoint Protection, McAfee, or even older versions of Malwarebytes—registers its own authentication packages in the registry. If that software is partially uninstalled or its DLL is removed before the registry entry is cleaned up, Windows tries to load a package that no longer exists.

This one's sneaky because the registry will have an extra entry like symantec_ips or mcafee_mpf in the Authentication Packages list, alongside the standard ones.

Fix: Remove Orphaned Third-Party Entries

1. Boot from recovery media, load the SYSTEM hive as described in Cause #1.
2. Navigate to the Lsa key. Look for any entry in Authentication Packages or Security Packages that doesn't correspond to a known Windows DLL.
3. Delete those entries. Keep only msv1_0 and optionally kerberos.
4. Unload the hive and reboot.

The fix is the same as Cause #1, but the root cause is different. You're not restoring a corrupted entry—you're removing a dangling reference. The error goes away as soon as Windows no longer tries to load a nonexistent DLL.

Quick-Reference Summary

All three fixes require booting from external media because you can't log in to fix it from inside the broken OS. Keep a Windows USB stick handy—it's the only way out of this one.