Shell Launcher custom shell is delayed on Windows 11 IoT Enterprise LTSC 2024 when SQL Server Reporting Services is running at boot

The available evidence does not establish a Windows 11 Shell Launcher dependency on SSRS; capture a cold-boot WPR trace and correlate it with SSRS and Service Control Manager timestamps to identify whether the 40 seconds occur in service initialization, resource contention, or user-session startup.

Shell Launcher selects and starts the configured application after sign-in. It processes the user’s Run and RunOnce entries before launching the custom shell, but Windows services are started separately by the Service Control Manager (SCM). Therefore, SSRS should not directly block eshell.exe unless there is an indirect dependency, startup item, or boot-resource bottleneck. ^1^ ^2^

Determine where the 40 seconds are spent

1. Record the SSRS service configuration and state Run from an elevated PowerShell window, substituting the installed SSRS service name if necessary:

      $svc = Get-CimInstance Win32_Service |
          Where-Object DisplayName -like "*Reporting Services*"
   
      $svc | Select-Object Name, DisplayName, StartMode, State,
          ProcessId, StartName, PathName
   
      sc.exe qc $svc.Name
      sc.exe queryex $svc.Name
   

   Confirm whether it is configured as Automatic or delayed automatic start and note its dependencies. SCM determines automatic-service order from load-order groups and declared dependencies—not from the Shell Launcher WMI configuration. ^2^
2. Correlate the cold-boot events After reproducing the delay, inspect:
   • Event Viewer → Windows Logs → System, filtering for sources Service Control Manager and Winlogon.
   • Event Viewer → Windows Logs → Application, filtering for SSRS/report-server events.
   • The current ReportServerService_<timestamp>.log.
   SSRS trace logs contain detailed service-operation information beyond what might appear in Event Viewer. Microsoft documents the default log location as:

      C:\Program Files\Microsoft SQL Server\MSRS13.MSSQLSERVER\Reporting Services\LogFiles
   

   The instance folder can differ by SSRS installation, so use the path configured on this appliance. ^3^ Compare these four timestamps:
   • Boot start
   • SSRS entering START_PENDING and RUNNING
   • Automatic logon
   • eshell.exe process start
   A service can remain START_PENDING while initializing. SCM also serializes portions of service startup while its service-database lock is held, so the event sequence is important; a service reporting RUNNING does not by itself prove that all of its internal initialization has finished. ^4^
3. Capture a full-boot ETW trace Install Windows Performance Recorder/Analyzer from the Windows ADK, then run from an elevated command prompt:

      wpr -boottrace -addboot GeneralProfile -filemode
      shutdown /r /t 0
   

   Immediately after automatic logon and after the shell appears, stop the trace:

      wpr -boottrace -stopboot C:\Temp\SSRS-ShellLauncher-Boot.etl
   

   This is Microsoft’s documented boot-trace sequence. ^5^ Open the ETL in Windows Performance Analyzer and examine:
   • System Activity → Processes
   • CPU Usage
   • Disk Usage
   • Services
   • The start times and waits for the SSRS process and eshell.exe
   WPR records ETW activity and WPA exposes the resulting CPU, disk, application-launch, and wait data. ^6^

Interpret the result

• eshell.exe starts promptly but its window appears 40 seconds later: investigate the custom shell’s initialization and whether it synchronously contacts SSRS, SQL Server, HTTP endpoints, or another startup component.
• eshell.exe itself is not created for 40 seconds: inspect Run/RunOnce entries first, because Shell Launcher processes those before starting the custom shell. ^1^
• SSRS remains START_PENDING for approximately 40 seconds: use its trace log to identify the operation in progress. Check for SCM timeout events only if the service fails or logs events such as 7000/7009; increasing ServicesPipeTimeout does not make a successfully starting service faster.
• SSRS and the shell overlap with heavy CPU or disk activity: this is boot contention, not a documented Shell Launcher ordering rule.

Conditional mitigation

If SSRS does not need to be available when the appliance UI first appears, test Automatic (Delayed Start) for the SSRS service. Delayed auto-start is a supported SCM configuration and takes effect on the next boot. ^2^

Do not use delayed start if eshell.exe requires SSRS immediately. In that design, launch the shell promptly, display a readiness state, and poll the required SSRS endpoint asynchronously rather than blocking the UI startup.

A certificate trust-list retrieval timeout is another branch only if the SSRS/Application logs show events 7000, 7009, or 1530 and the appliance cannot reach the required certificate-update endpoints. Microsoft documents that specific older SSRS timeout signature, but the 40-second delay alone is insufficient to attribute this case to certificate retrieval. ^7^

If the ETL shows the delay inside Windows session initialization rather than SSRS or the custom process, retain traces from both Windows 10 and Windows 11 under identical cold-boot conditions and escalate them with the exact Windows 11 build, SSRS version/update level, service logs, and event exports.

References

1. Configure Shell Launcher | Microsoft Learn
2. Automatically Starting Services
3. Report server service trace log
4. Service Startup
5. Understand feedback categories and diagnostics
6. Optimizing Performance and Responsiveness
7. You cannot start SQL Server Reporting Services after you apply the update that is discussed in KB 2677070