0

I know that there are lots of questions like this as it is a common error, I also know it is happening because I am using unicode. However, after reading through SO/microsoft docs and fixing the code, it still does not seem to work and I am stumped.

The code is as follows:

#include <Windows.h>
#include <Tlhelp32.h>
#include <string>

DWORD find_pid(const char* procname) {
// Dynamically resolve some functions
    HMODULE kernel32 =    GetModuleHandleA("Kernel32.dll");

    using CreateToolhelp32SnapshotPrototype = HANDLE(WINAPI *)(DWORD, DWORD);
    CreateToolhelp32SnapshotPrototype CreateToolhelp32Snapshot = (CreateToolhelp32SnapshotPrototype)GetProcAddress(kernel32, "CreateToolhelp32Snapshot");

using Process32FirstPrototype = BOOL(WINAPI *)(HANDLE, LPPROCESSENTRY32);
Process32FirstPrototype Process32First = (Process32FirstPrototype)GetProcAddress(kernel32, "Process32First");

using Process32NextPrototype = BOOL(WINAPI *)(HANDLE, LPPROCESSENTRY32);
Process32NextPrototype Process32Next = (Process32NextPrototype)GetProcAddress(kernel32, "Process32Next");

// Init some important local variables
HANDLE hProcSnap;
PROCESSENTRY32 pe32;
DWORD pid = 0;
pe32.dwSize = sizeof(PROCESSENTRY32);

// Find the PID now by enumerating a snapshot of all the running processes
hProcSnap = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
if (INVALID_HANDLE_VALUE == hProcSnap)
    return 0;

if (!Process32First(hProcSnap, &pe32)) {
    CloseHandle(hProcSnap);
    return 0;
}

while (Process32Next(hProcSnap, &pe32)) {

//--->here is offending code...

       if (lstrcmpiA(procname, pe32.szExeFile) == 0) {
        pid = pe32.th32ProcessID;
        break;
    }
}

// Cleanup
CloseHandle(hProcSnap);

return pid;
}

I changed the code to this:

 if (strcmp(procname, pe32.szExeFile) == 0) {
        pid = pe32.th32ProcessID;
        break;
    }

but still get the same error. Any ideas?

timetosleep123
  • 15
  • 2
  • 1
    If you are using Unicode, `procname` would have to be `wchar_t*` to match the type of the returned strings. – BoP Dec 04 '21 at 10:19
  • That's a lot of code for a compilation error. Your [mre] does not need to be functional (in fact, it cannot be since it will not compile); it just needs to be syntactically complete enough so that the error you ask about is the first error reported by the compiler. See how many lines of code you can eliminate without losing the error message. – JaMiT Dec 04 '21 at 10:28
  • Hi everyone, thanks for the input. I am a little confused Majo, how would I go about fixing this. I tried changing (const char* procname) to (const wchar_t* procname) and also (const tchar* procname) but that resulted in cannot convert argument 1 from 'const _Elem *' to 'const wchar_t *'. If anyone could give me a working code example and why that works it will be helpful as the more I read, the more confused I am getting. thanks – timetosleep123 Dec 04 '21 at 21:33

1 Answers1

1

PROCESSENTRY32 uses wchars when you define UNICODE. The doc's are probably misleading. Tlhelp32.h defines this:

#ifdef UNICODE
#define Process32First Process32FirstW
#define Process32Next Process32NextW
#define PROCESSENTRY32 PROCESSENTRY32W
#define PPROCESSENTRY32 PPROCESSENTRY32W
#define LPPROCESSENTRY32 LPPROCESSENTRY32W
#endif  // !UNICODE

As you can see, PROCESSENTRY32 maps to PROCESSENTRY32W if UNICODE is defined.

pe32.szExeFile is a WCHAR szExeFile[MAX_PATH]; // Path

That is the reason why strcmp fails with the error you get. strcmp expects a char* but you pass pe32.szExeFile, which in your case is a WCHAR*.

Take real care to get the correct pointers to the helper functions. Are you getting the ANSI or UNICODE pointers? You are using a lot of C-style casts in the GetProcAddress calls. You can easily end up casting the return value to an ANSI style function, but using the UNICODE style pointer type.

Hajo Kirchhoff
  • 1,969
  • 8
  • 17
  • Someone reading https://learn.microsoft.com/en-us/windows/win32/api/tlhelp32/ns-tlhelp32-processentry32 would indeed be caught by this. There is a warning about this on the page for the wide version, but not for the non-wide version. – Passerby Dec 04 '21 at 10:28