How would one get the base address of a module in a x64 process from a x86(32bit) app. i have no problem getting the process id with NtQuerySystemInformation but CreateToolhelp32Snapshot and EnumProcesses both fail to get the x64 process modules, are there any other ways to do this like any undocumented functions im missing?
You can achieve this by parsing PEB structure. It's undocumented but it's not changing between systems: http://www.nirsoft.net/kernel_struct/vista/PEB.html
Interesting part for you is PEB->Ldr->InLoadOrderModuleList.
Related
How do I know in a windows program if a process is running if I only know the exe file name ?
The process in question is TeamSpeak3 ts3client_win64.exe for 64 bit and ts3client_win32.exe for 32 bit.
I am using C++
Use the CreateToolhelp32Snapshot function to create a snapshot of the current process table, then use the Process32First and Process32Next functions to iterate the snapshot. You can get the name for each executable file by looking at the szExeName field of the PROCESSENTRY32 structure.
See the MSDN example for a sample of how to use these functions.
The advantage of this approach is that, unlike any EnumProcesses-based solution, it doesn't suffer from race conditions: with EnumProcesses it can happen that a process gets destroyed after you finished enumerating the processes but before you got around to opening the process (or reading our the process executable name).
You can use a combination of EnumProcesses, OpenProcess, and GetModuleFileNameEx (or alternatively, QueryFullProcessImageName for Vista or later). MSDN even has an example.
Windows NT has several APIs for enumerating processes.
EnumProcesses
ToolHelp
NtQuerySystemInformation (discouraged)
WMI's Win32_Process (works remotely)
My app uses LoadLibrary to load plugins at run-time and users can accidentally try to load 64 bit plugins in the 32 bit version of my application.
It looks like the error code returned from LoadLibrary is not very descriptive (says "%1 is not a valid Win32 application").
I am looking for ways to figure out if the plugin dll file is built 32 or 64 bit so that I can notify the user in a user friendly way.
Any ideas?
In order to retrieve information about an image such as the one you are looking for, just use the ImageHelp API
My program dynamically loads a number of DLL's using LoadLibrary and (on literally all machines) these load successfully, on one machine some of these DLL's do not get loaded. I added code to trace lasterror and this reports "0x43 The network name cannot be found.".
The machine in question is running Windows 7 Enterprise x64, the DLL is a 32 bit DLL, this shouldn't be an issue and (in fact) this is my development environment.
I also tried converting the name of the DLL (which includes the path) to a short filename and used that in the call to LoadLibrary, I still got the same error.
Any ideas?
//*eggbox
Download Procmon let it run and filter for you dll name. This will immediately give you the locations where the dll was searched and which access path did return 0x43.
You get even the call stacks if you have the pdbs for your code as well (C/C++ only no managed code).
Run the program through Dependency Walker in its Profile mode and let that fine tool tell you exactly what is going wrong.
To construct a process tree in Windows "C" given a PID, which one is a good approach to go for Win2k, XP, Windows Server 2008, Windows 7.
ZwQuerySystemInformation
NtQuerySystemInformation
CreateToolhelp32Snapshot
I remember ToolHelp had issue in leaking memory for win2k. Please correct me if I am wrong.
And using ZwQuerySystemInformation/NtQuerySystemInformation, I am not sure what the // System Information Class 5 structure should be for 64-bit architecture. Can someone provide pointers to it?
-Karthik
Off the top of my head, the documented ways to list processes include:
WTSEnumerateProcesses (Must delayload, call will fail if Terminal Services/Fastuserswitching is off)
EnumProcesses (Only a list of PID's)
CreateToolhelp32Snapshot
Performance Counters
WMI
I am having a problem with windows system function “EnumProcessModules()” that is defined in psapi.dll. In our component we use this function to retrieve modules in a specified process. This function is working well as long as we run the program on a 32-bit OS. However, this function fails when we run the program on a 64-bit OS (e.g. W2K8 R2). As you all know we are targeting Clay and Brick on W2K8 R2s. This is a known problem as per the following discussion in MSDN. One work around that was suggested in that thread is to compile the code as 64-bit. To us that is not an option, at least not yet. Do you have any suggestions? Any pointers/suggestions/ideas will be appreciated.
http://social.msdn.microsoft.com/forums/en-US/winserver2008appcompatabilityandcertification/thread/c7d7e3fe-f8e5-49c3-a16f-8e3dec5e8cf8/
If your existing code must continue being compiled as 32-bit, one possibility would be to create a small 64-bit executable that enumerates the processes via EnumProcessModulesEx. The 32-bit process could spawn the 64-bit process when necessary to do that work. Then use some kind of IPC to transfer the information back to the 32-bit process. Depending on what is needed, that part could be as low tech as writing a file to disk and reading it from the first process (or pipes, shared memory, sockets, etc.).