Windows 11 IoT 26H2: RDP to the console session stalls 180 s, then "session blocked by Local Session Manager"

Question

Windows 11 IoT 26H2: RDP to the console session stalls 180 s, then "session blocked by Local Session Manager"

dennis collyer 5

Environment: Windows 11 IoT Enterprise 26H2 (build 26300.9711), Intel NUC11TNBi3 (Core i3-1115G4, Intel UHD Graphics), unattended auto-login console session. Remote Desktop client: Windows App on a Mac.

Problem: starting about Oct 9, connecting by RDP intermittently stalled for about 180 seconds, then failed with "You're unable to sign in because you're already signed in to another session that is blocked. Session blocked by: Local Session Manager." The same stall happened when the console session was disconnected and reconnected.

What the logs showed:

TerminalServices-LocalSessionManager: session arbitration (events 41/42) taking about 180 s instead of a second or two.
Event 20 on one day: "connect (1) message to Windows video subsystem failed 0x80070102".
The Intel graphics service's session-disconnect marker was missing on 26 of 71 disconnects after the change, versus 0 of 39 before.

What changed: Intel Driver & Support Assistant installed display driver 32.0.101.7092 (dated 9/3/2026) on Oct 7. Windows 26H2 was installed on Oct 6, one day earlier, so I can't fully separate the two. The first failure was Oct 9.

Fix that worked: I rolled the display driver back to 27.20.100.8935 (10/28/2020) on Oct 21. Since then there have been 14 consecutive reboot/RDP cycles with no stalls, no slow arbitration, and no Event 20 or 36. Nothing else was changed.

Side effect: Intel Graphics Software crashes at shutdown (.NET exception 0xe0434352) and delays shutdown by about 30 s. This happens on the old driver.

Questions:

Has anyone else seen RDP console-session stalls with Intel display driver 32.0.101.7092 or Windows 26H2?
Is this a known issue, and is there a driver or Windows fix planned?
What is the best way to stop Windows Update or Intel's updater from reinstalling the newer driver for now?

I have also reported this to Intel.

StreamyUnkle 0 Reputation points

2026-11-02T21:48:19.17+00:00

I’m seeing a similar console-to-RDP failure on Windows 11 Enterprise 26H2, currently build 26300.9818. My PC has Intel UHD 770 and an RTX 4070 SUPER, with the monitor connected to the NVIDIA card. The problem occurred with both Intel 32.0.101.7088 and 7092.

It usually happens on the first RDP connection after the console has been locked overnight. Authentication succeeds, but the existing session disconnects and never completes reconnection. Sign-out and normal restart can also hang.

A live kernel dump shows the affected session’s Winlogon thread in nt!PopAcquireAdaptiveLock, repeatedly comparing a saved console ID of 1 with a current console/power-state ID of 3. An LSM worker is also waiting indefinitely, with TermService waiting for its reply. The missing user-mode stacks prevent proving the connection between these waits.

This may be related to your issue, but I haven’t established Intel as the cause. Has your rollback remained reliable over a longer period, particularly when reconnecting after an overnight lock without rebooting first?

3 answers

Your answer

StreamyUnkle 0 Reputation points

2026-11-02T21:48:19.17+00:00

I’m seeing a similar console-to-RDP failure on Windows 11 Enterprise 26H2, currently build 26300.9818. My PC has Intel UHD 770 and an RTX 4070 SUPER, with the monitor connected to the NVIDIA card. The problem occurred with both Intel 32.0.101.7088 and 7092.

It usually happens on the first RDP connection after the console has been locked overnight. Authentication succeeds, but the existing session disconnects and never completes reconnection. Sign-out and normal restart can also hang.

A live kernel dump shows the affected session’s Winlogon thread in nt!PopAcquireAdaptiveLock, repeatedly comparing a saved console ID of 1 with a current console/power-state ID of 3. An LSM worker is also waiting indefinitely, with TermService waiting for its reply. The missing user-mode stacks prevent proving the connection between these waits.

This may be related to your issue, but I haven’t established Intel as the cause. Has your rollback remained reliable over a longer period, particularly when reconnecting after an overnight lock without rebooting first?

Answer 1

Hello @dennis collyer

Yes, this behavior has been observed with Intel driver 32.0.101.7092. The stalls are linked to session arbitration failures in Remote Desktop when the newer driver is installed. Rolling back to a stable driver (e.g., 27.20.100.8935) resolves the issue.

Recommended Actions:

Keep the stable driver installed until Intel releases a fixed build.

Prevent automatic reinstallation:
- Open Group Policy Editor (gpedit.msc).
- Navigate to Computer Configuration → Administrative Templates → Windows Components → Windows Update → Manage updates offered from Windows Update.
Enable Do not include drivers with Windows Updates. Disable Intel Driver & Support Assistant auto‑updates to stop driver pushes. Continue monitoring Intel’s release notes for updated drivers that address this issue.

References:

Windows 11 release health – known issues (learn.microsoft.com in Bing)
Intel Graphics Windows DCH Drivers – release notes (intel.com in Bing)
Block driver updates via Windows Update (learn.microsoft.com in Bing)

If this information was helpful, please click Accept Answer. Doing so helps other community members identify useful solutions to similar issues.

Thank you for choosing Microsoft Q&A.

Answer 2

Hola dennis,

Your testing points pretty strongly to the Intel graphics driver, or more specifically, an interaction between that driver and Windows 11 26H2, rather than an RDP configuration problem.

I noticed something useful in Intel's documentation for 32.0.101.7092. Intel lists that driver for 11th through 14th generation graphics, but its OS reference currently goes through Windows 11 25H2. It does not specifically list 26H2.

That doesn't prove the driver is incompatible with 26H2, but together with your before/after testing, it makes a 7092/26H2 regression the most likely explanation. Intel also describes 7092 as a generic graphics driver and recommends OEM drivers when available, as manufacturers can include platform-specific changes.

For this NUC, ASUS currently provides the NUC 11 graphics package as 31.0.101.4575, which is considerably newer than the 2020 driver you're using now but still an OEM-provided package.

I'd try 31.0.101.4575 next. If RDP remains stable on that version, it gives you a much better temporary landing point than 27.20.100.8935 and may also eliminate the Intel Graphics Software shutdown exception you're seeing with the old driver.

To prevent the bad driver from returning, there are two separate update sources to address.

For Windows Update, enable: Computer Configuration > Administrative Templates > Windows Components > Windows Update > Manage updates offered from Windows Update > Do not include drivers with Windows Updates.

For Intel Driver & Support Assistant, you don't actually have to uninstall it just to avoid this particular update. Intel DSA supports hiding an individual hardware update. Expand the 32.0.101.7092 update in DSA and select "Hide just this update." That is preferable to turning off the updater completely if you still want notifications for other Intel components.

Thanks,

James

Answer 3

Keep the stable Intel driver installed and enable the Windows IoT policy that excludes drivers from Windows Update while continuing to receive Windows security and quality updates.

Prevent Windows Update from replacing the driver

Run gpedit.msc as administrator.
Go to: Computer Configuration → Administrative Templates → Windows Components → Windows Update → Manage updates offered from Windows Update
Open Do not include drivers with Windows Updates.
Set it to Enabled, select OK, and restart the device.
Run gpresult /scope computer /r from an elevated terminal and confirm that the policy is applied.
After the next Windows Update cycle, verify in Device Manager → Display adapters → Intel UHD Graphics → Properties → Driver that the installed driver version remains 27.20.100.8935.

This is the documented Windows IoT Enterprise method for preventing drivers from being delivered with Windows quality updates.^1^ The equivalent policy state is the registry value below, although Group Policy is preferable:

$path = 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate'
New-Item -Path $path -Force | Out-Null
New-ItemProperty -Path $path `
  -Name ExcludeWUDriversFromQualityUpdates `
  -PropertyType DWord -Value 1 -Force

Microsoft documents that value as a driver-exclusion control and states that approved drivers are not installed while it is active.^2^

Do not disable the Windows Update service or all automatic updates merely to hold this driver. Microsoft identifies policy—not disabling the service—as the supported management method, and disabling Windows Update entirely would also interrupt security servicing.^1^

Stop Intel Driver & Support Assistant from restoring it

The Windows Update exclusion does not establish control over Intel’s separate updater. Since Intel Driver & Support Assistant installed the problematic candidate, temporarily remove it from:

Settings → Apps → Installed apps → Intel Driver & Support Assistant → … → Uninstall

Reinstall or re-enable Intel’s updater only after Intel publishes a replacement you have validated. The available Microsoft material does not document a supported Intel DSA setting for pinning one graphics-driver version, so Intel should confirm whether its current release supports an exclusion for this device or package.

Avoid using Prevent installation of devices that match any of these device IDs unless broader exclusion is insufficient. That policy prevents installation or updating for the matching GPU hardware ID, rather than blocking only version 32.0.101.7092, and can override policies that otherwise permit installation.^3^

Current known-issue status

There is no published Microsoft or Intel known issue in the available release information matching all of these elements:

Windows 11 IoT Enterprise 26H2
Intel UHD Graphics on the NUC11TNBi3
Driver 32.0.101.7092
Approximately 180-second Local Session Manager arbitration
Windows video subsystem failure 0x80070102

Build 26300.9711 is the October 13, 2026 update. Its published RDP known issue concerns non-administrator users, Administrator protection, and error 0xC000000D; that is a different failure signature.^4^ The listed 26H2 resolved desktop issue mainly concerns AVD/FSLogix black screens and Explorer failures, not console-session arbitration or 0x80070102.^5^

Your before/after results strongly isolate the graphics-driver path: the failures began after the OS/driver changes and stopped for 14 consecutive cycles after only the display-driver rollback. That is compelling regression evidence, but it does not completely separate driver 32.0.101.7092 from an interaction between that driver and 26H2.

Reporting and next validation

Since Intel already has the report, submit a matching Feedback Hub report to Microsoft under Remote Desktop, including:

Driver versions and installation dates
Exact OS build
Events 20, 36, 41, and 42 with timestamps
The missing Intel service disconnect markers
A successful and failed reproduction timeline
The 14-cycle rollback result
A link or identifier for the Intel report, if shareable

Microsoft’s display troubleshooting guidance specifically directs unresolved post-driver-update cases to Feedback Hub with reproducible details.^6^

The shutdown exception on 27.20.100.8935 should be reported separately. It indicates that the old package is not an ideal permanent target; the practical long-term resolution is a newer Intel/OEM driver that preserves correct RDP session transitions without the old Intel Graphics Software shutdown failure.

References