Fix 0X80010132 LookupAccountName Failed (CO_E_LOOKUPACCNAMEFAILED)

What the heck is 0X80010132?

CO_E_LOOKUPACCNAMEFAILED means Windows called the LookupAccountName function and it came back empty. That function translates a security identifier (SID) into a readable account name — like DOMAIN\jsmith. When it fails, you get this error. It's a common headache in Outlook, Office apps, and sometimes during Windows updates.

The culprit is almost always a broken registry reference or a corrupted user profile. Sometimes it's a leftover SID from a domain that no longer exists. I've seen it pop up on domain-joined machines after a user is removed from AD but their SID lingers in the local profile.

Let's walk through the fix. Start with step one — it takes 30 seconds and sometimes that's all you need.

Step 1: The 30-Second Registry Check

This is the quickest fix. The error often traces back to a bad value in the ProfileList registry key. If a profile entry points to a nonexistent user, LookupAccountName chokes.

Press Win + R, type regedit, hit Enter.

Go to:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

Look for keys starting with S-1-5-21. Each one is a user profile. Click through them and check the ProfileImagePath value.
If you see a path that points to a user that doesn't exist on the machine (like C:\Users\OldUser), that's your suspect. Delete that entire key — but only if you're sure the user is gone. Right-click the key, Delete.

Reboot. Try whatever was failing. If the error's gone, you're done. If not, move on.

Back up the registry before you delete anything. Export the key first. It takes five seconds and saves you from a bricked system.

Step 2: The 5-Minute Permission Repair

If the registry was clean, the problem is probably a broken permission set on a file or folder — usually in C:\Users\Public or a shared directory. This happens when a folder was created by an old account and the ACL still references a SID that no longer resolves.

Open an elevated Command Prompt (right-click CMD, Run as administrator).
Run this command to reset permissions on the Public folder:
```
icacls C:\Users\Public /reset /t /c /q
```
This resets all inherited permissions. It won't hurt anything, but it might take a minute.
If your issue is in a specific folder (like a shared drive or an Outlook data file), run:
```
icacls "C:\path\to\your\folder" /reset /t /c /q
```

Still failing? Next, check if the user profile itself is corrupt. In Settings > Accounts > Your info, see if your account name shows as something odd like Unknown account. If yes, that's a dead giveaway. You'll need to rebuild the profile.

Rebuilding a profile is annoying but reliable. Create a new local admin account, log in with it, and move your files over. Then delete the old profile from System Properties > User Profiles. This takes a while but it's a sure fix.

Step 3: The 15+ Minute Clean Boot and SFC Deep Dive

If you're still here, something systemic is wrong. Maybe a third-party service is interfering with SID resolution, or a system file is corrupted. Let's do a clean boot first.

Press Win + R, type msconfig, hit Enter.
On the Services tab, check Hide all Microsoft services, then click Disable all.
On the Startup tab, click Open Task Manager, disable all startup items, then close.
Click OK, restart. Once in clean boot, test if the error appears.

If the error's gone, something you disabled is the trigger. Re-enable services in batches until it comes back — then you've got your culprit. Most of the time it's an antivirus or a VPN client messing with token lookups.

If the error persists even in clean boot, run the System File Checker:

sfc /scannow

That takes 10-15 minutes. If it finds corrupted files, it'll repair them. After that, also run DISM to fix the component store:

DISM /Online /Cleanup-Image /RestoreHealth

Reboot after both. That's the nuclear option, and it's fixed more than a few stubborn 0X80010132 cases for me.

Why does this happen in the first place?

Real-world trigger: you've joined a domain, worked for a while, then the domain controller is retired or the user account is deleted. Your local profile still has the old SID stored in the registry. When an app tries to enumerate permissions, Windows tries to translate that SID to a name, fails, and throws 0X80010132. It's more common in Outlook when you have delegate access to a mailbox that belonged to a removed user.

Another trigger: a bad Windows update. I've seen the error after cumulative updates on Windows 10 21H2 and 22H2. If you've recently patched, and the error started after, the SFC/DISM route is more likely to help.

What to skip

Don't bother with third-party registry cleaners — they do more harm than good. And don't just reinstall Office unless you've confirmed it's Office-specific. The error is at the OS level, not the app level.

If you're in a domain environment, check with your admin to make sure the user object still exists in AD. A simple net user username /domain from an elevated prompt will tell you. If the user is missing, that's your root cause, and the fix is to create a new profile.

That's the whole playbook. Start with the registry, move to permissions, then go full clean boot. Nine times out of ten, the registry key was the culprit. Good luck.