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. ]
Very helpful. I have been facing the ntQueryInformationProcess problem for several days without success.
Is there a workaround similar to GetProcessImageFileName that would get the startup command line arguments of a process?
Thanks
You should look at WMI for that if you have not already. [for example in command prompt type wmic PROCESS get Processid,Caption,Commandline]
I had never heard of WMI until this. I’ve been doing some preliminary testing with it, and it seems to be exactly what I need.
Typing:
wmic process where name=”calc.exe” get commandline
at the commandline prompt gets me the commandline string that started the calculator.
I’m testing on a 64 bit system.
Thank you for your excellent suggestion on this alternate way to resolve the problem!
i know this is old , but its the only explaination i got to this problem, and i want to point a workaround for the use of GetProcessImageFileName…
what i did is get all drive letters using GetLogicalDriveStrings , and then get their device path with QueryDosDevice (search both on msdn) , after that i parsed the paths i got from GetProcessImageFileName and replace the \Device\HarddiskVolumeX with their respective drive letters.
thanks for the article , and excuse my poor english.
I just ran across this. For others who are looking for an answer use “QueryFullProcessImageName”. This will give you the Win32 path format
Great article! I have an idea, how about they fix their API? 🙂
Finally, an explanation! (thumbsup)
Now I know why my InnoSetup installer app (32-bit) wouldn’t be able to enumerate process handles/files in use on Windows x64.