2

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.

coderforlife
  • 1,378
  • 18
  • 31
  • 2
    One preloading approach that might work: Try calling GetNamedSecurityInfo with a path you know won't be virtualized, so that it loads all its DLLs, then disable virtualization and try the system32 file in question. – ChrisV Jan 21 '11 at 23:30
  • I just thought of that as well, and it works! I use the following to preload: GetNamedSecurityInfo(TEXT("."), SE_FILE_OBJECT, 0, NULL, NULL, NULL, NULL, NULL); it is nice that I can just give it all NULLs... – coderforlife Jan 21 '11 at 23:32

2 Answers2

1

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).

sashkello
  • 17,306
  • 24
  • 81
  • 109
Andrea Allievi
  • 26
  • 1
0

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.

subwar
  • 279
  • 1
  • 3
  • I use `sysnative` when possible, however many of the paths are coming from outside sources (e.g. BCD). I guess I could replace \Windows\System32 with \Windows\SysNative however it is likely that there may be files in a \Windows\System32 that are NOT the system directory (e.g. in a mounted WIM image) and the \Windows\SysNative would fail there. The solution given by @ChrisV in the comments above worked wonderfully. – coderforlife May 03 '11 at 06:39