The 32-bit program fails to call GetModuleFileNameEx on the 64-bit system.

From: http://blog.csdn.net/anycell/archive/2008/12/12/3505864.aspx

I encountered the same problem two days ago.

-------------------------------------------

Today, the customer called to say that our company's server programs could not be started as a system service on the newly installed 64-bit Windows 2003. We initially suspect that our 32-bit service programs are not compatible on 64-bit machines. As a result, I got busy all morning and finally found the problem. A piece of code in the program is used to determine whether the program is started as a service or as a window: Get the handle of the parent process during application initialization. Then, the full path of the execution program of the parent process is obtained through the handle. If the "service.exe" string exists in the full path, the program starts as a service. The pseudocode is as follows:

1. HANDLE hParentProc; // Parent proccess handle initialize
2. BOOL bRet; // Check if we shoshould run it as service
3. If (GetModuleFileNameEx (hParentProc, NULL, pszPath, MAX_PATH ))
4. {
5. If (strstr (pszPath, "services.exe ")! = NULL)
6. {
7. BRet = TRUE;
8. }
9. }

Debugging shows that the problem lies in the getmodulefilenameex function. Originally, it returned the length of the full path, and the result returned 0 on a 64-bit machine. The pszpath variable did not get the full path of the parent process. I use getlasterror () to view the returned value as error.
299 -- "only part of a readprocessmemory or writeprocessmemory request was completed .". I started to suspect that the 32-bit program encountered a problem when calling the API to process the 64-Bit Memory Address.
So I googled and finally found the answer:
When we call the getmodulefilenameex API function, in order to obtain the full path of the specified process, it needs to access the peb header (process environment block) of the process internally and set the information in peb toPROCESS_BASIC_INFORMATION. The struct declaration is as follows:

1. Typedef struct _ PROCESS_BASIC_INFORMATION {
2. NTSTATUS ExitStatus;
3. PPEB PebBaseAddress;
4. ULONG_PTR AffinityMask;
5. KPRIORITY BasePriority;
6. ULONG_PTR UniqueProcessId;
7. ULONG_PTR InheritedFromUniqueProcessId;
8. } PROCESS_BASIC_INFORMATION;

The PEB address is set in PebBaseAddress. However, the 64-bit pebheader address is a 64-bit long address (specifically, the system entry services.exe), while the 32-bit process's PEB header address is only 32-bit in length. How does a 32-bit application run on a 64-bit system convert a 64-bit PEB address to a 32-bit address? If the 64-bit PEB address has a high 32-bit value of 0, the conversion will not cause any problems. However, if the 32-bit high also contains the address information, then WOW64 (Windows
32-bit on Windows 64-bit, which is compatible with 32-bit applications on windows 64-bit systems, and serves as a transitional solution from 32-bit to 64-bit programs) simply assign the low 32-bit PEB address to the PebBaseAddress variable in the 32-bit application. Of course, an error will occur! Therefore, Windows will start error 299 and return failure.
If your 32-bit application runs on Windows XP or a later operating system, the recommended solution is to use GetProccessImageFileName instead of GetModuleFileNameEx to obtain the full path of the process, the internal operation of this function is not as troublesome as GetModuleFileName, but only returns a full path string. However, the full path returned is the drive letter path in DOS format (
/Device/HarddiskVolumeX), so you need to convert it yourself.
Besides GetModuleFileNameEx, EnumProcessModule andEnumProcessModuleEx also causes this problem because it accesses the PEB header of a 64-bit process. The cause of createconlhelpsnapshot call failure is similar to the above principle.
Reference: http://winprogger.com /? P = 26