Question THE FINALS — EAC Process ID Capture Issues & FindWindow Fails

[byte_corvus]

Ran into a brick wall trying to grab the PID for THE FINALS.

I was digging into the process to set up a basic external, but standard WinAPI calls are coming up empty. Usually, a quick FindWindow or process name lookup does the trick for most titles, but EAC seems to be playing games with the window handles or masking the process visibility entirely.

I suspect we're looking at handle stripping or some specific window protection that's preventing standard user-mode tools from hooking in. Here is the snippet that's currently failing to return anything useful:

DWORD PID(const std::wstring& windowName)
{
    HWND hwnd = FindWindow(nullptr, windowName.c_str());
    if (hwnd == nullptr) {
        std::wcerr << L"Can not found the window: " << windowName << std::endl;
        return 0;
    }
    DWORD processId = 0;
    GetWindowThreadProcessId(hwnd, &processId);
    return processId;
}

Even when attempting to iterate by process name, it's like the game is shielded. Easy Anti-Cheat often hooks these common APIs to return null or invalid handles for protected windows. If you're trying to build a stable external for this, relying on FindWindow is a rookie mistake when dealing with PROCESS_QUERY_INFORMATION stripping.

Technical Considerations:

1. EAC may be utilizing protected windows to hide the process from standard EnumWindows calls.
2. Check if your tool is running with elevated privileges; even then, EAC's kernel-level driver usually wins the handle race.
3. Consider switching to CreateToolhelp32Snapshot for process iteration or just drop into kernel if you want to bypass these handle protections properly.

Anyone else noticed EAC masking the window class lately, or did they just push a sneaky update to their handle protection logic?

Drop your findings below.