Resolve a long black screen after sign-in caused by App Readiness

Windows reaches the sign-in screen and accepts the user's credentials, but the desktop is replaced by a black screen—often with a movable mouse pointer—for several minutes. Task Manager may still open. The desktop can eventually appear without intervention.

One possible cause is the Windows App Readiness service, internal service name AppReadiness. That service prepares packaged applications when a user signs in for the first time and when applications are added or updated. A service or application-provisioning delay can therefore hold up the transition from sign-in to a usable desktop.

This page is not a generic black-screen repair. App Readiness is the diagnosis only when a controlled comparison shows that changing this one service changes the sign-in delay, and restoring the service makes the delay return or leaves supporting event evidence. Temporarily disabling the service is a diagnostic and recovery step, not a recommended permanent configuration. Windows components and packaged applications depend on App Readiness, and Microsoft's service guidance lists its normal startup type as Manual and advises against disabling it permanently.

Searchable Windows error codes and exact messages

Search the complete event source, event ID, service name, timestamp, and message together. An App Readiness event on an otherwise normal sign-in does not prove causation.

Use this procedure when all of the following are true:

• Windows reaches the sign-in screen normally;
• credentials are accepted before the black screen or long wait begins;
• the mouse pointer moves, Task Manager opens, or the desktop eventually appears, showing that Windows completed substantially more than the pre-Windows boot path;
• the delay is reproducible and can be timed;
• no exact display-driver, shell, profile, storage, or update-removal diagnosis has already been demonstrated; and
• a temporary App Readiness comparison can be performed and rolled back.

The procedure is particularly relevant when the problem begins immediately after Windows or packaged applications are updated, occurs at the first sign-in after that change, and App Readiness events align with the delayed interval.

Do not use this procedure when the screen goes black before sign-in, no pointer is visible, firmware or Windows Recovery Environment is also blank, the computer restarts or displays a stop code, or the Windows disk is intermittently missing.

It also does not apply when:

• manually starting explorer.exe immediately and consistently restores the desktop and the shell configuration is wrong;
• the failure follows a graphics-driver change and Safe Mode or a driver rollback proves the graphics path;
• only one damaged user profile is affected and a new test profile signs in normally without changing App Readiness;
• the device is managed and service startup types are enforced by Group Policy, MDM, application-control policy, or an administrator;
• the device is a VDI, kiosk, multi-session, or application-layering environment whose packaged-app provisioning is controlled by a separate design; or
• the only evidence is an unrelated App Readiness warning in Event Viewer.

Do not permanently disable App Readiness to conceal an unisolated problem. If disabling it prevents new profiles, Store applications, inbox applications, or updates from completing, restore it immediately.

The exact application being prepared, the exact Windows build, the OEM model, and the update that first exposed the delay may remain unknown while the diagnostic comparison is performed.

The following may not remain unknown before the service is changed:

• whether the delay begins before or after credentials are accepted;
• the measured baseline delay from credential submission to a usable desktop;
• the current AppReadiness startup type;
• whether an administrator or management policy controls the service;
• whether the problem affects one profile or every tested profile;
• whether Task Manager and explorer.exe can be started during the delay; and
• the exact result of restoring the recorded service configuration.

An exact build becomes required only if an exact update is proposed for removal. This article does not use update removal as its primary resolution.

• A local administrator account or approved administrative assistance
• Stable power and saved work
• A verified backup of important user data
• A phone, stopwatch, or timestamped log for at least two comparable sign-ins
• Access to Task Manager with Ctrl+Shift+Esc or Ctrl+Alt+Delete
• An elevated Command Prompt
• Space for a new, unused attempt folder, such as C:\FixBackup\FIX-069\Attempt-01
• The ability to restart twice with App Readiness temporarily disabled and twice after restoring the recorded state
• For a managed device, approval from the responsible administrator before changing a Microsoft service

Do not begin a comparison immediately before a required presentation, remote session, or deadline. The first sign-in after restoring App Readiness can legitimately take longer while application preparation catches up.

1. Save all work and close applications.

2. Disconnect unnecessary external storage and docks only if they were not part of the known-good setup. Do not change firmware, storage-controller mode, or the partition layout.

3. From an elevated Command Prompt, choose a new attempt number and stop before writing if that directory already exists:

   set "EVID=%SystemDrive%\FixBackup\FIX-069\Attempt-01"
   if exist "%EVID%\" (echo STOP: choose the next unused Attempt number & exit /b 1)
   md "%EVID%" || exit /b 1
   echo FIX-069> "%EVID%\attempt-marker.txt"
   echo EVID=%EVID%>> "%EVID%\attempt-marker.txt"
   

   If Attempt-01 exists, change only the attempt number to the next unused value and write that exact path into the case record. Do not reuse, clear, or merge an earlier attempt directory.

4. Record the current service configuration and state:

   sc.exe qc AppReadiness > "%EVID%\AppReadiness-qc-before.txt"
   sc.exe queryex AppReadiness > "%EVID%\AppReadiness-query-before.txt"
   type "%EVID%\AppReadiness-qc-before.txt"
   

5. Photograph or copy the START_TYPE line. Do not assume it is Manual merely because Manual is the usual client configuration. The rollback must restore the recorded value.

6. Restart normally twice without changing anything. For each trial, measure from selecting Sign in or submitting credentials until the taskbar, Start menu, and one ordinary application are usable. Record both times.

7. If the delay does not recur in either baseline trial, stop. There is no stable condition against which to test a change.

1. During the black screen, press Ctrl+Shift+Esc. If that does not work, press Ctrl+Alt+Delete and select Task Manager.

2. In Task Manager, select Run new task, enter:

   explorer.exe
   

   Record the result. If the desktop appears immediately and remains usable, continue with the Explorer/shell diagnosis rather than assuming App Readiness.

3. From Task Manager, run cmd.exe, select Create this task with administrative privileges, and query the service:

   sc.exe queryex AppReadiness
   

   Record STATE, WIN32_EXIT_CODE, SERVICE_EXIT_CODE, CHECKPOINT, and WAIT_HINT. A running service is not proof that it caused the delay; a repeatedly increasing checkpoint can indicate that work is still progressing.

4. After the desktop becomes available, open Event Viewer and inspect:

   • Applications and Services Logs > Microsoft > Windows > AppReadiness > Admin
   • Windows Logs > System, filtered for Service Control Manager

   Record events whose timestamps fall inside the measured black-screen interval. If this is a new command session, reset EVID to the exact attempt path recorded in section 6 and validate its marker before any write. Export the AppReadiness log when available:

   set "EVID=%SystemDrive%\FixBackup\FIX-069\<recorded-Attempt-NN>"
   findstr /x /l /c:"FIX-069" "%EVID%\attempt-marker.txt" >nul || (echo STOP: wrong attempt directory & exit /b 1)
   findstr /x /l /c:"EVID=%EVID%" "%EVID%\attempt-marker.txt" >nul || (echo STOP: attempt path does not match marker & exit /b 1)
   wevtutil epl Microsoft-Windows-AppReadiness/Admin "%EVID%\AppReadiness-before.evtx"
   

   If the channel does not exist, record the error and continue; do not create a channel.

5. Test another existing local profile, if one is available and authorized. A delay confined to one profile can still involve per-user app preparation, but it weakens a machine-wide service diagnosis. Do not create a profile solely for this test on a managed device.

6. Perform the controlled service comparison. From an elevated Command Prompt, save the configuration again and inspect the saved START_TYPE before any configuration write or restart:

   sc.exe qc AppReadiness > "%EVID%\AppReadiness-qc-pretest.txt"
   type "%EVID%\AppReadiness-qc-pretest.txt"
   

   If that pre-intervention output says DISABLED, stop this comparison now. Changing disabled to disabled is no intervention and cannot establish App Readiness as the cause. Preserve the original disabled state and route to the shell/profile/startup investigation; do not enable the service merely to manufacture a reversal test.

   Only when the recorded original type is not disabled, temporarily disable App Readiness:

   sc.exe config AppReadiness start= disabled
   sc.exe qc AppReadiness
   shutdown /r /t 0
   

   The space after start= is required. Do not disable every Microsoft service and do not use a broad debloat script.

7. Sign in to the same profile and measure the same interval. Restart once more while the temporary disabled state is still in effect and repeat the same measurement. Then restore the exact original startup type:

   • If the recorded type was DEMAND_START:

     sc.exe config AppReadiness start= demand
     

   • If it was AUTO_START:

     sc.exe config AppReadiness start= auto
     

   • If it was AUTO_START (DELAYED):

     sc.exe config AppReadiness start= delayed-auto
     

   • If it was DISABLED, no controlled disable trial should have been run; preserve disabled exactly and leave this article.

   If policy restores a different value, stop and involve the administrator.

8. Restart twice with the recorded configuration restored and measure both comparable sign-ins. The diagnosis is sufficiently supported only when both disabled-state trials materially improve the same measured interval and both restored-state trials reproduce the delay with time-matched App Readiness activity. Ordinary App Readiness log activity alone is not a reversal test and does not prove causation.

9. If disabling the service makes no material difference, leave it restored and stop this article. Route by the observed stage: graphics, Explorer/shell, user profile, startup application, or another named service.

Use the least invasive branch supported by section 7.

Branch A — One-time App Readiness recovery, then restore the exact recorded startup type

Use this branch when the black screen is severe enough that the desktop cannot be reached normally, and the controlled comparison proved App Readiness involvement.

1. From Task Manager or Safe Mode, open an elevated Command Prompt.

2. Confirm and preserve the current configuration:

   sc.exe qc AppReadiness
   sc.exe config AppReadiness start= disabled
   sc.exe qc AppReadiness
   

3. Restart once:

   shutdown /r /t 0
   

4. Sign in and allow the desktop to settle. Do not install or remove Store applications during this temporary state.

5. Restore the exact startup type in AppReadiness-qc-pretest.txt. Use demand only for a recorded DEMAND_START, auto only for a recorded AUTO_START, delayed-auto only for a recorded delayed automatic state, and disabled only if that was the pre-test state. Never substitute the usual client default for the observed state. For a recorded Manual/on-demand state, use:

   sc.exe config AppReadiness start= demand
   sc.exe qc AppReadiness
   

6. Open Settings > Windows Update, check for current quality updates, and install the current supported update for the installed release. Do not seek out or remove historical KB4038788 on a modern installation.

7. Restart with App Readiness restored and permit one extended sign-in. It may need to complete deferred application preparation.

8. Test packaged applications used on the computer, including Settings, Microsoft Store if present, Calculator, Photos, and any business Store/MSIX applications.

Branch B — Isolate a third-party startup interaction while App Readiness remains enabled

Use this branch when App Readiness activity aligns with the delay but permanent service disablement is unacceptable or the delay returns after the one-time recovery.

1. Confirm App Readiness is restored to its recorded type.
2. Before changing anything, record the current General selection in System Configuration, every visible third-party service's checked/unchecked state, and every Startup app's Enabled/Disabled state in the current attempt record. A screenshot plus a written item list is acceptable; an unrecorded clean boot is not.
3. Open System Configuration (msconfig).
4. On Services, select Hide all Microsoft services. Verify the box is checked before disabling anything.
5. Select Disable all to disable only the remaining third-party services.
6. Open Task Manager's Startup apps page and disable nonessential third-party startup applications. Record every item changed and do not enable an item that was already disabled.
7. Restart and measure sign-in.
8. If the delay is gone, restore half of the items changed by this test to their exact pre-test states, restart, and retest. Continue by halves until one service or startup item is isolated.
9. Update, repair, or uninstall only the proven third-party item. Restore every other service, Startup app, and System Configuration selection to its exact recorded pre-test state. Do not select Normal startup as a blanket reset because it can enable items that were intentionally disabled before this test.

Branch C — App Readiness fails again after restoration

1. Leave the service at its recorded startup type.
2. Export the current AppReadiness and System events.
3. Record the exact application package or error named in Event 215 or related events. Do not remove every AppX package.
4. Repair or update the named application through its supported Settings, Microsoft Store, enterprise-management, or vendor path.
5. If no package is named, retain the evidence and escalate for AppX/MSIX or profile analysis. A blanket Get-AppxPackage | Remove-AppxPackage command is outside this article because it can remove working inbox applications without proving the cause.

• Disabled trial is fast; restored trial is slow: App Readiness involvement is strongly supported. Complete Branch A, then Branch B if a third-party interaction remains.
• Both trials are slow: App Readiness is not demonstrated. Restore it and investigate Explorer, graphics, profile, startup applications, or storage latency.
• Only one user is affected: retain a per-profile/app-provisioning hypothesis; do not apply a machine-wide permanent service change.
• Desktop appears immediately after manually running Explorer: route to FIX-071 or another shell-specific article.
• Store or inbox applications fail after the test: restore App Readiness, restart, and allow application preparation to complete.
• Service configuration is immediately rewritten: management policy owns the setting. Stop local changes.
• The delay occurs only after one exact current update: record the update and check its documented known issues before considering update removal.

• Do not leave App Readiness permanently disabled as the default fix.
• Do not disable all Microsoft services.
• Do not delete C:\ProgramData\Microsoft\Windows\AppRepository, AppX databases, user profiles, or WindowsApps content.
• Do not run mass AppX-removal or debloat scripts.
• Do not remove an old KB merely because one historical case mentioned it.
• Do not force power off repeatedly while Windows is preparing applications.
• Do not treat every Event 215 as causal.
• Do not change firmware mode, Secure Boot, storage-controller mode, BCD, or partitions for a post-sign-in service delay.

1. Restore the exact service startup type recorded before the test:

   sc.exe config AppReadiness start= demand
   

   Replace demand with auto, delayed-auto, or disabled only when that exact value was recorded before the test. Never default an unknown original state to Manual/on-demand.

2. Confirm the write:

   sc.exe qc AppReadiness
   

3. Restore each third-party service, Startup app, and System Configuration selection changed during clean-boot isolation to its exact recorded pre-test state, except an item independently proven defective and deliberately removed. Leave items that were disabled before the test disabled; do not use Normal startup as a substitute for the itemized record.

4. Restart and allow one complete sign-in without interruption.

5. If packaged applications still fail, record the application and AppReadiness events and use the supported repair path for that exact package. Do not compensate by deleting package databases.

Service configuration is the rollback for this procedure. System Restore is not required merely to undo a startup-type change.

Verification requires more than seeing the desktop once:

1. Confirm sc.exe qc AppReadiness shows the intended recorded startup type.
2. Complete three normal restart-and-sign-in cycles to the same profile. Record each credential-to-usable-desktop time.
3. Complete one sign-in to another authorized existing profile, when available.
4. Open the Start menu, Settings, and representative packaged applications.
5. Install or update one noncritical Store/MSIX application only if that application path is normally used on the device.
6. Review the AppReadiness and System logs for new events during the three verification intervals.
7. Confirm no clean-boot configuration or unintended disabled startup item remains.
8. Record the before median, after median, service configuration, and any remaining events in the case record.

Bounded confidence: approximately 80% for a case that passes the controlled service comparison. Two independent Windows 10 discussions contained a visible App Readiness action and reported successful sign-in recovery. Microsoft documentation confirms the service's purpose, Manual startup behavior, and the risk of disabling it. This procedure has not been independently reproduced in the project lab, and the evidence does not prove that App Readiness is the cause of every post-login black screen.

Stop and escalate when the service is policy-managed, the device is VDI/kiosk/multi-session, the desktop never appears even with App Readiness disabled, the screen is black before sign-in, a stop code appears, storage is unstable, or packaged applications remain broken after the recorded configuration is restored.