Fix ERROR_NULL_LM_PASSWORD (0X00000518) in Windows
This error means Windows can't convert your password to a LAN Manager hash. The quick fix is disabling LM hash storage in Group Policy or the registry.
You’re staring at error 0X00000518 — and it’s annoying as hell
This usually pops up when you’re trying to authenticate against an older system (like a legacy NAS, a Windows 2003 server, or an SMB share that still talks LM). The fix is straightforward: stop Windows from trying to store a LAN Manager hash of your password. Here’s how.
The real fix: disable LM hash entirely
The culprit here is almost always the Network security: Do not store LAN Manager hash value on next password change policy. Microsoft added this setting years ago because LM hashes are laughably weak — they’re split into two 7-character chunks and case-insensitive. But sometimes an app or service expects them, and you get this error.
You’ve got two ways to kill this. Pick one.
Option 1: Group Policy (domain or local)
- Press Win + R, type
gpedit.msc, hit Enter. - Go to Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options.
- Find Network security: Do not store LAN Manager hash value on next password change.
- Set it to Enabled. Yes, enabled means “don’t store LM hash.” That’s what you want.
- Run
gpupdate /forcein an admin command prompt. - Change your password (or force a password change via Ctrl + Alt + Del → Change a password). The error won’t reappear.
Option 2: Registry (if no Group Policy editor — Windows Home, for example)
Open regedit as admin, navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa. Look for a DWORD called NoLMHash. If it’s not there, create it. Set the value to 1 (enabled). Reboot, then change your password.
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa" /v NoLMHash /t REG_DWORD /d 1 /fThat’s it. The error is gone after a password change.
Why this works
Windows, by default, stores two password hashes: the NT hash (modern, secure) and the LM hash (legacy, weak). The LM hash has a 14-character limit and doesn’t support Unicode or case sensitivity. When your password is too long, has special characters, or uses mixed case — the LM converter chokes. Instead of failing gracefully, it throws error 0X00000518.
Disabling LM hash storage tells Windows: “Skip the LM hash entirely, just use NT.” No conversion, no error. You lose nothing — nothing modern uses LM hashes anyway. Even older SMB clients (like Windows 98, if you’re running that) will fall back to NTLMv2. If you’re still relying on LM for compatibility, you’ve got bigger problems.
Less common variations of the same issue
Sometimes the fix above doesn’t stick because of these edge cases:
- Stale cached credentials — If you’re connecting to a remote share with saved credentials, Windows might still try to use the old LM hash. Clear them: Control Panel → Credential Manager → Windows Credentials. Delete the entry for the target server, then reconnect.
- Third-party SMB clients (like Map-Network-Drive scripts in PowerShell) — Some tools explicitly request LM authentication. Check the script:
New-PSDrive -Persistcan trigger this. Switch toNew-SmbMappinginstead, which uses NTLMv2 by default. - Domain Group Policy overriding local settings — If you’re domain-joined, the domain policy might force LM hash storage. Check with
rsop.msc→ look under Security Settings. If domain policy says “Disabled” (i.e., store LM hashes), you’ll need your domain admin to change the GPO, not the local policy. - Legacy software that requires LM — Some ancient accounting apps or vendor tools hardcode LM authentication. In that case, you can’t disable LM entirely without breaking them. Your only option is to use a shorter, all-uppercase password (14 chars max, no symbols). That’s terrible advice, but sometimes the business needs it. Document the risk.
Prevention — keep this error away
- Disable LM hash storage as standard policy on every Windows machine you touch. Do it via GPO if you’re managing a domain, or via the registry for standalone boxes. It’s been a best practice since Windows Vista.
- Audit your network for devices that still use LM authentication — old printers, NAS boxes, embedded systems. Replace them or isolate them. Nothing made after 2010 should need LM.
- Use SMB 2.0 or higher whenever possible. SMB 1.0 required LM hashes. Disable SMB 1.0 via
Disable-WindowsOptionalFeature -Online -FeatureName smb1protocol. This kills two birds — security and this error. - Set password complexity policies that avoid the LM limit — Windows default policy already does this (passwords over 14 chars aren’t attempted for LM). But if you’re forced to use short passwords, at least use mixed case and numbers. LM hashes ignore case, so “Password1” and “pASSWORD1” produce the same hash. That’s why disabling LM is always better.
The 0X00000518 error is a sign your network still has one foot in the 1990s. Kick LM to the curb and you won’t see it again.
Was this solution helpful?