Fix 0X00000963 (NERR_BadPasswordCore): Share Name or Password Invalid

What's actually happening with error 0X00000963

Error 0X00000963 maps to NERR_BadPasswordCore. Windows is telling you the password it has for the network share is wrong. But here's the trick — it's often not that you typed it wrong. The problem is Windows cached an old password, or the server rejected the credentials for a less obvious reason.

This usually shows up when you try to map a drive or access a shared folder on another machine (Windows, NAS, or Samba server). You'll see a dialog saying the share name or password isn't valid. But you know the password is correct, because you just changed it. Sound familiar?

Let's fix it. I'll start with what fixes 90% of cases, then work down to the niche stuff.

Cause 1: Stale credentials in Windows Credential Manager

Most of the time, Windows saved the old password from last time you connected. Even if you type the new one, Windows might still send the cached one. This happens because Windows prioritizes stored credentials over what you type in the connection dialog.

Fix: Clear the saved credentials

1. Open Credential Manager: hit Win + R, type control /name Microsoft.CredentialManager, press Enter.
2. Click Windows Credentials (not Web Credentials).
3. Look for any entry under Generic Credentials that matches the server name or IP of the share you're trying to access. It might be named something like TERMSRV/192.168.1.100 or just the server's hostname.
4. Click the arrow to expand it, then Remove.
5. Close Credential Manager, then try accessing the share again. Windows will now prompt you for fresh credentials.

I've seen this happen most often on Windows 10 22H2 and Windows 11 23H2 after a password change on a NAS (like Synology or QNAP). The NAS password changes, but Windows doesn't know — it keeps sending the old one. Clearing the credential is the fix.

Cause 2: The password you're using is rejected by the server

If clearing credentials didn't work, the password itself might be valid but the server's authentication settings reject it. This is common with older SMB servers or when the server expects a specific NTLM version.

Fix: Use the net use command to force fresh authentication

The GUI dialog sometimes silently fails with cached creds. The command line is more explicit.

net use * /delete
net use Z: \\SERVER\SHARE /user:DOMAIN\Username *

Replace Z: with an unused drive letter, \\SERVER\SHARE with the actual path, and DOMAIN\Username with your credentials (use a dot . for local accounts, like .\Administrator). The * at the end makes Windows prompt you for the password. This bypasses the cache entirely because the /user flag forces a new login.

The reason this works: net use with explicit credentials ignores any stored credentials for that server and creates a new session. The GUI often doesn't.

After running this, you can close the command window. The drive stays mapped.

Cause 3: LAN Manager authentication level on the client blocks the password

This is less common but I've seen it on domain-joined machines with strict security policies. Windows can be configured to refuse to send NTLMv1 responses, while the server might only accept NTLMv1 or LM. The result? The password never gets sent — and you get error 0X00000963.

Fix: Check and adjust LAN Manager authentication level

This is a group policy or registry setting. Only change it if you're sure the server is old and doesn't support NTLMv2.

1. Open Registry Editor (Win + R, type regedit, press Enter).
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.
3. Find the LmCompatibilityLevel DWORD. If it doesn't exist, the default is 0 (meaning Windows sends LM & NTLM — modern systems won't have this set).
4. If the value is 5 (refuse NTLMv1 and LM), that's the strictest setting. Try setting it to 3 (send NTLMv2 only, but accept LM & NTLM from peers — this usually works).
5. Reboot the machine, then try connecting.

Don't set it below 3 unless you know what you're doing. Setting it to 0 is a security risk. I've only needed this fix on Windows 10 Enterprise machines that had strict security baselines applied, connecting to a legacy Samba share on an old NAS running firmware from 2016.

Quick-reference summary