Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've written a custom password filter for Windows Domain Controllers (a passfilt.dll) and registered it according to the instructions (put it in the system32 folder and updated the registry key)

But there are no signs of the DLL even being called. None.

I've set up auditing of system events and I'm getting 4614 events ("A notification package has been loaded by the Security Account Manager.") for scecli and rassfm, both listed in "HKEY_LOCAL_MACHINE.SYSTEM.CurrentControlSet.Control.Lsa.Notification Packages". If I remove them from "Notification Packages", they're not read. As expected. But the DLL that I've put into "Notification Packages" is not loaded. Nor is the logged a failed audit. Or any other event. The DLL is not loaded since I can delete it without a lock.

The OS is Windows 2008 R2 x64 and I'm using an 64 bit version of my DLL.

Does anyone have an idea on how I should proceed to solve this problem? At least find an error message or something...

share|improve this question
up vote 2 down vote accepted

You cannot dynamically load or unload the DLL. Put the DLL in system32. Add the name to the list of Notification Packages. You need the name only (not the .DLL part). You will need to reboot. On boot the OS reads the Notification Packages value and loads all DLLs there. When you logon run winmsd or msinfo32 to be sure your DLL is loaded. See Computer Configuration + Software Environment + Loaded Modules. The DLL is only called during a pw change and only if the pw meets the windows requirements (min length, no min age issue, not in history buffer). The LSA first checks windows requirements (in 2K3 and 2K8) and then calls the PasswordFilter() function for each DLL listed int he Notification Packages in the order listed. If your DLL says pw is OK and no other filters reject it the pw is committed to AD/SAM and then the LSA goes through all DLLs listed there again to call PasswordChangeNotify() so a DLL can do pw sync (i.e. sync is OK since pw was committed to AD, never try to sync of PasswordFilter() call). If you need to modify update the DLL you have to remove the entry from Notification Packages, reboot, copy the new one to system32, update Notification Packages again and reboot. Save time, write a script and use 2 DLL names so when you reboot it you load the 2nd then switch back to the first on next reboot, etc. Kernel debugging is slow / painful. So if you debug it is probably easier to have it write to a file.

share|improve this answer

I've solved this problem by installing the redistruable package of C++ visual studio on each DC.

You MUST install the same version of the redistribuable package of VS C++ according to the version of Visual Studio used to compile your dll.

share|improve this answer

You'll probably have to run regsvr32 to make sure it registers properly. The link explains the proper syntax (generally just regsvr32 dllname.dll)

share|improve this answer
No, that won't help. RegSvr32 is just for COM DLLs. This is a pure native DLL that is loaded dynamically by LSA (or it should be loaded dynamically) – henriksen Nov 30 '11 at 23:12

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.