Fix NERR_PasswordFilterError (0X00000A91) Fast
A password filter DLL's blocking your password change. Usually a third-party security tool or a broken registry entry—here's how to kill it.
Quick Answer
Delete the broken or unwanted password filter DLL reference from HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Notification Packages in the registry, then reboot.
Why This Happens
You're trying to change a user's password—either locally or over the network—and Windows slaps you with error 0X00000A91, which maps to NERR_PasswordFilterError. This isn't a simple "password too short" thing. It means a password filter DLL—usually a third-party security tool, a legacy password complexity checker, or sometimes a misconfigured Microsoft tool—either crashed or rejected the password. I've seen this blow up on a domain controller after someone installed a cheap password history add-on. Last month I had a client whose printer server kept throwing this error because an old antivirus password filter was still clinging to life in the registry.
The filter sits in the Windows LSA (Local Security Authority) as a registered notification package. When you submit a password change, Windows calls every registered DLL. If any of them fails or returns garbage, you get this error. The tricky part? The password itself might be totally fine—the DLL's just broken or incompatible with your current Windows build.
Step-by-Step Fix
- Open Regedit as administrator. Hit Win+R, type
regedit, right-click and run as admin. Don't skip that—you'll get access denied trying to edit LSA keys without elevation. - Navigate to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa - Find the
Notification Packagesmulti-string value. Right-click it and choose Modify. This is where Windows lists every password filter DLL filename without the .dll extension. - Identify the culprit. Common entries:
passfilt(Microsoft's own, usually fine),scecli, or third-party names likeASAPasswordFilter,mypasswordfilter,appvstrm. If you see anything you don't recognize—especially from an old security suite or a custom tool someone built years ago—that's your suspect. - Remove the suspect entry. Copy the whole list to Notepad first as a backup. Then delete just the problematic line. Leave everything else untouched. Click OK.
- Reboot the machine. This is critical. Changes to Notification Packages only take effect after a reboot. Without it, nothing changes.
After the reboot, try the password change again. If it works, you're golden. If not, move to the alternatives below.
Alternative Fixes
Check the DLL Exists
Sometimes the registry entry points to a DLL that's been deleted or corrupted. Open a command prompt as admin and run:
dir C:\Windows\System32\dllname.dll replacing dllname with each entry from Notification Packages. If the file's missing, that registry entry is dead—remove it as above.Use Procmon to Find the Exact Filter
If you're not sure which DLL is failing, grab Process Monitor from Sysinternals. Set a filter for Process Name = lsass.exe and include Path contains .dll. Reproduce the error (try changing a password). Procmon will show you which DLL throws an error—look for NAME NOT FOUND or BUFFER OVERFLOW entries. That's your target.
Check Event Viewer
Open Event Viewer, go to Windows Logs > Security. Look for Event ID 4724 (password change attempt) or 4698 (if you're lucky). The details may name the filter module that failed. I've also seen it logged under Application and Services Logs > Microsoft > Windows > Security-Mitigations > Kernel on Server 2019+.
Temporarily Disable Third-Party Security Software
Some antivirus or password manager tools register their own filter. Disable them completely (not just the GUI—stop the service, set to disabled) and retry. If the error disappears, uninstall the tool and use something that doesn't hook into LSA.
Prevention Tips
- Audit Notification Packages regularly. Every 6 months, check that registry key. If you see something and nobody remembers what it's for, remove it. Dead DLLs are ticking time bombs.
- Test password filter changes in a lab or on a non-production machine first. I've seen a single bad filter take down an entire domain's password policy—every user could change passwords except one group, took hours to trace.
- Stick to Microsoft's built-in passfilt.dll unless you absolutely need custom complexity. It's battle-tested. Third-party filters break more often than they solve problems.
- Document every registry change. Keep a text file in the repo or on the server's desktop. When you add a new filter, note the date, the DLL name, and why. Future you will thank present you.
If none of this works and you're still stuck, the filter might be part of a group policy. Check gpedit.msc > Computer Configuration > Windows Settings > Security Settings > Account Policies > Password Policy and look for anything pointing to a custom filter. But 9 times out of 10, it's that orphaned registry entry. Kill it, reboot, move on.
Was this solution helpful?