Fix 0x0000089F: Logoff Processor NERR_UnableToDelName_F

What 0x0000089F Actually Means

0x0000089F is decimal 2207 in hex, which maps to NERR_UnableToDelName_F — the "unable to delete name, full" NetBIOS error. When a user logs off, the logoff processor tries to remove their message alias from the Messenger service's name table. If that alias won't come out — usually because it's still bound to something, or the name table is full — you get this error in the Application log or on the console.

You'll see this most on Windows XP, Server 2003, and older legacy boxes. It's rare on modern Windows because the Messenger service was deprecated after Server 2003, but you'll still trip over it in mixed environments, on VDI gold images, or when someone's still running an old line-of-business app that piggybacks on net send.

The classic trigger: a workstation with a stale roaming profile, the Messenger service still running, and a logon script that registers an alias at logon but can't unregister it at logoff because the process holding the name already crashed. Sounds oddly specific. It's not. I've seen it on a 200-workstation rollout at a hospital back in the XP SP3 days, and the pattern was identical every time.

Step 1: 30-Second Fix — Stop the Messenger Service

If you don't actually need Messenger, kill it. That's it. The error goes away because nothing's trying to manage aliases anymore.

1. Open a command prompt as local admin.
2. Run:

sc config Messenger start= disabled
sc stop Messenger

Reboot. Log the user off. If the error's gone, you're done — and honestly, you should have disabled Messenger years ago. Microsoft killed it for a reason. It's a needless attack surface and it does nothing useful on a modern network.

If you're on a domain and this is happening fleet-wide, push it via GPO: Computer Configuration > Windows Settings > Security Settings > System Services, then set Messenger to Disabled.

Step 2: 5-Minute Fix — Clear the Alias and Rebuild the Profile

Sometimes Messenger isn't the whole story. The alias is bound to a user SID that's still cached somewhere. Do this:

1. Log the user out fully. Not switch-user — actual logoff.
2. Open Computer Management > Shared Folders > Sessions. Look for stale sessions tied to that username or computer. Close them.
3. From an elevated command prompt:

nbtstat -RR
net session /delete /y
net config server /autodisconnect:5

That nbtstat -RR forces a NetBIOS name release and refresh. The autodisconnect tweak drops dead sessions in 5 minutes instead of letting them linger for the default 15. Call it a band-aid for the symptom — but it clears the alias table so the next logoff can succeed.

Then log the user back in, run gpupdate /force, and log off again cleanly. If the alias deletes without complaint, you're done. If it doesn't, jump to Step 3.

Step 3: 15+ Minute Fix — Profile Surgery and Registry Cleanup

By now you've confirmed Messenger isn't the only culprit. That means the user's profile is corrupt, or there's a leftover registry key pinning the alias to a dead SID. This is where you earn your paycheck.

3a. Check the Event Log First

Open Event Viewer > Windows Logs > Application. Filter by source Application Popup or Userenv. Any 1517 or 1524 warnings around the same timestamp? Those mean a roaming profile didn't unload cleanly — which is exactly what leaves the alias orphaned. If you see them, you've found your root cause.

3b. Remove the Broken Profile Properly

Don't just delete the folder in C:\Documents and Settings (or C:\Users). You'll leave the registry entry behind and the alias stays pinned. Do this instead:

1. Right-click My Computer > Properties > Advanced > User Profiles > Settings.
2. Find the profile, select it, click Delete. Yes, the UI. It removes the registry hive too.
3. Open regedit as admin and verify nothing's left:

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

Any subkey whose ProfileImagePath points to a nonexistent folder is dead weight. Export it first if you're nervous, then delete the key.

3c. Clean the Messenger Name Table Manually

If the service is legitimately still required (I've seen point-of-sale apps that use it — no, I don't know why either), you can clear stuck aliases:

net stop Messenger
net start Messenger

A service restart flushes the in-memory name table. Combined with the profile delete above, this is the combo that sticks. Don't bother with net name /delete on the alias directly — on XP and 2003 it usually throws the same NERR_UnableToDelName_F right back at you. Restart the service instead.

What Doesn't Help

Don't waste time chasing SMB signing, antivirus exclusions, or DNS. This error has nothing to do with any of them. I've watched three different admins burn a shift on DNS because the error text says "name." It's a NetBIOS alias table problem, not a name resolution problem.

Also skip the sfc /scannow reflex. System file corruption isn't what causes 0x0000089F. The files are fine. The state is wrong.

When It's Time to Just Reimage

If you've done all three steps and the alias still won't delete, the machine has registry corruption deeper than it's worth fixing. On a workstation, reimage. On a server, restore from backup. I've only seen that happen twice in 14 years, and both times the box had a failing disk with silent read errors feeding the registry corruption. If you're seeing this error alongside random other weirdness, run a chkdsk /r and check SMART before you trust anything else on that box.

Preventing It

• Disable Messenger on every machine that doesn't explicitly need it. That's 99% of them.
• Make sure roaming profiles unload cleanly — check for Userenv 1517s monthly.
• If you're using logon scripts that call net send or register aliases, audit them. Nothing good comes from legacy alias registration in 2024.
• Set autodisconnect to a sane value so stale sessions don't accumulate.

Fix the underlying cause and 0x0000089F stops showing up in your logs. Treat the symptom and it'll be back next Tuesday.