Wow64DisableWow64FsRedirection and GetNamedSecurityInfo - unavoidable ERROR_BAD_EXE_FORMAT?
I am using Wow64DisableWow64FsRedirection
/ Wow64RevertWow64FsRedirection
to disable and restore WOW-64 file redirection (making system32\ to syswow64\ and some registry changes). The MSDN page warns that you should use these pairs very close together because they effect all I/O operations, including loading DLLs.
I have 开发者_开发百科used these successfully for quite some time, but now have come up against a seemingly impossible situation. The function I am trying to call is GetNamedSecurityInfo
which takes a file path. The file path will frequently be into the system32 folder so I need to disable redirection. However, if I disable redirection the function returns ERROR_BAD_EXE_FORMAT
.
I have tried to pre-load the DLL it is in with LoadLibrary(TEXT("Advapi32.dll"))
but that didn't help. My guess is that it is loading another DLL within GetNamedSecurityInfo
but I don't know which.
So here is the question now. What is the best way to handle this situation? Should I just pre-load all possible DLLs before using Wow64DisableWow64FsRedirection
? Is there a better way?
Thanks.
It's enough that you pre-load ntmarta.dll before calling Wow64DisableWow64FsRedirection
(LoadLibrary("ntmarta.dll")
).
In this way GetNamedSecurityInfo
/ SetNamedSecurityInfo
API will not return ERROR_BAD_EXE_FORMAT
before that module is preloaded before (see ADVAPI32!AccProvpLoadMartaFunctions
function code).
In your application you should attempt to access the directory %SystemRoot%\SysNative instead of %SystemRoot%\System32. This disables the need for FS redirection. All 32-bit processes have access to this pseudo-directory. It is invisible to 64-bit processes.
32-bit cmd.exe, http://screencast.com/t/xbAQJ2XIzoT
64-bit cmd.exe, http://screencast.com/t/t9iFd9Ruc
Using the Sysnative directory is preferrable to disabling file system redirection because of the kind of problems you have run into.
精彩评论