Restore Explorer when a Windows update or shell utility prevents it from starting

Windows accepts sign-in credentials but the desktop, taskbar, and Start menu do not load. The screen may remain black with a movable pointer, and Task Manager may still open. explorer.exe might be missing, might exit immediately, or might be prevented from becoming the Windows shell after an update or a shell/repair utility changes files or configuration.

Two different repair mechanisms belong on this page but must remain separate:

• an exact Windows 11 preview update, KB5030310 on build 22621.2361, was removed and Explorer returned in one case; and
• a repair utility left explorer.exe missing, and restoring the system to a point before the utility ran returned the desktop in another case.

The common boundary is a demonstrated change followed by Explorer failure and a rollback of that exact change. This is not permission to uninstall the latest update or copy explorer.exe from another computer.

Searchable Windows error codes and exact messages

Search the complete exception code with the faulting module and file path. explorer.exe 0xc0000005 is materially different from explorer.exe missing or a wrong Winlogon Shell value.

Use this procedure when:

• Windows reaches sign-in and accepts credentials;
• Task Manager, the security screen, or Safe Mode remains accessible;
• Explorer, the taskbar, and the desktop do not start or do not remain running;
• %windir%\explorer.exe, the Winlogon Shell value, Event 1000, update history, or a known utility change provides evidence; and
• the exact update, utility, configuration value, or restore point can be identified before rollback.

The KB5030310 branch applies only to Windows 11 22H2 where that exact package/build relationship is present. The System Restore branch applies only when a restore point predates the demonstrated utility or shell change.

Do not use this page when the black screen occurs before sign-in, no Windows security screen or Task Manager can be reached, firmware or WinRE is also blank, Windows shows a stop code or Recovery code, or the disk/file system is unstable.

It also does not apply when:

• Explorer is running normally and only one folder window, browser, game, or application is black;
• Windows+Ctrl+Shift+B, display reconnection, or graphics-driver rollback proves a display path;
• App Readiness service comparison proves a sign-in provisioning delay;
• the computer is intentionally configured as a kiosk or replacement-shell device;
• malware response is required; or
• the proposed update is not actually installed or the restore point was created after the breakage.

Do not alter the Winlogon Shell value on a managed kiosk, assigned-access device, remote-session host, or system with a deliberately replaced shell without design-owner approval.

The internal reason the update or utility affected Explorer, the exact shell extension involved, and the original utility author's intent may remain unknown.

The following may not remain unknown before change:

• whether explorer.exe exists at the affected installation's %windir%;
• whether manually starting it returns the desktop, shows a dialog, or exits;
• the current Winlogon Shell value;
• the exact installed KB or exact utility and change time;
• the faulting module and exception code when Event 1000 exists;
• whether the device is intentionally using a replacement shell; and
• the rollback route for the exact proposed change.

The exact Windows build may remain unknown for utility rollback, but it is mandatory for the KB5030310-specific branch.

• Administrative access through Task Manager, Safe Mode, or Windows Recovery Environment
• A verified backup of important data
• Stable power
• A new, unused affected-user capture path and a separate new, unused elevated evidence attempt, both carrying the same recorded attempt label
• A record of the last known-good sign-in and last material change
• Update history or package evidence before update removal
• A restore point created before the failure for the System Restore branch
• Registry backup before changing Winlogon values
• Current Windows installation media only if later escalation requires repair installation; it is not required for the initial branches

Do not proceed with update removal or System Restore until files are backed up and the exact target is visible.

1. At the black screen, press Ctrl+Shift+Esc. If Task Manager does not open, use Ctrl+Alt+Delete and select it.

2. First capture the affected user's identity and user-scope Shell value in that user's own, non-elevated security context. Choose a new attempt label. In Task Manager select Run new task, type cmd.exe, leave Create this task with administrative privileges clear, and run the existence guard before any write:

   set "ATTEMPT=Attempt-01"
   set "USERCAP=%PUBLIC%\Documents\FIX071-AffectedUser\%ATTEMPT%"
   if exist "%USERCAP%\" (echo STOP: choose the next unused Attempt number & exit /b 1)
   md "%USERCAP%" || exit /b 1
   echo FIX-071> "%USERCAP%\attempt-marker.txt"
   echo ATTEMPT=%ATTEMPT%>> "%USERCAP%\attempt-marker.txt"
   whoami /user > "%USERCAP%\affected-user-SID.txt"
   echo %USERPROFILE% > "%USERCAP%\affected-user-profile.txt"
   reg query "HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v Shell > "%USERCAP%\Shell-HKCU-before.txt" 2>&1
   type "%USERCAP%\affected-user-SID.txt"
   type "%USERCAP%\Shell-HKCU-before.txt"
   

   If Attempt-01 exists, change only the attempt number to the next unused value. If the public location is not writable, use another new user-writable folder. Record the exact ATTEMPT and USERCAP path. Keep the not-found result when the value is absent. This non-elevated capture is mandatory when elevation uses a different administrator account, because an elevated prompt's HKCU can belong to that helper administrator.

3. Close that prompt. In Task Manager run cmd.exe again and now select Create this task with administrative privileges.

4. In the elevated prompt, reset ATTEMPT and USERCAP to the exact values recorded by the affected user. Validate that capture, then create a separate machine evidence path with a pre-write existence guard:

   set "ATTEMPT=<recorded-Attempt-NN>"
   set "USERCAP=<exact-recorded-affected-user-capture-path>"
   findstr /x /l /c:"FIX-071" "%USERCAP%\attempt-marker.txt" >nul || (echo STOP: wrong affected-user attempt & exit /b 1)
   findstr /x /l /c:"ATTEMPT=%ATTEMPT%" "%USERCAP%\attempt-marker.txt" >nul || (echo STOP: attempt labels do not match & exit /b 1)
   set "EVID=%SystemDrive%\FixBackup\FIX-071\%ATTEMPT%"
   if exist "%EVID%\" (echo STOP: elevated evidence attempt already exists; select a wholly new attempt & exit /b 1)
   md "%EVID%" || exit /b 1
   echo FIX-071> "%EVID%\attempt-marker.txt"
   echo ATTEMPT=%ATTEMPT%>> "%EVID%\attempt-marker.txt"
   echo EVID=%EVID%>> "%EVID%\attempt-marker.txt"
   echo USERCAP=%USERCAP%>> "%EVID%\attempt-marker.txt"
   

   If the elevated attempt path already exists, do not reuse it. Return to step 2 and create a wholly new attempt label for both paths; preserve the abandoned capture as evidence rather than overwriting it.

5. Record Windows version and package state:

   ver > "%EVID%\version-before.txt"
   dism /online /get-packages /format:table > "%EVID%\packages-before.txt"
   

6. Preserve the machine-wide Winlogon key, query its Shell value, and copy the already captured affected-user files into the evidence directory:

   reg export "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" "%EVID%\Winlogon-before.reg" /y
   reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v Shell > "%EVID%\Shell-HKLM-before.txt" 2>&1
   copy "%USERCAP%\attempt-marker.txt" "%EVID%\affected-user-attempt-marker.txt"
   copy "%USERCAP%\affected-user-SID.txt" "%EVID%\affected-user-SID.txt"
   copy "%USERCAP%\affected-user-profile.txt" "%EVID%\affected-user-profile.txt"
   copy "%USERCAP%\Shell-HKCU-before.txt" "%EVID%\Shell-HKCU-before.txt"
   

   Substitute the recorded alternate user-capture path if one was required. Open affected-user-SID.txt and confirm it is the user whose sign-in fails. Keep the ERROR: The system was unable to find... result when a value or key is absent; absence is part of the rollback state. Do not query affected-user HKCU from the elevated helper account, and do not use the full-key export as the routine rollback for one value because it can overwrite unrelated Winlogon changes.

7. Do not run a registry cleaner, shell reset script, or downloaded DLL replacement. Preserve the state before diagnosis.

1. From Task Manager choose Run new task and enter:

   explorer.exe
   

   Record whether the desktop appears, nothing happens, Explorer exits, or a dialog displays a code or file path.

2. Check the expected file from the elevated Command Prompt:

   dir /a "%windir%\explorer.exe"
   

   • If the file is missing, do not copy it from another computer. Continue to the utility/System Restore or component-repair branch.

   • If it exists, record its version and Microsoft signature from PowerShell:

     Get-Item "$env:windir\explorer.exe" | Select-Object FullName,Length,@{n='FileVersion';e={$_.VersionInfo.FileVersion}}
     Get-AuthenticodeSignature "$env:windir\explorer.exe" | Format-List Status,StatusMessage,SignerCertificate
     

3. Query the machine scope from the elevated prompt, then query user scope only from a separate non-elevated prompt running as the same affected SID captured in section 6:

   reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v Shell
   

   In the affected user's non-elevated prompt, first prove the identity and then query HKCU:

   whoami /user
   reg query "HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v Shell
   

   On an ordinary Windows desktop, the expected effective shell is explorer.exe. An explicit current-user Shell value can override the machine-wide value for that user. Determine which scope contains the demonstrated wrong value; do not rewrite HKLM merely because HKCU contains the override. A different value is not automatically wrong on a kiosk or managed replacement-shell system.

4. Inspect Event Viewer > Windows Logs > Application for Event ID 1000 at the failed sign-in. Record:

   • faulting application name and path;
   • faulting module name and path;
   • exception code;
   • fault offset; and
   • timestamp.

   Export the Application log if needed:

   wevtutil epl Application "%EVID%\Application-before.evtx"
   

5. Check Reliability Monitor (perfmon /rel) for an Explorer failure and the update or utility installation on the same timeline.

6. If KB5030310 is suspected, verify all three facts:

   • Windows 11 version 22H2 was running;
   • OS build 22621.2361 or update history identifies KB5030310; and
   • Explorer failure began immediately after that package was installed.

   A superseding current cumulative update can make the old KB absent or non-removable. If it is not listed, stop that branch.

7. If a repair or shell utility is suspected, record its exact name, version, run time, log, backup/restore feature, and the last restore point before it ran. Do not rerun it to see what happens.

8. If Explorer exists and the Shell value is correct, perform a clean boot or Safe Mode comparison. If Explorer starts in Safe Mode or clean boot, a shell extension, startup program, service, or injected module is more likely than a missing core file.

9. Proceed only when one branch is evidenced: wrong Shell value, exact update regression, demonstrated utility change with a prior restore point, or protected-file damage.

Choose one branch and verify before combining it with another.

Branch A — Correct a proven wrong Winlogon Shell value

Use this branch only on an ordinary Windows desktop where the current value is not explorer.exe and no intentional replacement shell is configured.

1. Confirm both scope-specific query files from section 6 exist and show whether each original value was present, its type, and its data.

2. Modify only the scope proven to supply the wrong effective value.

   Wrong machine-wide value with no overriding affected-user value:

   reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v Shell /t REG_SZ /d explorer.exe /f
   reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v Shell
   

   Wrong affected-user value: open a separate non-elevated prompt while signed in as that affected user. Require whoami /user to match affected-user-SID.txt, then run:

   whoami /user
   reg add "HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v Shell /t REG_SZ /d explorer.exe /f
   reg query "HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v Shell
   

3. Sign out and sign back in, or restart once.

4. If the value changes back, stop. A policy, utility, malware, or replacement-shell configuration owns it; repeated registry writes are not a repair.

Branch B — Remove exact KB5030310 from the affected historical build

1. Confirm KB5030310 is installed and the computer is the affected Windows 11 22H2 case.

2. Prefer Settings > Windows Update > Update history > Uninstall updates. Select only KB5030310.

3. If Settings cannot perform the removal but Task Manager can run an elevated command, enumerate packages and identify the exact LCU package name associated with the installed build:

   dism /online /Get-Packages /Format:Table > "%EVID%\packages-before-removal.txt"
   

   KB5030310 is a combined SSU/LCU package; WUSA /uninstall /kb:5030310 is not a valid removal path for it. Match the exact Package_for_RollupFix... identity to the installed LCU using the package listing and retained update/build evidence. Do not select a Servicing Stack package or a package merely because its date is nearby.

4. Remove only the exact identified LCU package:

   dism /online /Remove-Package /PackageName:<exact-LCU-package-name>
   

   Replace the placeholder with the full package identity copied from DISM. Do not add /Quiet, do not guess the package name, and do not remove the SSU.

5. Restart when DISM requests it.

6. If DISM says the package is absent, permanent, not applicable, or cannot be removed, stop. Preserve the exact HRESULT and use System Restore or a later supported cumulative update rather than forcing package deletion.

7. After Explorer returns, install the current supported cumulative update for the Windows release. Do not remain indefinitely on an obsolete preview-build state.

Branch C — Undo a demonstrated shell/repair utility change with System Restore

1. From Task Manager, try Run new task > rstrui.exe. If the interface does not open, enter Windows Recovery Environment.
2. In WinRE select Troubleshoot > Advanced options > System Restore.
3. Select the correct Windows installation if prompted.
4. Choose Show more restore points and select a restore point created before the utility ran or Explorer disappeared.
5. Use Scan for affected programs and save or photograph the list.
6. Confirm the target date and begin restore. Keep stable power and do not interrupt it.
7. After Windows restarts, record the restore result and test Explorer before reinstalling the utility.
8. If no qualifying restore point exists, stop this branch. Do not select a later restore point merely because it is available.

Branch D — Repair protected Windows components when Explorer is missing or has a bad signature

Use this branch in a normal Windows session reached through Task Manager or Safe Mode.

1. Repair the component store:

   DISM.exe /Online /Cleanup-Image /RestoreHealth
   

2. Require the command to complete successfully before continuing. Record any error code.

3. Run System File Checker:

   sfc /scannow
   

4. Record the complete result. Do not claim repair if SFC says it could not perform the operation or could not repair some files.

5. Restart and recheck %windir%\explorer.exe, its signature, and Event 1000.

6. If DISM requires a source or Windows cannot sustain an online session, stop and use a separately validated offline-repair or repair-installation procedure matched to the installed edition, language, architecture, and release.

Branch E — Remove a proven incompatible shell utility without rolling back Windows

1. Use Settings > Apps > Installed apps or the utility's signed uninstaller to remove the exact demonstrated utility.
2. Do not use its generic “repair all” function again.
3. Restart and test Explorer.
4. If Explorer remains missing or damaged, use Branch C or D according to available evidence.

• Explorer starts manually and remains running: shell startup configuration or a startup interaction is more likely than a missing executable.
• Explorer starts only in Safe Mode/clean boot: isolate third-party shell extensions, services, and startup items; do not remove the latest update by default.
• Correcting the Shell value restores every sign-in: preserve the registry backup and identify what changed it.
• Removing verified KB5030310 restores Explorer: install a later supported cumulative update and confirm the defect does not return.
• System Restore returns Explorer: keep the offending utility removed until a compatible version and rollback are available.
• DISM/SFC repairs Explorer: verify signatures, Event 1000, and repeated sign-ins.
• No branch changes the failure: preserve logs and escalate to dump/ProcMon analysis or a matched repair installation.

• Do not copy explorer.exe or DLLs from another computer or download them from a DLL site.
• Do not uninstall the newest update without identifying the exact installed package and timeline.
• Do not change the Shell registry value on an intentional kiosk or replacement-shell system.
• Do not delete user profiles, WindowsApps, AppRepository, or shell-extension registry trees wholesale.
• Do not run multiple cleanup/repair utilities.
• Do not use offline DISM package removal with a guessed drive letter or package identity.
• Do not disable security software permanently to make Explorer start.
• Do not change firmware, BCD, controller mode, or partitions for a post-sign-in Explorer failure.

Registry branch

Reset ATTEMPT, USERCAP, and EVID to the exact paths recorded for the attempt that performed Branch A. Validate both markers and the saved affected-user SID before using any rollback data:

set "ATTEMPT=<exact-recorded-Attempt-NN>"
set "USERCAP=<exact-recorded-affected-user-capture-path>"
set "EVID=%SystemDrive%\FixBackup\FIX-071\%ATTEMPT%"
findstr /x /l /c:"FIX-071" "%EVID%\attempt-marker.txt" >nul || (echo STOP: wrong elevated attempt & exit /b 1)
findstr /x /l /c:"ATTEMPT=%ATTEMPT%" "%EVID%\attempt-marker.txt" >nul || (echo STOP: elevated attempt label mismatch & exit /b 1)
findstr /x /l /c:"EVID=%EVID%" "%EVID%\attempt-marker.txt" >nul || (echo STOP: elevated attempt path mismatch & exit /b 1)
findstr /x /l /c:"FIX-071" "%USERCAP%\attempt-marker.txt" >nul || (echo STOP: wrong affected-user attempt & exit /b 1)
findstr /x /l /c:"ATTEMPT=%ATTEMPT%" "%USERCAP%\attempt-marker.txt" >nul || (echo STOP: affected-user attempt label mismatch & exit /b 1)
type "%EVID%\affected-user-SID.txt"

Do not select a folder because it is newest or has the highest attempt number. Restore only the Shell value in the scope changed by Branch A, using the scope-specific before file from this validated attempt. Replace <RECORDED-TYPE> with the exact type shown in that file (normally REG_SZ) and replace <RECORDED-LITERAL-DATA> with the complete original data, retaining its quoting and arguments.

If the machine-wide value originally existed, run from the elevated prompt:

reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v Shell /t <RECORDED-TYPE> /d "<RECORDED-LITERAL-DATA>" /f
reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v Shell

If the affected-user value originally existed, open the affected user's non-elevated prompt, require its SID to match the saved SID, and run:

whoami /user
reg add "HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v Shell /t <RECORDED-TYPE> /d "<RECORDED-LITERAL-DATA>" /f
reg query "HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v Shell

If the value was originally absent, remove only the value that Branch A added. For an HKLM change use the elevated prompt:

reg delete "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v Shell /f

When the affected-user HKCU value was the one added, use that affected user's non-elevated prompt after verifying its SID:

whoami /user
reg delete "HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon" /v Shell /f

Restart and verify the intended shell. Do not import the full Winlogon key as routine rollback because that can overwrite unrelated values changed after the evidence capture. The full export is evidence/emergency reference for this same installation, not a cross-machine repair file.

Update branch

Use Windows Update to install the current applicable cumulative update. If the exact removed preview package is still required for controlled historical testing, reinstall only through Microsoft's supported update channel or catalog after creating a restore point.

System Restore branch

If Windows offers Undo System Restore and the restore introduced a worse problem, use that supported option from System Restore. User-created files are not a System Restore rollback mechanism; keep the separate data backup.

Utility branch

Reinstall only a version documented compatible with the current Windows release, and only after a restore point is created. If reinstalling reproduces the failure, remove it again and retain the before/after evidence.

1. Confirm %windir%\explorer.exe exists and has a valid Microsoft signature.
2. Confirm the ordinary desktop's Winlogon Shell data is explorer.exe.
3. Sign out and back in three times or complete three restarts. Explorer, taskbar, Start, and desktop must appear without manually running Explorer.
4. Open File Explorer, Settings, Start search, and a context menu.
5. Review Application Event 1000 for the verification intervals.
6. Confirm the removed update or utility state and current Windows build.
7. Run Windows Update and confirm the device can reach a supported update state without reproducing the failure.
8. Record the exact successful branch, before/after build or utility version, and remaining exception events.

Bounded confidence: approximately 80% when the exact change and rollback match one of the confirmed branches. One case explicitly reported Explorer recovery after removing KB5030310; another reported recovery after restoring to a point before a repair utility removed or disrupted Explorer. Microsoft's current shell guidance confirms explorer.exe as the normal Windows desktop shell and documents Event 1000, clean boot, update removal, and recovery paths. The project has not independently reproduced either case, and the two causes are variants, not interchangeable fixes.

Stop when the device is a kiosk/replacement-shell system, the exact update or utility cannot be identified, no qualifying restore point exists, the file system is unstable, malware is suspected, DISM/SFC returns an unresolved error, Windows fails before sign-in, or a protected/managed policy owns the configuration.