Home/ Questions/Q 39671
In Process

askthedev.com Latest Questions

Asked: 2025-06-12T22:14:17+05:30

Why does GameInputCreate return E_NOTIMPL on one Windows 10 machine but not another with identical setups?

I’ve hit a snag with a project I’m working on, and I hope someone in the community can shed some light on this weird issue I’m facing. I’ve got two test machines, and they’re both running Windows 10 version 22H2. I’ve set them up to be as identical as possible, right down to the hardware specifications and software installations. However, there’s this frustrating discrepancy when I run my input initialization code using the GameInput API.

Here’s the crux of the problem: on one machine, everything works like a charm. I call `GameInputCreate`, and it sets up the input interface without any hassle. But on the other machine, it just doesn’t like me. Instead of initializing properly, it throws back `E_NOTIMPL`— which, let’s be honest, doesn’t tell me a whole lot. It’s like hitting a brick wall with no explanation.

I’ve made sure to grab the latest GameInput NuGet package and even installed the GameInput redistributable on both machines, so that shouldn’t be the issue. I’ve double-checked the project settings, and they line up perfectly on both ends. I even went as far as to check for any missing dependencies or updates in the Windows settings, but everything looks up to date.

Now, I can’t help but wonder if there are deeper systemic issues at play here. Is it possible that there’s a configuration or a driver issue that’s specifically affecting only one of the machines? Maybe there’s a hidden setting in the registry or a conflicting software that I’m overlooking?

I’d love to hear if anyone else has run into similar situations or if you have any troubleshooting tips that might help narrow this down. This is driving me nuts, and I could use all the wisdom from the community to figure it out! Any insights would be really appreciated!

Share

    Leave an answer

    You must login to add an answer.

    Need An Account,

    2 Answers

    1. It sounds super frustrating to deal with that kind of inconsistency between two identical machines. Here are a few things you might want to try or check:

      • Check the Windows Features: Sometimes, specific features or components in Windows can have unexpected restrictions or configurations. Make sure that both machines have the same Windows features enabled.
      • Look at Device Manager: Even if the hardware is the same, check if there are any driver issues or differences in settings in Device Manager. Sometimes, one machine might have a newer or older driver installed.
      • Environmental Variables: There might be path issues or environmental variable differences between the two systems. It could be worth looking into them to see if there’s anything that stands out.
      • Check for Conflicting Software: Sometimes, other software can interfere. Check if there’s anything running on the machine where it’s failing that could be causing issues, like game-related overlays or different input software.
      • Isolate the Problem: Try creating a very minimal application that uses `GameInputCreate` with no other dependencies to see if it still throws the same error. This could help identify if it’s something in the broader project setup or just specific to the GameInput API calls.

      If you haven’t already, you might also want to dig into the Event Viewer for any related logs or errors that might give you more context. Good luck, and I hope you get it sorted out!

    2. The GameInput API returning E_NOTIMPL typically indicates that the method you’re calling isn’t implemented on that specific system or isn’t recognizing an essential pre-condition. Since both your machines are practically identical in terms of software and hardware, it’s possible there’s a subtle variation in installed drivers, security software, or even Windows components. I’d first recommend using tools such as Dependency Walker or Process Monitor to compare the working and non-working environments closely. Pay particular attention to DLL calls or OS-level differences that could be causing the issue.

      Another avenue worth checking is the DirectX and graphics driver status, as underlying interaction differences could trigger such discrepancies. Try reinstalling graphics and input-related drivers completely, or check if additional optional SDK components—perhaps DirectX SDK or varying versions of Visual C++ redistributables—exist on the working machine. Lastly, dive deeper into the registry using Registry Editors like RegEdit or ProcMon for hidden configuration entries. Comparing system snapshots of working vs non-working setups often uncovers hidden mismatches not readily visible through standard checks.