I've noticed a problem when running applications on Windows 7 from an SMB share on an older SMB server that does not support NT status codes. I've taken Procmon traces of the Windows client running a simple MFC app from the server. When the server was patched to partially support NT status codes temporarily, the Windows client appears to follow the DLL resolution search order described here: http://msdn.microsoft.com/en-us/library /ms682586%28VS.85%29.aspx When the server is allowed to operate normally with the old DOS/LANMAN error codes, the client only searches the share directory where the app is located. Has anyone else noticed this behavior? Is there a way to correct it?

Hi, The issue you posted is related to TechNet and would be better suited in the TechNet community. Please visit the link below to find a community that will offer the best support. http://social.technet.microsoft.com/Forums/en-US/category/ Please respond back for the status on the issue and let us know if you have any issues. Azam – Microsoft Support.

What is the error message when the issue occurs? I suggest you follow the steps below. 1. Launch regedit from Start Search box.2. Find the following branch. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa 3. Create a DWORD key under Lsa and set: Name: LmCompatibilityLevel Value: 1 4. Restart. If the issue persists, please make the following changes. 1. Open gpedit.msc. 2. Find the policy Windows Settings -> Security Settings -> Local Policies -> Security Options ->Network Security: Configure encryption types allowed for Kerberos 3. Configure the policy. If it is not configured, actually both DES cipher suites are disabled. I suggest that you enable all the suits.Arthur Xie - MSFT

I think that perhaps my original problem description was misunderstood. The problem I tried to describe is not related to the initial connection to the server. Even so, I tried the suggestions. They did not correct the problem. The problem I am having is that Windows 7 does not appear to be following the PC search path for DLLs when running an application hosted on an SMB server that only supports DOS return codes. It only appears to search the share path for the DLL. I've noticed that the Windows 7 client does do a correct DLL search of the local search path after first checking the share path when the server supports NT status codes. Here is a screen capture of the error displayed on the Windows machine: http://i169.photobucket.com/albums/u220/clemig/Work/install_error.png Here are screen captures of the Process Monitor traces I've captured: Dos return codes http://i169.photobucket.com/albums/u220/clemig/Work/ProcmontraceDOS.png NT status codes http://i169.photobucket.com/albums/u220/clemig/Work/ProcmontraceNT.png

I managed to find the fix for the problem myself. There is a Windows 7 hotfix to correct "Error message when you try to open a network-shared application on a client computer that is running Windows 7 or Windows Server 2008 R2: 0xc000000f". I've loaded and tested the fix, and it appears to resolve my issue. Here is the URL to the hotfix: http://support.microsoft.com/kb/978869

Hi, Glad to hear that your issue has been resolved and your suggestions may help other users. Thank you. Let us know if you have any issues. Azam - Microsoft Support.