Windows 11 - Blank Blue Screen Before Logon After an Upgrade

Purpose

Use this when a Windows 11 endpoint completes boot far enough for remote management to work, but the local console shows a blank or solid-color screen and the normal sign-in UI is not visible.

The symptom is ambiguous. A display adapter in an error state is a strong clue, especially immediately after an OS upgrade. It is not by itself proof that the graphics driver is the sole root cause.

Confirm whether the problem is pre-logon or post-logon

Do not start by modifying the Explorer shell unless a user has actually logged on.

From an elevated remote PowerShell session:

Get-Process -Name LogonUI -ErrorAction SilentlyContinue |
    Select-Object Id,SessionId,ProcessName

Get-Process -Name explorer -ErrorAction SilentlyContinue |
    Select-Object Id,SessionId,ProcessName

Interpretation:

LogonUI.exe present in an interactive session means Windows has reached the sign-in UI stage.
It does not prove that the display stack is healthy or unhealthy.
explorer.exe is relevant only after an interactive user session exists. Explorer running under SYSTEM or session 0 is not evidence that the normal desktop shell loaded for the user.

Avoid treating HKLM\...\Winlogon\Shell = explorer.exe as a generic fix for a missing pre-logon screen. That value controls the user shell after authentication, not rendering of the secure sign-in UI.

Record OS and display state

Capture the build and all display adapters before changing anything:

Get-ComputerInfo |
    Select-Object WindowsProductName,WindowsVersion,OsBuildNumber

Get-PnpDevice -Class Display |
    Select-Object Status,FriendlyName,InstanceId

If a display adapter reports Error, capture its exact InstanceId and inspect the full object if needed:

Get-PnpDevice -Class Display | Format-List *

Treat Status = Error as evidence of a PnP or device problem, not as a complete diagnosis of the blank screen.

Repair component-store and system-file corruption correctly

If the upgrade may have left servicing corruption, Microsoft recommends repairing the component store and then validating protected system files.

DISM.exe /Online /Cleanup-Image /RestoreHealth
sfc /scannow

If SFC reports that it repaired files, run it again after DISM until the result is clean or the remaining corruption is understood.

One successful DISM run does not prove that every login or display component is healthy. It only establishes that the image repair operation completed.

Check Windows Update diagnostics without assuming PSWindowsUpdate exists

Get-WindowsUpdate is not a built-in Windows PowerShell cmdlet. It comes from the community PSWindowsUpdate module.

Native Windows diagnostics include:

Get-WindowsUpdateLog -LogPath C:\Windows\Temp\WindowsUpdate.log

Get-WinEvent -LogName 'Microsoft-Windows-WindowsUpdateClient/Operational' -MaxEvents 100 |
    Select-Object TimeCreated,Id,LevelDisplayName,Message

Get-WindowsUpdateLog converts Windows Update ETL traces into a readable static log. It does not install updates.

Test whether the display driver is causal

If all of the following are true:

the blank-screen symptom began immediately after an upgrade or driver change
the display device reports an error
remote management remains available
you have a rollback path if local video disappears

then disabling the failing vendor display device is a reasonable diagnostic test.

First capture the exact device:

$display = Get-PnpDevice -Class Display |
    Where-Object Status -eq 'Error'

$display | Select-Object Status,FriendlyName,InstanceId

If exactly one intended adapter is returned, disable that object directly:

$display | Disable-PnpDevice -Confirm:$false

or use its exact instance ID:

Disable-PnpDevice -InstanceId '<exact-instance-id>' -Confirm:$false

Do not rely on Disable-PnpDevice -InstanceId 'PCI\VEN_1002*' as a wildcard match. The cmdlet accepts instance IDs. Use the exact ID or pipe the desired PnP object into the cmdlet.

Windows can fall back to the Microsoft Basic Display Driver when the vendor graphics driver is absent, not working, or disabled. That makes this a useful isolation test. Success after disabling the device is what establishes causality.

PnPUtil also supports explicit device disable and enable operations:

pnputil /disable-device "<exact-instance-id>"
pnputil /enable-device "<exact-instance-id>"

Use /reboot only when you intend a restart.

Reboot and evaluate the result

After disabling the suspect display device:

shutdown /r /t 0

Then evaluate the local console and remote telemetry.

If the sign-in screen returns

The display-driver path is now strongly implicated.

Next steps:

Keep the device isolated only long enough to regain stable console access.
Obtain an OEM-supported graphics driver for the exact hardware and Windows build.
Install the driver using the vendor package or the specific INF package.
Re-enable the device if required.
Reboot and verify the normal sign-in UI and desktop.

For a staged INF package:

pnputil /add-driver "C:\Drivers\Display\*.inf" /subdirs /install

Do not use DISM /Online /Add-Driver /Driver:C:\Windows\INF /Recurse as a blanket display-driver repair method.

If the symptom does not change

The graphics error may be unrelated or only one part of the problem. Continue with:

Safe Mode testing
event-log review for Winlogon, LogonUI, display, DWM, driver-framework, and setup or upgrade errors
credential-provider investigation only when evidence points there
servicing or upgrade rollback if the failure clearly tracks the feature update

Safe Mode caution for remotely managed endpoints

Safe Mode is useful because Microsoft Basic Display is loaded there. Forcing it remotely can strand the endpoint if the remote-control agent does not start in Safe Mode.

Before setting Safe Mode remotely, verify you have one of:

physical access
out-of-band management
a tested remote-management Safe Mode capability
another recovery path

If intentionally setting Safe Mode from the running OS:

bcdedit /set {current} safeboot minimal
shutdown /r /t 0

Remove the flag before returning to normal operation:

bcdedit /deletevalue {current} safeboot
shutdown /r /t 0

Do not leave safeboot configured on a remote endpoint without a verified way back in.

Avoid speculative destructive repairs

Do not use these as generic next steps without direct evidence:

resetting Winlogon Shell or Userinit for a pre-logon rendering problem
clearing LastLoggedOnSAMUser as a general LogonUI repair
copying logonui.exe from C:\Windows\WinSxS\*\ with a wildcard
removing arbitrary driver packages before recording the active package and rollback path

WinSxS can contain multiple component versions. Wildcard-copying a system executable can select the wrong version and make recovery harder. If protected Windows files are suspected, use supported SFC/DISM or offline servicing first.

Useful event-log checks

Get-WinEvent -LogName System -MaxEvents 300 |
    Where-Object {
        $_.LevelDisplayName -in 'Error','Critical' -and
        $_.Message -match 'display|driver|dxg|DWM|video'
    } |
    Select-Object TimeCreated,Id,ProviderName,Message

Get-WinEvent -FilterHashtable @{LogName='Application'; Level=2; StartTime=(Get-Date).AddHours(-4)} |
    Select-Object TimeCreated,Id,ProviderName,Message

Use log correlation as supporting evidence. A generic display-driver event should not be called the root cause unless changing that driver changes the symptom.

Validation

A successful recovery should establish:

normal sign-in UI is visible
local console input works
the display device no longer reports an unexplained error
the intended vendor driver is installed and stable, or Basic Display is being used only as a temporary recovery state
no new critical display or Winlogon errors appear after reboot
remote-management access remains functional

Catches / gotchas

LogonUI.exe running proves the process exists. It does not prove the GPU caused an invisible sign-in screen.
Get-PnpDevice -Class Display showing Error is a strong lead after an OS upgrade. Causality still has to be validated.
Disable the exact PnP object or pipe it to Disable-PnpDevice. Do not assume wildcard matching in -InstanceId.
Get-WindowsUpdate belongs to PSWindowsUpdate. It is not native Windows PowerShell.

Key lesson

A blank blue screen before logon is a symptom, not a diagnosis. If a display adapter is in error after an upgrade, disabling that exact device is a useful test because Windows can fall back to Basic Display. Do not force Safe Mode remotely until you know how you will regain access.