c:\windows\system32\dllcache inaccessible
c:\windows\system32\dllcache inaccessible
Under Windows 2003 Server the "dllcache" directory is hidden unless running cmd.exe or Windows File Explorer. This must be some anti-malware feature but it's very annoying. All other programs like Far, Cygwin bash, and even some disk defraggers don't see the directory at all. Have anyone else experienced this or know some way to disable this security feature?
Before jumping into the conclusion that Windows Server 2003 is doing some kind of parent process security check I want to provide some more observations.
This system is a x64. It has C:\windows\System32 and C:\windows\SysWOW64 directories.
Far behavior:
Using Process Monitor from Sysinternal Far tries to open the SysWOW64 when I'm actually trying to open the System32 directory.
Running CMD and bash shells under Far:
"dir c:\windows\system32" shows up an open to "c:\windows\syswow64" in Sysinternal.
Running CMD shell from under other processes (e.g. explorer, task manager, process explorer):
"dir c:\windows\system32" actually resolves correctly.
Running Cygwin bash shell from under other processes (e.g. explorer, task manager, process explorer):
"dir c:\windows\system32" silently resolves to SysWOW64 directory.
Now this is a problem. Something is silently replacing queries to System32 to SysWOW64 as captured by Process Monitor. This implies that the replacement had to have come from non-kernel space because the directory asked for had already changed before reaching the kernel.
My current thinking is perhaps Microsoft changed kernel32.dll or added some DLLs which do Win32 to Win64 compatibility translations. The problem is how to turn this feature off, or how can programs like FAR work around it.
This system is a x64. It has C:\windows\System32 and C:\windows\SysWOW64 directories.
Far behavior:
Using Process Monitor from Sysinternal Far tries to open the SysWOW64 when I'm actually trying to open the System32 directory.
Running CMD and bash shells under Far:
"dir c:\windows\system32" shows up an open to "c:\windows\syswow64" in Sysinternal.
Running CMD shell from under other processes (e.g. explorer, task manager, process explorer):
"dir c:\windows\system32" actually resolves correctly.
Running Cygwin bash shell from under other processes (e.g. explorer, task manager, process explorer):
"dir c:\windows\system32" silently resolves to SysWOW64 directory.
Now this is a problem. Something is silently replacing queries to System32 to SysWOW64 as captured by Process Monitor. This implies that the replacement had to have come from non-kernel space because the directory asked for had already changed before reaching the kernel.
My current thinking is perhaps Microsoft changed kernel32.dll or added some DLLs which do Win32 to Win64 compatibility translations. The problem is how to turn this feature off, or how can programs like FAR work around it.
Aha! Windows x64 compatibility crap!
Far needs to be modified so that the thread that gets the current directory list is expected to call Wow64DisableWow64FSRedirection(). The simpler fix is to recompile Far for 64-bit Windows to avoid the WOW mess.
http://support.microsoft.com/kb/942589
Far needs to be modified so that the thread that gets the current directory list is expected to call Wow64DisableWow64FSRedirection(). The simpler fix is to recompile Far for 64-bit Windows to avoid the WOW mess.
http://support.microsoft.com/kb/942589