This is an FYI for administrators who have installed or who are considering installing KB2264107 and using the 0xFFFFFFFF option for CWDIllegalInDllSearch.
The documentation in KB2264107 (as of August 31, 2010) does not appear to be entirely accurate. Based on an analysis of the actual behaviour of Windows when loading DLLs, using Process Monitor, I have concluded that the current directory remains in the search order; however, if the DLL is found in the current directory, the load fails.
Under most circumstances this distinction doesn’t matter. However, it does mean that if the DLL is found in the current directory, the directories specified by the PATH environment variable are not searched. So if the DLL is normally found by searching PATH, the load will fail if the current directory contains the DLL but not otherwise. This behaviour may be surprising.
I ran across this problem during an Oracle 10g client installation. The batch file netca.bat runs a Java program that loads DLLs from the Oracle binary directory; the binary directory is on the search path but is also the current directory. The DLL specified by the Java program (oranjni10.dll) is located successfully but its dependency (oranl10.dll) is not. The symptom is an error message from java.exe saying “The program can’t start because oranl10.dll is missing from your computer. Try reinstalling the program to fix this problem.”
This problem can be worked around in two ways. You can specify a different CWDIllegalInDllSearch value for java.exe, or you can modify netca.bat so that it doesn’t change the current directory to the Oracle binary directory. Of course, I can’t be certain that the latter change won’t cause netca.bat to fail under some circumstances, but it seems to be working for me.
Hope this helps.