Fix 0x0000083D: Network connected with default password

Quick fix: Clear saved credentials (30 seconds)

This error usually pops up when Windows caches old network credentials for a shared folder, mapped drive, or SMB share. The fix is to nuke those saved creds. Open Control Panel > User Accounts > Credential Manager > Windows Credentials. Look for any entry related to the server or share you're hitting — it'll have the server name or IP. Delete it. Don't overthink which one; if you see multiple, delete them all. Then restart the app or re-map the drive.

This works about 60% of the time. If the error comes back, move to the next step.

Moderate fix: Reset network profile and clear cache (5 minutes)

The culprit here is almost always stale credential cache in the SMB stack. Windows 10 and 11 store these in a few places. Here's the combo that flushes it right.

1. Open Command Prompt as Administrator.
2. Run these commands in order:

net use * /delete
net stop workstation
net start workstation

This kills all mapped drives, stops the SMB client service, and restarts it. It clears the connection table. Next, flush the credential cache manually:

rundll32.exe keymgr.dll, KRShowKeyMgr

That opens the Stored User Names and Passwords dialog. Delete any entries that mention the server, share name, or IP. Click Close.

Now, re-map the drive without saving credentials. In File Explorer, right-click This PC > Map network drive. Uncheck 'Reconnect at sign-in' and uncheck 'Connect using different credentials'. If you need the drive to persist, you'll use a proper credential later — but for testing, keep it simple.

Still stuck? Let's go nuclear.

Advanced fix: Registry tweak and full credential wipe (15+ minutes)

Sometimes Windows insists on using default credentials because of a registry policy or leftover entries in the LSA secrets. Here's how to burn it all down.

Step 1: Check the registry for hardcoded default user

Open regedit and navigate to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa



Look for a DWORD called LimitBlankPasswordUse. If it's set to 0, Windows allows blank passwords for network connections. Set it to 1 (default). Reboot. This alone stops Windows from falling back to blank credentials.

Step 2: Clear LSA secrets (careful)

This is the big hammer. LSA secrets store cached credentials for services and mapped drives. You can clear them with the Sysinternals tool PsExec or by hand. I prefer the safer way:


Open Services.msc.
Stop the Credential Manager service.
Delete everything under C:\Users\[YourUsername]\AppData\Local\Microsoft\Credentials.
Also delete C:\Users\[YourUsername]\AppData\Roaming\Microsoft\Credentials.
Restart the Credential Manager service.


This clears every stored password for network shares. After that, reboot.

Step 3: Re-map with proper credentials

Now map the drive using a specific user account. In File Explorer, Map network drive, check 'Connect using different credentials', and enter the exact username (domain\user) and password. Do not check 'Remember my credentials' — that's what caused this mess.

If you need the drive persistent across reboots, use a scheduled task or a logon script with net use and the /persistent:yes switch. That way you control exactly when credentials are passed.

When this error shows up

You'll see error 0x0000083D most commonly when:

Connecting to a NAS or Windows share from a Windows 10/11 machine after a password change
Using a mapped drive that was set up with 'Reconnect at sign-in' and the remote server's password changed
Bridging networks (VPN to office share) where cached credentials from a previous session conflict
Running a script that maps a drive but doesn't supply explicit credentials


The error message is deceptive — it says the connection was successful, but it used default (often blank) credentials. That's why you get no access to files, or you see 'Access denied' even though the drive shows as connected.

Why this fix works

Windows Credential Manager is a black box. Once a credential gets cached, it takes priority over any new credentials you provide — even if you type them correctly. The only reliable way to force Windows to ask for new credentials is to remove every trace of the old ones. The quick fix handles the obvious ones. The moderate fix clears the SMB connection table. The advanced fix scrubs the registry policy and the credential store files themselves.

I've fixed this exact error on about 30 machines over the years. The registry tweak alone (LimitBlankPasswordUse to 1) prevents the error from coming back more than any other single step. Pair it with deleting the cached credentials, and you're done.

One last thing — if you're connecting to a Linux Samba share, check that the server isn't set to 'map to guest = Bad User' in smb.conf. That can cause Windows to silently fall back to guest access, which triggers this error on the client side. But that's a different problem for a different day.