XP 64-bit | Entry Point Not Found | KERNEL32.dll

CyrodiilWarrior

Active Member
Joined
Oct 9, 2023
Messages
4
Hello forum,

I have an old 'retro' machine with Windows XP 64-bit installed, for some old games.

One issue I have ran into when trying to launch specific games is the following:
"NAME.exe - Entry Point Not Found"
"The procedure entry point K32GetModuleInformation could not be located in the dynamic link library KERNEL32.dll."

I wasn't sure about the issue and a possible fix. I've used unofficial utility 'Legacy Update' to update Windows XP 64-bit. I wasn't sure that since the PC is of 64-bit architecture, that could be the source of some issues.

Any suggestions/solutions?
 

Solution
Hello CyrodiilWarrior,

Setting up a shim (or wrapper) DLL can seem intimidating at first, but the core idea is to create a small DLL that “fills in” the missing function by forwarding the call to its equivalent in another library (in this case, PSAPI.dll). Here’s an outline of how you might tackle this:

  • 1. Understand the Goal:
      The game is calling K32GetModuleInformation – a function that isn’t exported from Windows XP 64-bit’s Kernel32.dll. However, the comparable functionality is available as GetModuleInformation in PSAPI.dll. The shim DLL will export K32GetModuleInformation and simply forward its parameters to PSAPI.dll’s GetModuleInformation.
  • 2. Set Up a Development Environment:
      You’ll need a C/C++...
Hello CyrodiilWarrior,
The error message you’re seeing –
"The procedure entry point K32GetModuleInformation could not be located in the dynamic link library KERNEL32.dll."
– indicates that the game is trying to call a function (K32GetModuleInformation) that isn’t exported by the Windows XP 64-bit version of Kernel32.dll.
Why does this happen?
In newer versions of Windows (starting with Windows Vista/7), Microsoft started exporting K32GetModuleInformation directly from Kernel32.dll. In earlier systems like Windows XP (both 32‑ and 64‑bit), the equivalent functionality is provided by PSAPI.dll via its GetModuleInformation function. In other words, your game (or its libraries) is expecting a function signature that simply isn’t available on XP 64-bit in Kernel32.dll.
What can you do about it?
There are a few approaches you can consider:

  • []Use a “shim” or wrapper DLL:
      You can create or locate a pre-made wrapper DLL that exports K32GetModuleInformation. This DLL would forward the call to PSAPI.dll’s GetModuleInformation. Once you have this DLL (often available on retro or enthusiast forums), place it in the same directory as your game’s executable. This tells the game to load your custom DLL instead of relying on the system’s Kernel32.dll.
    [
    ]Patch the executable’s import table:
      For advanced users, it’s possible to modify the game’s executable using tools like CFF Explorer or Dependency Walker. In this method, you’d change its import reference from Kernel32.dll’s K32GetModuleInformation to PSAPI.dll’s GetModuleInformation. Be advised that modifying executable files can be risky and might break other functionalities or violate terms of use.
  • Switch to a 32‑bit environment:
      Many legacy games were designed for the 32‑bit version of Windows XP where these mismatches were less likely. If feasible, installing 32‑bit Windows XP (or running a virtual machine with the 32‑bit OS) could resolve the issue without any tweaks, as the 32‑bit libraries are more likely to match what the game expects.
Additional Tips:
  • Before attempting any fixes, make sure you have backups of your original files (both the executable and any DLLs you modify or replace).
  • Note that the unofficial “Legacy Update” you mentioned may update various components but might not address this particular API mismatch since the missing function is inherent in XP 64-bit’s Kernel32.dll API set.
  • Use tools like Dependency Walker to identify exactly which DLL and function calls are failing. Similar “entry point not found” errors (for example, issues with diskshadow.exe on mismatched DLLs discussed by other community members) show that these kinds of errors are common when legacy software’s expectations don’t match the underlying OS capabilities.
While no single official fix exists for this situation, many retro computing enthusiasts have successfully used the shim DLL method to run such games on Windows XP 64-bit. A quick search online using keywords like “K32GetModuleInformation wrapper XP64” might lead you to a community-developed solution.
I hope this helps clarify what’s happening and gives you a path forward. Feel free to ask if you have any further questions or need more detailed guidance on any of these steps.
Happy gaming,
ChatGPT
 

How does someone do the “shim” or wrapper DLL method, for example? I'm not an advanced user but it would be easier to use a method than install Windows XP 32-bit as well.
 

Hello CyrodiilWarrior,

Setting up a shim (or wrapper) DLL can seem intimidating at first, but the core idea is to create a small DLL that “fills in” the missing function by forwarding the call to its equivalent in another library (in this case, PSAPI.dll). Here’s an outline of how you might tackle this:

  • 1. Understand the Goal:
      The game is calling K32GetModuleInformation – a function that isn’t exported from Windows XP 64-bit’s Kernel32.dll. However, the comparable functionality is available as GetModuleInformation in PSAPI.dll. The shim DLL will export K32GetModuleInformation and simply forward its parameters to PSAPI.dll’s GetModuleInformation.
  • 2. Set Up a Development Environment:
      You’ll need a C/C++ compiler – Microsoft Visual Studio (even the free Community Edition) works well. Create a new DLL project and configure it as a 64-bit build (matching your OS and game).
  • 3. Write the Shim Code:
      Below is an example of what the C++ code might look like. This snippet defines the missing function and forwards the call:

    Code:
    #include <windows.h>
    #include <psapi.h>
    
    // Minimal DllMain - required for a DLL
    BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpReserved)
    {
        return TRUE;
    }
    
    // Exported function that mimics K32GetModuleInformation
    extern "C" __declspec(dllexport) BOOL WINAPI K32GetModuleInformation(
        HANDLE hProcess,
        HMODULE hModule,
        LPMODULEINFO lpmodinfo,
        DWORD cb)
    {
        // Load PSAPI.dll dynamically
        HMODULE hPSAPI = LoadLibrary("psapi.dll");
        if (!hPSAPI)
            return FALSE;
            
        // Get the address of GetModuleInformation in PSAPI.dll
        typedef BOOL (WINAPI *PFNGETMODULEINFORMATION)(HANDLE, HMODULE, LPMODULEINFO, DWORD);
        PFNGETMODULEINFORMATION pGetModuleInformation = (PFNGETMODULEINFORMATION)GetProcAddress(hPSAPI, "GetModuleInformation");
        if (!pGetModuleInformation)
            return FALSE;
            
        // Forward the call
        return pGetModuleInformation(hProcess, hModule, lpmodinfo, cb);
    }
  • 4. Compile the DLL:
      Once your code is in place, compile the DLL in 64-bit mode. You should get a file (for example, ShimDLL.dll) containing your shim.
  • 5. Getting Your Game to Use the Shim:
      This is the trickiest part because the game is looking for the missing function from Kernel32.dll (a critical system DLL). There are a couple of approaches:

      

    •    
    • Modify the game’s import table:
           Tools like CFF Explorer (or similar) can let you edit which DLL the game imports a function from. In this case, you could change the entry for K32GetModuleInformation so that it points to your shim DLL (e.g., “ShimDLL.dll”) rather than to kernel32.dll.

         
    • DLL Redirection:
           On Windows XP, some applications support a “local DLL” override using a file named GameName.exe.local (placed in the same folder as the executable). This tells Windows to load DLLs from the local folder first. However, note that system DLLs like Kernel32.dll are usually protected and may not be overridden this way; that’s why modifying the import table is often needed.
        

      Be aware that editing the import table should be done with caution and only after backing up the original executable.
  • 6. Testing and Caution:
      Before using the modified executable, test it on your system. Creating a shim involves modifying low-level behavior, so it’s essential to have backups of the original files. If things don’t work as expected, you can always restore your original setup.
  • 7. Alternative Options:
      If you’re not comfortable with building your own DLL or patching the game’s import table, check community forums or retro computing websites. Sometimes enthusiasts in these communities have already created and shared precompiled shim DLLs for problems just like this.

Even though the process might sound “advanced,” breaking it down into these steps can make it more manageable. Feel free to ask more questions or for clarification on any step!

Happy retro gaming,
ChatGPT
 

Solution
Back
Top