Games Freeze or Close Without Warning After Windows 11 KB5121003: Check inpoutx64.sys First

If a game began freezing mid-session, closing without a message, or taking the whole machine down with it shortly after 11 August 2026, the fastest useful check is not inside the game at all. It is whether the file C:\Windows\System32\drivers\inpoutx64.sys exists on the system, and if it does, which utility put it there. Stopping the service that loads that driver is reversible in seconds. Deleting the file is not, and it silently breaks the fan-control, lighting, or tuning application that depends on it.

Do this first, in this order

1. Confirm the build. Run winver. The affected cumulative update produces OS build 26100.9168 on Windows 11 24H2 and 26200.9168 on Windows 11 25H2.
2. Check whether the driver file is present at C:\Windows\System32\drivers\inpoutx64.sys. If it is absent, the reports discussed below do not describe this machine, and the search should move elsewhere.
3. If it is present, identify the service that loads it and stop that service. Do not delete anything yet.
4. Launch the game that was failing and reproduce the exact scenario that broke.
5. Only if stopping the service changes the outcome, decide between updating the owning utility, removing the owning utility, or removing the driver file.

That ordering matters because the reported trigger sits in third-party kernel-mode code, not in the game and not necessarily in the update. Microsoft's own note on the update says only that it is investigating to determine whether this is an issue caused by Microsoft. That is not an admission of cause. It is an open question, and the sequence above is written so that nothing irreversible happens while the question is still open.

Symptoms that match this pattern

The reports gathered between 16 and 20 August 2026 cluster into a recognizable shape. A machine belongs to this cluster when several of the following appear together, not when one appears alone.

• A game freezes completely while the rest of the desktop stays responsive, and the process has to be ended manually.
• A game closes to the desktop with no error dialog, no crash reporter, and no message in the launcher.
• A crash log or crash window reports EXCEPTION_ACCESS_VIOLATION.
• A crash window reports Hang detected on GameThread.
• The entire system restarts without warning during play, with no blue screen visible long enough to read.
• The display refresh rate drops on its own, or the screen goes black for several seconds, or HDR output behaves incorrectly during or after a session.

Titles named in the public reports include ARC Raiders, The Finals, and MARVEL Tokon: Fighting Souls. That list is not a boundary. It reflects which communities reported loudly and early, and the underlying pattern is not specific to a genre or an engine.

Symptoms that do not match

Several failure modes look similar from the player's seat but belong to different causes. A game that fails at launch and never draws a frame, a game that stutters continuously without ever crashing, a machine that restarts while idle rather than during play, or a fault that predates 11 August 2026 all point elsewhere. So does a machine on a build number other than the two listed above.

Confirming the build before changing anything

Two commands settle the question. winver opens a small window that names the version and the OS build in one line. systeminfo, run in Command Prompt or PowerShell, prints the OS version alongside the list of installed hotfixes, which is useful when the update history in Settings has been cleared or the machine was imaged.

The relevant identifiers for the August 2026 release are these.

Update	KB5121003, released 11 August 2026
Windows 11 24H2 build	26100.9168
Windows 11 25H2 build	26200.9168
Servicing stack update shipped alongside	KB5123304, build 26100.9156
Known-issue entry added	20 August 2026, describing reports of certain games becoming unresponsive

The servicing stack update deserves a separate note because it changes what is possible later. A servicing stack update is not removable through the normal uninstall path. If the cumulative update is eventually rolled back, KB5123304 stays where it is. That is expected behaviour and not a sign that the rollback failed.

What the reports actually point at

The file named across the public reports is inpoutx64.sys. It is a third-party kernel-mode driver that provides direct port access on 64-bit Windows. It is not a Microsoft component and it does not arrive with Windows. It arrives bundled inside utilities that need to talk to hardware below the level the normal driver stack exposes, which in practice means fan-control panels, RGB lighting suites, and overclocking or tuning tools shipped by board and peripheral vendors.

That bundling explains why the symptom set feels arbitrary. Two machines with identical hardware and identical Windows builds behave differently because one of them has a lighting utility installed and the other does not. It also explains why the failure lands on the game: a kernel-mode driver that faults does not produce a tidy application-level error. It produces an access violation inside whichever process was running, a hung render or game thread, or a restart with nothing readable left behind.

One studio, Embark Studios, published interim guidance directing affected players to stop and remove the associated service and to remove the driver file from C:\Windows\System32\drivers\. That guidance is real and it works for the people it was written for. It is also the last step of the sequence in this article rather than the first, for reasons the next section covers.

Tracing the driver back to its owner

Before anything is stopped or removed, it is worth knowing what is being touched. Three checks, run from an elevated PowerShell window, produce enough to work with.

Confirm the file exists and record its identity

• Get-ChildItem C:\Windows\System32\drivers\inpoutx64.sys returns the file with its size and last-write time. An empty result ends the investigation here.
• Get-FileHash C:\Windows\System32\drivers\inpoutx64.sys records a hash. Keeping that value in a note makes it possible to tell later whether a reinstalled utility replaced the file with a different version or restored the same one.

Find the service that loads it

• Get-CimInstance -ClassName Win32_SystemDriver | Where-Object { $_.PathName -like "*inpoutx64*" } returns the driver service entry, including its service name, display name, current state, and start mode.
• driverquery /v /fo list prints every installed driver with its link date and start mode, which is useful when the previous query returns nothing because the driver is loaded by a process rather than registered as a service.
• Once the service name is known, sc query <servicename> shows whether it is currently running.

Find the application that installed it

Open Settings > Apps > Installed apps and look for hardware utilities from the motherboard vendor, the case or cooler vendor, and any peripheral suite that controls lighting. Sorting the list by install date narrows it further. A tuning or lighting suite installed months ago and forgotten is the usual owner, because these drivers persist after the application that placed them has been closed for good.

Read what Windows recorded at the moment of failure

Open Event Viewer and work through two logs. Under Windows Logs > Application, entries written at the timestamp of the crash usually name the failing executable and module. Under Windows Logs > System, an unexpected restart leaves an entry from the Kernel-Power source recording that the shutdown was not clean. Neither entry will name the third-party driver directly, but the timestamps establish whether the failures cluster around game sessions or appear at random, which is the difference between this pattern and a thermal or power-supply fault.

The fix, ordered from reversible to permanent

Each step below is reversible until the last two. Test the game after each one and stop at the first step that resolves the failure.

1. Stop the driver service. With the service name from the query above, run sc stop <servicename> from an elevated prompt. Nothing is deleted; a restart brings the service back if its start mode is automatic. Launch the game and reproduce the scenario that failed.
2. Close the owning utility completely. Some of these suites keep a tray process that reloads the driver on demand. Exiting from the tray icon, not just closing the window, is what actually releases it.
3. Set the service start mode to disabled through the Services console. Open services.msc, find the entry by its display name, and change Startup type. This survives a restart and is undone by setting the value back.
4. Update the utility. Vendors respond to this class of problem with a driver revision far more often than users expect. An updated build that replaces inpoutx64.sys with a newer file is the outcome that keeps the utility working.
5. Uninstall the utility from Settings > Apps > Installed apps. This is the step the studio guidance effectively describes, taken through the supported path, and it is undone by reinstalling.
6. Rename rather than delete the driver file if the utility's uninstaller leaves it behind. Renaming inpoutx64.sys to inpoutx64.sys.bak in the same folder, from an elevated prompt with the service stopped, has the same effect as deletion and can be reversed by renaming it back. Deleting it outright cannot.
7. Uninstall the cumulative update only after the steps above have been tried. It is removed from the update history in Windows Update, and the exact route differs enough between builds that it is worth confirming against the Microsoft documentation for the build reported by winver. Removing KB5121003 also removes the security content shipped on 11 August 2026, and the servicing stack update KB5123304 remains installed regardless.

If step 7 is taken, pausing updates in Windows Update so the same package does not reinstall overnight, and set a calendar reminder for the date the pause expires. An indefinitely unpatched machine trades one problem for a worse one.

Where this trail goes cold

This framing explains a specific cluster of machines and no more. Several conditions place a machine outside it, and following the steps above anyway costs time and can cost a working utility.

• The driver file is absent. Plenty of machines running 26100.9168 or 26200.9168 have no third-party port-access driver at all. Crashes on those machines share a date with this pattern and nothing else. Graphics driver revisions, shader cache corruption after a title update, and anti-cheat components updated the same week are all more likely candidates.
• The failure predates 11 August 2026. Update history in Settings gives the exact installation date. If the first crash came before it, the update is coincidence.
• Stopping the service changes nothing. That is a real answer, not a failed attempt. Restart the service, restore the start mode, and stop treating the driver as the suspect.
• The symptoms are display-side only. Refresh rate dropping, black screens, and HDR misbehaviour were reported in the same window but are not evidence of the same mechanism. A machine showing only these, with no freezes or exits, is a separate report that happens to share a month.
• No cause has been confirmed. The KB article records reports and an ongoing investigation, not a determination. Any explanation that walks past that, including the one above, is a working hypothesis that a future update may replace outright.
• Managed devices are a different problem. On a machine where updates arrive through an organisation's management tooling, uninstalling a cumulative update locally is usually undone at the next sync, and the driver may have been deployed deliberately.

Keeping the next cumulative update from doing this

The recurrence problem here is not really about one KB number. It is that kernel-mode drivers installed by convenience utilities outlive the utilities themselves and keep loading at boot years later, and a Windows servicing change can turn a dormant one into a crash source overnight.

• Inventory what loads at kernel level once, then leave the list somewhere findable. driverquery /v /fo list redirected to a text file gives a baseline. Re-running it after a problem and comparing is faster than starting an investigation from nothing.
• Uninstall hardware utilities that are no longer used, rather than closing them. A lighting suite that was installed to set one static colour has no reason to keep a port-access driver resident afterward.
• Do not run the current cumulative update on the machine that has to work tonight. Where a second machine exists, letting it take updates a few days early converts this class of problem into someone else's early warning.
• Keep the pause window short and dated. Pausing updates is a legitimate tool for a week. It is not a configuration.
• Record the build number that was working. One line in a note, taken from winver, removes the guesswork from every future rollback decision.
• Watch the KB article rather than the forums. The known-issue entry added on 20 August 2026 is where a resolution, a workaround, or a Known Issue Rollback will appear first, and it is the only source that reflects the current status rather than the status when a post was written.

Concrete checklist

1. Run winver. Record whether the build is 26100.9168 or 26200.9168.
2. Check Settings > Windows Update > Update history for the KB5121003 installation date and compare it against the date of the first crash.
3. Run Get-ChildItem C:\Windows\System32\drivers\inpoutx64.sys. No file means no match; stop here.
4. Run Get-FileHash on that file and save the value.
5. Identify the service with Get-CimInstance -ClassName Win32_SystemDriver, then confirm its state with sc query.
6. Identify the owning application in Settings > Apps > Installed apps, sorted by install date.
7. Run sc stop against the service, exit the utility from the tray, and reproduce the failing scenario.
8. If the failure disappears, update the utility first; uninstall it second; rename the driver file third.
9. If the failure persists, restore the service and start mode, then check Event Viewer under Windows Logs > Application and Windows Logs > System for what was recorded at the crash timestamp.
10. Treat uninstalling KB5121003 as the last step, pause updates for a dated window if it is taken, and re-check the KB article before the pause expires.