GetModuleFileNameEx, EnumProcessModules(Ex) failures in Wow64

原文链接：http://winprogger.com/getmodulefilenameex-enumprocessmodulesex-failures-in-wow64/

转载注：懒得翻译了，很短，而且没有太复杂难度的地方吧。一句话总结：在64位机器上，32位程序调用GetModuleFileNameEx, EnumProcessModules(Ex)来处理64位程序时会失败。

When a 32-bit  application running in 64-bit Vista (ie. under wow64) attempts to determine the process file name of the 64-bit process via win32 call GetModuleFileNameEx (with hModule passed as NULL to indicate that the program is interested in the full path of the executable of the process), that function returns 0 indicating failure. GetLastError returns ERROR_PARTIAL_COPY (error 299). winerror.h describes this error as Only part of a ReadProcessMemory or WriteProcessMemory request was completed.

Why does GetModuleFileNameEx fail ? Well, in order to get the full path name of the process (whose handle is passed as first parameter) PSAPI’s GetModuleFileNameEx needs to access the PEB (process environment block) of the process. To get at the PEB it calls NtQueryInformationProcess with ProcessInformationClass set to ProcessBasicInformation. NtQueryInformationProcess fills in a PROCESS_BASIC_INFORMATION structure that is declared as under.

PEB of the process is obviously found in PebBaseAddress. However the PEB of a 64-bit process lies at a 64-bit address and since PROCESS_BASIC_INFORMATION for 32-bit applications only has space for 32-bit pointer, how can the 64Bit PEB address be returned to a 32-bit application ?  If the 64-bit PEB had no high bits set, then technically the 64-bit PEB address could fit into 32-bits without losing any of the address bits. wow64 solves this problem simply by setting PebBaseAddress to NULL in all cases.

Now, wow64 translation is needed in this case since the 64-bit structure members would have to be downsized to fit in 32-bit PROCESS_BASIC_INFORMATION structure. [32-bit PROCESS_BASIC_INFORMATION is 24 bytes where as 64-bit PROCESS_BASIC_INFORMATION is 48 bytes]

Since NtQueryInformationProcess returns success despite this loss of PEB data in the wow64 translation layer, GetModuleFileNameEx in 32-bit process eventually ends up attempting to read invalid memory in the opened process, when it calls ReadProcessMemory (or more specifically NtReadVirtualMemory) with offsets from NULL PEB returned. This causes error 299 (ERROR_PARTIAL_COPY).

If you are running on XP or above, the recommended workaround to get at the 64-bit process image path from a 32-bit process, is to use the newer GetProcessImageFileName which gets the path (via  ProcessImageFileName (27) process information class of NtQueryInformationProcess). The wow64 layer does not do much this time because it is just a unicode string. However this function has a downside – the path returned is of the form /Device/HarddiskVolumeX instead of DOS style drive letter based paths. You cannot have the cake and eat it too, right ?

[ ERROR_PARTIAL_COPY also happens if a 32-bit process calls EnumProcessModules or the newer EnumProcessModulesEx on a 64-bit process handle in an attempt to enumerate loaded modules in the process. That is because EnumProcessModules will need to access the process PEB as well and EnumProcessModulesEx is mostly designed for 64-bit applications to get 32-bit module information not the other way around. CreateToolhelp32Snapshot on a 64-bit pid, fails similarly as well. ]