Summary of the Issue
We are encountering a widespread, reproducible Windows UAC failure across multiple Windows 11 devices where the UAC consent dialog becomes unresponsive after credentials are entered.
Observed behavior:
User can enter username/password
Credentials appear to be accepted
“Yes”, “No”, and Close buttons are non-functional
Mouse and keyboard input stop responding within the UAC dialog
Dialog cannot be dismissed
Only recovery is CTRL+ALT+DEL → Restart (or waiting ~4–5 minutes for a timeout, with no elevation)
This impacts local admin elevation, credential prompts, and auto-elevation workflows, causing significant disruption to support and administrative operations.
Affected Environments
Windows 11 (Windows 10 not recently verified due to Win10 sunset)
Azure AD–joined and non-domain-joined systems
Occurs:
- Locally at the device
- During remote sessions
Independent of:
- Application elevation allowlists
- Manual vs auto-filled credentials
- Presence of third-party elevation tools
Multiple organizations we support have reproduced this issue.
Reproduction Pattern
The issue does not occur immediately after reboot. A consistent pattern has emerged:
Reboot system → UAC works normally
System is left powered on, logged in, and locked for several hours or overnight
Upon attempting elevation:
- UAC prompt appears
- Credentials can be entered
- Prompt becomes unresponsive
The issue persists until:
System reboot or
A specific background service is stopped (details below)
Key Observations
What temporarily restores UAC
Reboot
Stopping certain background services immediately restores UAC functionality
Restarting those services does not immediately reintroduce the issue
What does not resolve the issue
sfc /scannow (no integrity violations)
Group Policy (reproduced on non-domain-joined systems)
Ending or avoiding remote sessions
Removing third-party elevation tools
Service-Level Correlation
Through repeated controlled testing:
- Stopping/Restarting any number of services immediately restores UAC
- DNS Filter Agent
- File Cache Service Agent (N-Able N-Central)
- PME Agent (N-Able N-Central)
- Restarting the service does not instantly break UAC
- Leaving the system locked/idle again can cause recurrence
This suggests a timing or state-related interaction rather than a persistent corruption.
Behavioral Details
Secure Desktop does render
Credential entry is accepted
UI interaction fails post-credential submission
Event Viewer:
- No consistent crash events
- No clear Application Errors tied to
Consent.exe or ConsentUX
- No obvious CPU or memory exhaustion at time of failure
Diagnostics Collected
Application and System Event Logs
Service-related process dumps (via ProcDump)
Time-correlated logs before and after service stoppage
No single crash signature or definitive fault has surfaced.
Current Blocker
Failure occurs within native Windows UAC (Secure Desktop)
Issue reproduces even without third-party elevation tools
Stopping specific third-party background services immediately restores native UAC
Unclear whether root cause is:
- Windows subsystem interaction
Secure Desktop/session isolation issue
- Application or driver-level bug
Similar behavior reported elsewhere:
Are there known issues involving:
- Secure Desktop input handling
ConsentUX.exe
- Winlogon or session transitions
- Service-to-user session IPC
Are there recommended diagnostic tools beyond Event Viewer and ProcDump for UAC deadlocks?
Have recent cumulative updates introduced known UAC or session isolation regressions?
Has anyone observed similar behavior tied to:
- Credential Providers
- Network filter drivers
- Background agents running as SYSTEM
Request
If anyone has:
- Seen similar UAC freezes
- Identified a root cause
- Found a Microsoft hotfix or mitigation (registry or otherwise)
- Insight into deeper UAC diagnostics
Any guidance would be greatly appreciated. We are actively gathering reproducible data and trying to determine whether this is a known Windows defect or an undocumented interaction.
Thank you for your time and expertise.