0X0000089B NERR_BadPassword Error: Real Fix

You just changed your domain password. Everything's fine locally. Then you double-click a mapped drive and get hit with 0X0000089B — NERR_BadPassword. Or a scheduled task fails at 3 AM because it's running under an old service account. Or someone tries to RDP into a server with credentials from a different domain and Windows spits this out. The trigger is almost always the same: something on the system is holding onto an old password and keeps replaying it to a remote resource.

It shows up in Event Viewer under Security or System logs, in net use output, in the weird corners of net helpmsg 1327 (which is what 0x89B translates to in decimal). The message sounds generic. The cause usually isn't.

What 0X0000089B actually means

NERR_BadPassword is a LAN Manager / Windows networking error. It means the credential you sent to a remote machine didn't match what that machine expected. That's it. Not a broken driver, not a corrupt profile, not a hardware fault. The password on the wire was wrong.

The catch is which password. Windows caches credentials in a few places, and any one of them can go stale:

Credential Manager — stored entries under Windows Credentials for specific hosts or shares.
Active net use sessions — a mapped drive that authenticated hours ago with the old password keeps the session alive until it times out.
Scheduled tasks — if the task stores a password instead of running as S4U or with a gMSA, the task keeps using whatever password it was created with.
Services — same deal. A service running as a domain account with a stale password will fail to authenticate anywhere it goes.
RDP saved credentials — the .rdp file or Windows credential store entry for the target host.

On a machine that's been in production for a while, you usually have several of these stacked up. Fixing one exposes the next. So you clear them all at once.

The classic real-world trigger: an admin rotates a service account password on a Friday, updates it in AD, updates the service, but forgets the scheduled task on a remote file server that authenticates to a share. Monday morning the backup job fails with 0X0000089B in the task history.

The fix, step by step

Do these in order. Don't skip steps hoping the first one solves it — you'll end up chasing your tail.

Kill any existing network sessions. Open an elevated Command Prompt and clear the SMB session cache for the target host.
```
net use * /delete /y
```
That nukes every mapped drive and IPC connection on the machine. If you only want to target one host:
```
net use \\fileserver\share /delete
```
Clear Credential Manager entries for that host. Open Control Panel → Credential Manager → Windows Credentials. Look for anything matching the server name, FQDN, or the share path. Delete them. From a command line:
```
cmdkey /list
cmdkey /delete:fileserver
cmdkey /delete:fileserver.domain.local
```
Delete both the short name and FQDN entries if they exist. Windows treats them as separate credentials and will happily use the wrong one.
Re-establish the connection with explicit credentials. Don't let Windows autofill from the logged-in user if that's not who should be authenticating.
```
net use Z: \\fileserver\share /user:DOMAIN\svc_account *
```
The * prompts for the password so it never lands in command history or a log file.
If the credential is used by a scheduled task, update it. Open Task Scheduler, find the task, go to Properties → General. Re-enter the password under "When running the task, use the following user account". If the account is a domain service account, consider switching it to run as NT AUTHORITY\SYSTEM (if it doesn't need network access) or use a group Managed Service Account so password rotation stops breaking it.
Check services running under the affected account. services.msc, sort by "Log On As", find anything running as the user with the changed password. Right-click → Properties → Log On → re-enter the password → Apply. Then restart the service.
For RDP problems, blow away the saved credential. Delete the .rdp file's cached creds, or in the RDP client untick "Remember me" and reconnect. Also run cmdkey /list and remove anything pointing at the RDP target's hostname or IP.
Reboot if sessions won't clear. Sometimes the SMB client hangs onto a session to a dead server and won't release it. A reboot is faster than fighting it. Not elegant, but it works.

If it still throws 0X0000089B

You missed a credential store somewhere, or the password you're typing is actually wrong. Both happen. Check these:

Typo in the password. Obvious, but easy to overlook when you've typed it ten times. Test with runas /user:DOMAIN\account cmd from a fresh prompt to confirm the password is valid at all.
Account locked or expired. Check net user account /domain or ADUC. Bad password errors stack up fast and lock the account after the domain policy threshold.
Kerberos ticket cache. If you're in a domain, run klist purge to dump cached tickets, then klist get krbtgt to force a new TGT. Stale tickets cause weird auth failures that look like bad passwords.
Local vs domain account mixup. SERVERNAME\user is not the same as DOMAIN\user. If the target server is domain-joined but you're authenticating with a local account, or vice versa, you'll get exactly this error.
Time skew. Kerberos fails hard when clocks are more than 5 minutes apart. Bad password is often the reported symptom. Run w32tm /query /status and compare against the domain controller.
Group Policy mapped drives. If drives come from GPO, the credential is applied at logon. Check User Configuration → Preferences → Windows Settings → Drive Maps. Update the stored credentials there.

Nine times out of ten, clearing net use sessions and Credential Manager entries fixes this on the spot. The tenth time, it's a scheduled task or service most people forgot was still running under the old password. Those are the ones that bite you on a Monday morning.