Microsoft's own Windows 11 release health page lists an issue titled "Some games become unresponsive when certain drivers are present," tied to the August 11, 2026 security update KB5121003. The root cause: RGB lighting and motherboard utility software that installs a driver named inpoutx64 or something similar. Microsoft's fix is to block that driver from loading — and it says the same block is being folded into the September 2026 Windows security update and every release after it. If you manage endpoints, that means an ordinary Patch Tuesday cumulative update is about to start changing driver behavior on any machine that has this software installed, whether or not anyone touches Memory Integrity or a security setting.
This is a different bug from the one covered elsewhere on this site under "Memory Integrity will not turn on: finding the incompatible driver, and what the vulnerable driver blocklist actually blocks." That post is about a user deliberately trying to enable Memory Integrity (HVCI) and hitting a driver the general vulnerable driver blocklist already flags. This post is about something Microsoft is doing to everyone, proactively, regardless of whether HVCI is on, off, or has never been touched — and regardless of whether the affected user was even trying to change a security setting at all. Same broad family of mechanism (blocking a driver from loading), different trigger, different reader question: "is a routine update about to disable a driver I depend on?"
After KB5121003 (August 11, 2026), some Windows 11 24H2/25H2 devices with RGB lighting or motherboard utility software installed can see games like ARC Raiders freeze, crash with EXCEPTION_ACCESS_VIOLATION, or trigger an unexpected restart. Microsoft traced this to a legacy hardware I/O driver named inpoutx64 (or something similarly named) colliding with the game. Microsoft's fix is a targeted block that disables that driver and shows a notification when it does — already rolling out automatically to non-managed devices, and confirmed to be arriving in the September 2026 security update and subsequent releases for everyone else, including enterprise-managed devices that don't get the automatic push. Before that update lands fleet-wide, check whether any of your devices actually have this driver, and what installed it, using the read-only script below — do not mass-disable a driver you have not confirmed is present and understood.
The problem: games freezing, crashing, or restarting the device after KB5121003
Here is exactly what Microsoft documents. After installing Windows updates released on or after August 11, 2026 (KB5121003, OS Build 26100.9168), some Windows 11 devices running certain games can experience:
- the game application becomes unresponsive
- the game application closes without notice
- the error
EXCEPTION_ACCESS_VIOLATIONis displayed - the device restarts without warning
Microsoft names three specific games in its own advisory: ARC Raiders, MARVEL Tokon: Fighting Souls, and THE FINALS. Quoted directly from the Windows 11, version 25H2 known issues page (the identical entry also appears on the 24H2 page):
Read that status carefully — "Resolved" does not mean "fixed everywhere for everyone automatically." It means Microsoft has shipped a specific block, and that block is propagating on a specific schedule to a specific population of devices. The rest of this post is about exactly what that means for a managed fleet.
Client: Windows 11, version 25H2; Windows 11, version 24H2
Server: None
Why it happens: a legacy hardware I/O driver, and how Windows blocks drivers in general
To understand this, you need two pieces of background: what inpoutx64 actually does, and how Windows can block a driver from loading at all. Both are simpler than they sound.
What inpoutx64 is, in plain English
Inpoutx64.sys (and its older 32-bit sibling, inpout32.sys) is not a Microsoft driver. It's a small, widely reused open-source kernel driver whose entire job is to give a regular application a way to read and write hardware I/O ports directly — something Windows normally does not allow user-mode software to do, for very good security reasons. Direct port access used to be routine on older operating systems; on modern Windows it requires a kernel-mode driver acting as a translator.
RGB lighting utilities, some motherboard monitoring tools, and a handful of legacy peripheral configuration programs bundle this driver (or a close relative like WinRing0) because it is a quick way to talk to embedded controllers, fan headers, and lighting controllers on the motherboard without writing a full custom driver. It has been part of the PC hobbyist and gaming-peripheral ecosystem for well over a decade. It was never written or audited by Microsoft, and it grants any process that can talk to it a fairly direct path to hardware — which is exactly the kind of capability that makes security researchers nervous, and exactly the kind of driver Microsoft's vulnerable driver blocklist program exists to police in general.
How Windows disables a driver, mechanically
A Windows device driver's startup behavior is controlled by a single registry value: the Start value under that driver's service key at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<driver name>. Microsoft's own workaround instructions for this exact issue — published on the same release health page — tell administrators to set that value to 4 (Disabled) by hand. That is the same mechanism a Code Integrity policy block ultimately achieves at load time, just applied directly rather than through a signed policy file.
Why this collides with games specifically
Modern PC games, especially competitive multiplayer titles, commonly ship kernel-level anti-cheat components that watch closely for anything else touching low-level hardware or kernel memory in ways that look unusual. A legacy, unsigned-for-modern-purposes I/O driver initializing or being polled by RGB software at the same time a game's anti-cheat driver is doing its own aggressive kernel-level checks is a plausible collision point — consistent with the symptom pattern Microsoft describes (freezes and access-violation crashes specifically tied to game launch, not general system instability). Microsoft's own text stops short of a full technical post-mortem of the collision mechanism, and this post won't speculate beyond what's confirmed.
How to verify: is this driver even on your device, and is it already blocked?
Before touching anything, find out whether this even applies to a given device. Three independent checks, from quickest to most thorough.
Step 1 — Check the registry for the driver's service key
Open PowerShell as Administrator and check for the driver's own service registration. An absent key means the driver has never been installed on this machine.
What a device with the driver present and enabled looks like:
A Start value of 4 means the driver is already disabled — either by Microsoft's automatic block, by a prior manual workaround, or by something else entirely. Any other value (0, 1, 2, or 3) means the driver can still load.
Step 2 — Check whether Code Integrity is already blocking it
Whether or not this specific inpoutx64 fix uses the standard vulnerable driver blocklist mechanism, it's worth knowing how to check for any Code Integrity driver block, since HVCI, Smart App Control, or a future blocklist update could independently block the same driver on a device where you also expect Microsoft's targeted fix.
If you see a 3077 event naming the driver, Code Integrity is actively blocking it right now, regardless of what caused that policy to exist. If you never see one, that only tells you Code Integrity isn't the thing blocking it — the driver may still be blocked purely via the registry Start value, which Code Integrity never gets involved with.
App Control / Code Integrity Event ID catalog
This is the full set of Code Integrity Operational log events relevant to a driver being validated, blocked, or allowed — not just the one event tied to today's issue — sourced from Microsoft's own Understanding App Control event IDs reference:
| Event ID | Level | Meaning |
|---|---|---|
| 3001 | Warning | An unsigned driver attempted to load |
| 3023 | Warning | The driver under validation did not meet the requirements to pass the App Control policy |
| 3033 | Warning | The file's signature is revoked, or a Lifetime Signing EKU certificate has expired — correlates with a 3077 event when App Control caused the block |
| 3076 | Warning | Main block event for an audit-mode policy — the driver would have been blocked if the policy were enforced |
| 3077 | Error | Main block event for an enforced policy — the driver did not pass the policy and was blocked from loading |
| 3082 | Warning | A non-WHQL driver would be blocked if the policy were enforced (audit-mode signal) |
| 3089 | Information | Signature detail for a file that was blocked or audit-blocked, correlated to its 3076/3077 event by ActivityID |
| 3099 | Information | An App Control policy (including the vulnerable driver blocklist policy) has been loaded |
| 3111 | Error | The file under validation did not meet the hypervisor-protected code integrity (HVCI) policy |
citool.exe -lp -json) to list every active App Control policy and its friendly name on a device, so you can tell a general vulnerable-driver-blocklist policy apart from an organization-specific App Control policy that happens to also mention drivers.
Step 3 — Check what installed the driver in the first place
Before deciding anything, find the application that put the driver there. This is the step the source guidance behind this post insists on, and it's the difference between an informed decision and a guess.
- Note the
ImagePathfrom Step 1's output, e.g.C:\Windows\System32\drivers\inpoutx64.sys. - Check installed programs for RGB lighting or motherboard utility software: open Settings › Apps › Installed apps and look for vendor lighting-control suites (motherboard OEM lighting utilities, peripheral manufacturer control-center apps, standalone open-source RGB tools).
- Check the file's own version/publisher metadata for a hint at the bundling application:
Get-Item "C:\Windows\System32\drivers\inpoutx64.sys" | Select-Object VersionInfo. - If you cannot identify the owning application confidently, do not disable the driver on that device yet — flag it for manual follow-up instead.
The fix: what Microsoft is doing, what you can do now, and what NOT to do
There are three separate timelines to understand here, because they land differently depending on how your devices are managed.
Timeline 1 — Non-managed consumer and business devices (already happening)
Microsoft's own text says this resolution "is propagating automatically to Windows consumer and business devices that are not managed by IT departments, and a device restart is required." It began rolling out starting August 26, 2026, 6 PM PT, and Microsoft says it could take up to 24 hours from that point to reach all affected devices in that population. If a device isn't enrolled in Intune, Configuration Manager, or a similar management platform, it is very likely already covered, once it has restarted since then.
Timeline 2 — Enterprise-managed devices (does not happen automatically)
Quoted directly from Microsoft: "If you have an enterprise-managed device, this resolution will not propagate automatically. IT administrators can address this issue by following the steps mentioned in the workaround section." This is the population every EndpointWeekly reader actually manages, and it means nothing changes on your fleet from this specific block until you either apply the manual workaround yourself or wait for Timeline 3.
Timeline 3 — The September 2026 security update and beyond (arrives via normal patching)
Microsoft's advisory closes with the sentence that matters most for planning: "The driver block will also be included in the September 2026 Windows security updates and subsequent releases." Patch Tuesday for September 2026 falls on September 8 — the day after this post was researched. As of publication, Microsoft has not yet published the specific KB number for that release on its release health or servicing pages, since it had not shipped yet. Treat the September CU (and every cumulative update after it) as carrying this driver block going forward, and confirm the exact KB number against Microsoft's Windows message center or the 25H2 release health page once it's live, rather than assuming a specific number in advance.
Start value actually changes (or a Code Integrity block appears) once the update lands.
The documented manual workaround, if you need it before your pilot ring reaches the September CU
Microsoft publishes this exact workaround on the same release health page. It's the safest option if you've confirmed on a specific device that the driver is present, no needed software depends on it, and you don't want to wait for the September CU.
- Back up the registry first — Microsoft's own instructions stress this. See How to back up and restore the registry in Windows.
- Navigate to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\inpoutx64in Registry Editor, or use the confirmed-safe read (never write) command from Step 1 above to locate it via PowerShell first. - Double-click the value named Start. Change Value data to 4.
- Close Registry Editor and restart the computer. The change does not take effect until reboot.
Registry key reference — what this workaround touches, and what it doesn't
| Value name (type) | Healthy / desired value | If wrong |
|---|---|---|
Start (REG_DWORD) | 4 once you've confirmed disabling is correct for this device | 0-3 = driver can still load; the collision this post covers is still possible |
ImagePath (REG_EXPAND_SZ) | Points to the actual .sys file on disk — use this to confirm the file's owning software via version metadata | Points to a missing file = driver is registered but not actually installed; usually harmless leftover |
Type (REG_DWORD) | 1 (kernel driver) on a genuine inpoutx64 installation | Unexpected value warrants a closer look before assuming this is the same driver family |
Start value. It does not remove the RGB/monitoring software that installed the driver, does not prevent that software from reinstalling or re-enabling the driver on its next update, and does not stop a different machine with a differently-named sibling driver (inpout32, WinRing0) from hitting the same collision. Treat it as a per-device, per-driver mitigation, not a permanent fleet-wide fix — that's what the September 2026 CU and Microsoft's own automatic rollout are for.
Deploy this as an Intune Proactive Remediation
Because this is fleet-checkable, use the companion scripts as a read-only Proactive Remediation pair — with the remediation half deliberately conservative, per the guidance above. The detection script matches the checks in "How to verify" exactly. The remediation script reports only by default; it will not disable anything unless it is explicitly re-run with both -Disable and -AcknowledgeRisk, and even then only for one exact driver name you supply after reviewing a specific device's findings — it is not designed to be handed a blanket "fix everything" assignment.
- Sign in to the Intune admin center.
- Go to Devices › Scripts and remediations › Proactive remediations.
- Select Create and name it, e.g. "inpoutx64 RGB driver — detect only (KB5121003 issue)".
- On the Settings page, paste
Detect-InpOutX64DriverPresence.ps1into Detection script file. - Paste
Remediate-InpOutX64DriverPresence.ps1into Remediation script file — it will run in report-only mode with no parameters, which is what you want for fleet-wide visibility without fleet-wide changes. - Set Run this script using the logged-on credentials to No (both scripts need local admin context to read the driver service registry and the Code Integrity log reliably).
- Select Next, then assign to a pilot device group first under Scope tags › Assignments.
- Set the schedule (e.g. Daily, every 1 day) and select Next › Create.
Proof it worked: reading the audit script's output
Run the detection script locally first and confirm its findings against the manual checks in "How to verify" before relying on it operationally. This is a real captured run on a lab device with the driver absent (the common case for most business laptops):
Three things confirm this ran correctly, not just that it printed "HEALTHY":
- It checked all five things, not just the registry. A device could have the driver's registry key removed but still show a loaded entry in
Win32_SystemDriverfrom before an uninstall completed, or vice versa — checking both independently catches that gap. - It exits 0 only on a genuinely clean result. If a query failed (for example, the CodeIntegrity-Operational log couldn't be read), the script reports the failure and exits 2 rather than silently reporting a false-clean 0.
- A device WITH the driver present and enabled reports exit code 1, not 0, with an explicit instruction not to disable it blindly. That's the signal that should route to a human for the "what depends on this" investigation, not to an automatic disable action.
If your own run comes back with the driver present (DriverServiceFound = True, Start not equal to 4, and no Code Integrity block event), that device needs the manual investigation in "The fix" section — not an automatic script run with -Disable -AcknowledgeRisk applied fleet-wide.
These scripts are being finalized after local testing on the author's own device (both parse cleanly and ran successfully in read-only mode; see the report note below). They will be published to Windows-Patching-Scripts once testing on a device that actually has the driver present is complete — check back at the link below, or watch this post for the GitHub links to be added.
References
- Microsoft Learn — Windows 11, version 25H2 known issues ("Some games become unresponsive when certain drivers are present")
- Microsoft Learn — Windows 11, version 24H2 known issues (identical advisory entry)
- Microsoft Support — August 11, 2026, KB5121003 (OS Builds 26200.9168 and 26100.9168)
- Microsoft Learn — Microsoft recommended driver block rules (the general vulnerable driver blocklist)
- Microsoft Learn — Understanding App Control event IDs (full Code Integrity Event ID catalog)
- Microsoft Learn — App Control debugging and troubleshooting guide (CodeIntegrity-Operational log location and 3077/3089 walkthrough)
- Microsoft Support — How to back up and restore the registry in Windows
- Microsoft Learn — Windows message center (check here for the September 2026 CU's own KB number once published)
- EndpointWeekly — Memory Integrity will not turn on: finding the incompatible driver, and what the vulnerable driver blocklist actually blocks (the related, distinct issue)