Windows DLL Search Order

D

Deque

Limp Gawd
Joined
Jun 1, 2004
Messages
484
Hey everyone, I apologize in advance if I won't be able to answer all of your questions, but I'll try my best. I'm not an Active Directory Administrator, but I know a little.

Currently in our Windows Server 2003 environment, our users were experiencing slow response times on certain applications. It wasn't until we noticed that our consultants didn't have the same issue, and we traced it to the fact our users have a Home Profile set that maps an H:\ drive to their home folder.

All of our corporate systems are housed in a hosting facility and the users use clients installed on terminal servers there to access those applications. So when a user is logged into those terminal servers, their home folder will be across the WAN and the response times will be very slow at times (depending on users internet traffic and other things).

We think the issue is a Windows problem with DLL Search Order, but we can't pinpoint the resolution.

The way we determined this was by running ProcessMon from SysInternals and view what was going on. When we launched the application, it was searching for a particular DLL (XYZ.DLL, for instance). In ProcessMon, you would see a bunch of lines where the result was "NAME NOT FOUND", but the order looked something like this:

1 - Folder where Executable was launched
2 - C:\Windows\system32\xyz.dll
3 - C:\Windows\system\xyz.dll
4 - C:\Windows\xyz.dll
5 - H:\Windows\xyz.dll
6 - Folder where Executable was launched (again?)
7 - C:\Windows\system32\xyz.dll
8 - C:\Windows\xyz.dll
9 - C:\Windows\system32\wbem\xyz.dll
10 - etc

Starting at line 7, everything starts matching what's defined in our PATH environment variable. According to this, http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx, we have SafeDllSearchMode enabled.

So the problem appears as though in a Windows Terminal Server environment, it also looks on the home directory for the user as specified in Active Directory.

We know a fix is to either disconnect that drive or specify a Terminal Services Profile in Active Directory to the local path, but we would prefer to do neither. We would like to keep the users Home Directory, but achieve better performance.
 
So where actually is the dll? I would say put the DLL in a place such that it would be found near the top of the list, before it even attempts to go to the H:
 
extide said:
So where actually is the dll? I would say put the DLL in a place such that it would be found near the top of the list, before it even attempts to go to the H:
Click to expand...

The DLL exists in one of the folders in the PATH. The application installs some of the DLLs to a "shared" location, but it's not in the same directory as where the program is launched.

We actually did try that, but then the application crashed. The only thing I could think of was that the DLL references something else by a relative path, so we'd have to copy more than just that DLL.

But we'd like to avoid even doing that approach because it'd make maintenance a burden. Everytime we apply a hotfix, we'd have to remember to update all of the DLLs manually.

If there isn't a way to get terminal server to not search their Home Profile for a Windows directory, then we'll just have to stick with the Terminal Services Profile setting, but that takes away their H:\ drive so then the users couldn't access their documents. We could add a login script to manually map it, but this seems like a hackish way to solve this problem.
 
Hrmm... Yeah I think the login script mapping might be the best way then. That really sucks. So is the H: slow and it takes forever for it to look for dll's there then?
 
Is the DLL in system32? If so, you could probably add it to HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs

In theory, that should force the DLL to always be loaded from that location, bypassing the whole searching crap. You could also try running regsvr32 <path to DLL>, I'm not sure if registering a dll bypasses searching as well.

Your idea of removing the profile setting in AD and changing H: to a mapped drive in the login script will work perfectly though. I had the exact same issue at my current job. I'm a remote employee with only a 512k link back to the HO, and my performance at all times was terrible until I changed my AD profile dir back to local path.
 
You must log in or register to reply here.
Back
Top