Question:
How can I find the name of the program file (EXE) associated with another process? I've tried various combinations of GetModuleFileName, GetModuleInstance, and GetModuleHandle, but nothing seems to work.
Answer:
Download the code for this article: CQA0207.exe (72KB)
The problem with these calls is that they work only for modules loaded within the current running process, not modules in a different process. For that, you need something else, and here the road forks. If you're writing for Windows NT® 4.0, Windows 2000, or Windows XP, you can use PSAPI, a relatively new DLL with functions to get information about processes and modules. If you're writing for Windows 95, Windows 98, or Windows Me, you'll have to use ToolHelp. Since I'm so modern, I'll show you how to do it the PSAPI way. For help with ToolHelp, see Article Q175030, "HOWTO: Enumerate Applications in Win32" on MSDN®.One of the functions in PSAPI is GetModuleFileNameEx. It takes a process and module handle and gets the name of the module. How do you know which module in a process is the EXE that started it? There's another PSAPI function, EnumProcessModules, that stuffs an array with module handles for all the modules in a process. The first entry is always the main module, so you can write
DWORD count;to get the first HMODULE, then call GetModuleFileNameEx. To show how it works in practice, I wrote a little program, lp, that lists processes with their module names and main windows (see Figure 2 ). Figure 3 shows a sample run. (Note that Windows Explorer and Outlook both have two "main" windows.)
HMODULE hm[1];
EnumProcessModules(hProcess, hm, 1, &count);

Figure 3 Sample Run
The lp program uses a third PSAPI function, EnumProcesses, to enumerate all the running processes, but following the same idea as CWindowIterator and CMainWindowIterator from the previous question, I encapsulated the gory aspects of EnumProcesses and EnumProcessModules in two iterator classes, CProcessIterator and CProcessModuleIterator .With these classes in hand, lp is pretty straightforward. To iterate the processes, try the following:
CProcessIterator itp;And here's how to get the name of the EXE that created the process:
for (DWORD pid=itp.First(); pid; pid=itp.Next()) {
// handle each process
}
CProcessModuleIterator itm(pid);
HMODULE hModule = itm.First(); // .EXE
TCHAR modname[_MAX_PATH];
GetModuleBaseName(itm.GetProcessHandle(),
hModule, modname, _MAX_PATH);


Process[] procs = Process.GetProcesses();
int len = procs.GetLength(0);
for (int i=0; i<len; i++) {
Process p = procs[i];
if (p.Id!=0) {
int hwnd = p.MainWindowHandle.ToInt32();
if (hwnd!=0) { // if has a main window:
ProcessModule pm = p.MainModule;
String modname = pm.ModuleName;
•••
}
}
}

Update

class D : public B {
public:
virtual void test(int x) {
B::test(x); // call base explicitly
}
};

class D : public B {This brings B::test into the scope of D. It has the advantage that you don't have to rewrite D if someone expands B with more overloaded test functions. Not to mention it requires less typing! When you use using, all overloaded B::test functions come into D's scope and are thus inherited. This may be an advantage or disadvantage, depending on what you're trying to do. If you want to keep some test functions hidden from consumers of D, you can use my first method (call base explicitly), or make the functions you want to hide private or protected. If you read Scott's book More Effective C++ (Addison-Wesley, 1995), you'll learn on pages 143-144 that you can even use using to circumvent the privacy of base classes.
public:
using B::test;
// other test overrides
};
class B { // some classThis trick is expedient when B should properly be hidden, but has one or two functions you want to expose. All of which goes to prove that in C++, there's never only one way to skin a cat.
public:
func1();
func2(double d);
virtual test();
virtual test(int x);
};
// D is privately derived from B
class D : private B {
public:
// make all B::test fns public!
using B::test;
};
