The short version
On 64-bit Windows, System32 is the native system directory. Microsoft's File System Redirector documentation says the %windir%\System32 directory is reserved for 64-bit applications on 64-bit Windows. The 32-bit system files live in SysWOW64. The "64" in that name refers to the Windows environment hosting them, not to the files inside. WOW64 is commonly expanded as "Windows 32-bit on Windows 64-bit."
The reason there are two folders is mundane. Microsoft's documentation says most DLL file names weren't changed when 64-bit versions were created. That means kernel32.dll exists in both bitnesses, and the two copies can't share one directory.
Why Microsoft didn't rename System32
The "32" comes from history. 16-bit Windows kept system files in C:\Windows\System, and 32-bit Windows added System32. By the time 64-bit Windows arrived, many programs and scripts had the literal System32 path hard-coded. Windows Latest cites Raymond Chen's account that recompiled 64-bit programs still looked in System32 and expected 64-bit files. A batch file calling reg.exe from there would have hit the wrong tools if the folder held 32-bit binaries.
The Windows team therefore made System32 hold whatever matches the OS. The old name stays. This part is context from Chen's commentary, not a separately documented current behavior of Windows. It's a plausible and well-attributed explanation, but it is a historical account.
How the redirector works
Whenever a 32-bit application tries to reach %windir%\System32, WOW64 redirects the access to %windir%\SysWOW64. The application doesn't know this happened. Microsoft's table lists these mappings for 32-bit x86 processes:
| A 32-bit process asks for | It gets |
|---|---|
| %windir%\System32 | %windir%\SysWOW64 |
| %windir%\lastgood\system32 | %windir%\lastgood\SysWOW64 |
| %windir%\regedit.exe | %windir%\SysWOW64\regedit.exe |
Microsoft says these paths are for reference only. Applications shouldn't hard-code them and should call the documented APIs instead.
Redirection is needed because bitness can't be mixed. Microsoft's compatibility guidance says a 32-bit binary loading a DLL from System32 might accidentally pick up an incompatible 64-bit file. Redirection means the DLL it gets was built for 32-bit programs.
A confusing side effect
Matt Pietrek described this trap in a 2006 MSDN Magazine article. He ran DIR on kernel32.dll in System32 from what he didn't realize was a 32-bit command prompt. He got the same results as in SysWOW64, and it took "a lot of head scratching" to work out why. Windows Latest reports similar behavior on Windows 11 26H2. Its author saw the 32-bit Command Prompt report x86 and list a different kernel32.dll than the 64-bit one at the same path. Those are the author's own test results, not something verified independently here. Pietrek's account and Microsoft's documentation do support the general point.
A practical consequence follows. A third-party file manager or script host that is 32-bit can show you SysWOW64's contents when you browse System32. XYplorer's FAQ describes exactly that behavior for 32-bit builds.
Sysnative: the escape hatch
What if a 32-bit process really needs the 64-bit System32? Microsoft's recommended answer is the Sysnative alias. 32-bit applications can substitute %windir%\Sysnative for %windir%\System32, and WOW64 treats that as a signal not to redirect. 64-bit applications can't use it, because it's a virtual directory, not a real one.
That explains the odd behavior Windows Latest describes. File Explorer is a 64-bit app, so it can't resolve Sysnative. A 32-bit command prompt can.
A common admin scenario: a 32-bit management agent or script host needs to launch the 64-bit PowerShell. Calling the System32 path would quietly launch the 32-bit copy from SysWOW64. Using Sysnative reaches the 64-bit one. One third-party write-up (theDXT) walks through this PowerShell case. It matters for registry work, because the 32-bit PowerShell would also be subject to registry redirection.
You can also turn redirection off with the Wow64DisableWow64FsRedirection API, but Microsoft warns against leaving it off. The documentation says it affects all file operations on the calling thread. It should be disabled only for a single CreateFile call and re-enabled immediately. Leaving it off longer can stop 32-bit applications from loading system DLLs and cause them to fail. Chen's 2010 blog post makes the same point from a different angle. A complex operation may touch multiple files or spawn worker threads, so a blunt global switch is risky and Sysnative is the neater tool.
Note that Microsoft's page for the older Wow64EnableWow64FsRedirection function says it may not work reliably with nested calls. It points developers to the Disable and Revert pair instead.
Exceptions and edge cases
The UAC gotcha
Microsoft documents one surprising case. If accessing a redirected file triggers a UAC prompt, redirection doesn't occur. Instead, the 64-bit version of the file launches. The documented workarounds are to specify the SysWOW64 path directly or to run the 32-bit application as administrator so no prompt appears. That is a narrow workaround, not a general reason to elevate software.
Six folders that aren't redirected
Microsoft lists six System32 subfolders that are exempt:
- catroot
- catroot2
- driverstore
- drivers\etc
- logfiles
- spool
Microsoft's page notes that driverstore was redirected on Windows Server 2008, Vista, Server 2003 and XP. Microsoft doesn't say why the others are exempt. Windows Latest guesses they hold shared data, such as the hosts file in drivers\etc. That's a reasonable guess, but it is only a guess.
Registry and Program Files
WOW64 also gives 32-bit apps a separate registry view. Microsoft's registry redirector page explains that redirected keys map to physical locations under Wow6432Node. It also says the physical location is reserved by the system and that applications shouldn't access it directly. Some keys are shared rather than redirected, so Wow6432Node isn't the whole story. 32-bit programs also install to Program Files (x86), and Microsoft recommends the SHGetKnownFolderPath function over hard-coded assumptions.
What about Windows on Arm and SysArm32?
Windows Latest says SysArm32 "is going away" and that Arm PCs no longer support 32-bit Arm apps. Microsoft's documentation is more careful. Microsoft's Arm32-to-Arm64 guidance says Windows devices on Arm processors no longer support AArch32. Support for 32-bit Arm application versions, and the sysarm32 system binaries, will be removed in a future release of Windows 11. I couldn't confirm from that page that the removal has already happened on every current build.
Two points keep this straight:
- Microsoft's redirector table still documents SysArm32 as the destination for 32-bit Arm processes.
- This is separate from x86 and x64 apps on Arm PCs, which Microsoft says run under emulation. Arm-native builds are recommended for the best performance and battery life.
Developers with Arm32 UWP targets should add an Arm64 platform in Visual Studio (2017 version 15.9 or newer, per Microsoft's guide) and republish.
Practical takeaways
- If a 32-bit tool shows different files than you expect in System32, check its bitness in Task Manager first.
- From a 32-bit script, use Sysnative to reach native tools. Don't create a Sysnative folder yourself.
- Use documented APIs such as GetSystemWow64Directory and SHGetKnownFolderPath instead of hard-coded paths.
- Keep redirection disabled only for a single file operation.
- Compile for Arm64 if you still ship an Arm32 build.
Analysis
Windows Latest's author says he'd have preferred a folder called SysExec, which is a fair joke. Renaming System32 two decades ago would have broken a lot of software, though. The redirector, the Sysnative alias and the exemption list are clunky, but they let old software keep working. Most of the pain comes when developers try to outsmart the redirector instead of working with it. The confusing folder names are the price of backward compatibility.