File Getting Copied to Syswow64 Instead of System32

File getting copied to SysWOW64 instead of System32

You've run afoul of file system redirection.

Because %windir%\System32 is reserved exclusively for 64-bit applications, on 64-bit versions of Windows, 32-bit applications that attempt to access the %windir%\System32 directory are automatically and transparent redirected to the 32-bit %windir%\SysWOW64 directory.

First, make sure that your program actually does belong in the 64-bit system folder. Windows does this automatic redirection for a reason. 32-bit stuff does not go in the %windir%\System32 folder on 64-bit versions of Windows.

If you're certain that you want to be copying stuff into the 64-bit system directory, you have a couple of options. The easiest is probably to just compile your utility as a 64-bit application. Alternatively, you can tell the WOW64 redirector that you know what you're doing and not to perform the redirection by using %windir%\Sysnative instead of %windir%\System32.

Why copying to system32 automatically copies to sysWOW64 instead?

On 64bit Windows, Windows does filesystem redirection for 32bit processes. To disable, call Wow64DisableWow64FsRedirection

For the app to also run on 32bit Windows XP, Wow64DisableWow64FsRedirection must be dynamically linked at run-time.
Here is the code I use:

BOOL DisableWow64FsRedirection(PVOID* OldValue)
{
#ifdef WIN64
    UNREFERENCED_PARAMETER(OldValue);
    return TRUE;
#else
    typedef BOOL (WINAPI * LPWOW64DISABLEWOW64FSREDIRECTION)(PVOID *);

    LPWOW64DISABLEWOW64FSREDIRECTION    fnWow64DisableWow64FsRedirection;
    HMODULE                             kernelMod;
    BOOL                                success = TRUE;

    kernelMod = GetModuleHandleW(L"kernel32");
    if (kernelMod)
    {
        fnWow64DisableWow64FsRedirection = (LPWOW64DISABLEWOW64FSREDIRECTION)GetProcAddress(kernelMod, "Wow64DisableWow64FsRedirection");
        if (fnWow64DisableWow64FsRedirection)
            success = fnWow64DisableWow64FsRedirection(OldValue);
    }

    return success;
#endif
}

BOOL RevertWow64FsRedirection(PVOID OldValue)
{
#ifdef WIN64
    UNREFERENCED_PARAMETER(OldValue);
    return TRUE;
#else
    typedef BOOL (WINAPI * LPWOW64REVERTWOW64FSREDIRECTION)(PVOID);

    LPWOW64REVERTWOW64FSREDIRECTION fnWow64RevertWow64FsRedirection;
    HMODULE                         kernelMod;
    BOOL                            success = TRUE;

    kernelMod = GetModuleHandleW(L"kernel32");
    if (kernelMod)
    {
        fnWow64RevertWow64FsRedirection = (LPWOW64REVERTWOW64FSREDIRECTION)GetProcAddress(kernelMod, "Wow64RevertWow64FsRedirection");
        if (fnWow64RevertWow64FsRedirection)
            success = fnWow64RevertWow64FsRedirection(OldValue);
    }

    return success;
#endif
}

64-bit system copies dll files into SysWOW64 instead of system32 using WiX installer [SystemFolder] property

Just a short illustration:

1. Set the Platform to x64 in the Package element.
2. For the hosting component set the Win64 attribute to yes, and install to System64Folder.

---

1. Package Element:

<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" Platform="x64" />

---

2. WiX WXS Snippet:

<Directory Id="System64Folder">
  <Component Feature="ProductFeature" Win64="yes">
    <File Source="TestFile.txt" />
  </Component>
</Directory>

---

And a few things:

• Files installing to the System folder are generally supposed to be set permanent (validation error or warning if you do not)
• You should not install to the System folder if you can help it. What file is this?

Why is SysWOW64 reported as System32?

It's a bit confusing, but SysWOW64 is actually the 32 bit emulator for 64 bit systems.

WOW stands for "Windows on Windows", and the original SysWOW was the 16 bit emulator for 32 Bit Windows (and should have been called SysWOW32). So SysWOW64 is the 32 bit emulator for 64 bit Windows.

So, when you run 32 bit applications, it uses SysWOW64 to emulate the 32 bit registry, and 32 bit redirection (to Program Files (x86) for instance).

Unmanaged 64-bit DLL copied to SysWOW64 and not System32 by Visual Studio

Your script is being run from a 32-bit process. As a sort of band-aid solution you should be able to replace system32 with sysnative and the WOW64 layer should do the right thing.

Update: Sorry, maybe this instead: %windir%\sysnative\cmd.exe /C "xcopy ..."

Want to copy screenesaver file in System32 folder instead of SysWow64 on 64bit Machine

The question I asked in the comments is an important one:

Is your screen saver compiled as a 32-bit or 64-bit application?

The deal is that 32-bit applications go into the SysWow64 folder, and 64-bit applications go into the System32 folder. Simple enough, right?

I know that seems backwards—the one that contains 32-bit applications has 64 in the name—but it was done for backwards-compatibility reasons. Lots of people hardcode paths, like System32, into their applications and installers. Let this be a lesson to you: committing these sins leads to inescapable ugliness in the future.

So if your screen saver is compiled as a 32-bit application, it belongs in the SysWow64 folder, not in the System32 folder. The system is smart enough to know this, so it's automatically doing the right thing and redirecting your application into the appropriate folder. On a 32-bit Windows installation, your 32-bit screen saver will indeed be placed into the System32 folder.

I suppose you could override this behavior, but I'm not going to tell you how. If you really want your screen saver to be in the System32 folder on 64-bit Windows, you should re-compile it as a 64-bit app.

Why do 64-bit DLLs go to System32 and 32-bit DLLs to SysWoW64 on 64-bit Windows?

I believe the intent was to rename System32, but so many applications hard-coded for that path, that it wasn't feasible to remove it.

SysWoW64 wasn't intended for the dlls of 64-bit systems, it's actually something like "Windows on Windows64", meaning the bits you need to run 32bit apps on a 64bit windows.

This article explains a bit:

Windows x64 has a directory System32 that contains 64-bit DLLs (sic!).
Thus native processes with a bitness of 64 find “their” DLLs where
they expect them: in the System32 folder. A second directory,
SysWOW64, contains the 32-bit DLLs. The file system redirector does
the magic of hiding the real System32 directory for 32-bit processes
and showing SysWOW64 under the name of System32.

If you're talking about an installer, you really should not hard-code the path to the system folder. Instead, let Windows take care of it for you based on whether or not your installer is running on the emulation layer.

---

Related Topics