I will try very briefly to summarize how a 32-bit process is loaded.
- an EPROCESS is created, with the 32bit process `flag` set
- the image is mapped in the new address space
- the 64bit ntdll.dll is loaded
- the 64-bit ntdll.dll realizes this is a wow64 process
- it then loads the wow64 modules (wow64, wow64bin, wow64cpu)
and the wow64 modules runs the cpu simulation loop (let's not argue on
this name for now)
- the cpu simulation loop loads the 32-bit ntdll.dll, that carries on
process initialization as usual.
- during (32-bit) process initialization, ntdll loads the other modules
NtDll.dll is treated specially, given its role in process intialization.
So, to summarize, there are 2 list of modules for a 32-bit process under
and, 64-bit tlist.exe pointed to a 32-bit process clearly shows that.
The paths are always consistent for the "half of the world" that uses them.
Unless you disable redirection, opening `c:\windows\system32` from a 32-bit
will effectively go to `c:\windows\SysWOW64`, that is the correct result
from the point of view of the 32-bit process. Opening `c:\windows\syswow64`
is again correct for a 32-bit process.
However, as 64-bit process can be 32-bit aware, and, opening
`c:\windows\syswow64\xxx.dll` will really open the 32-bit binary,
and that may be expected and wanted, since 64-bit processes
can be designed to be aware of the wow64 subsystem, while
the coverse is not necessarely true.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at