Start screen bypass configuration for Win32 application transitions
0 reputation · 30 Jul 2024, 03:41 UTC
0 reputation · 30 Jul 2024, 03:41 UTC
Windows 8 implements a distinct separation between WinRT Store apps and legacy Win32 desktop applications. While the Start screen serves as the primary shell interface, the system provides a configuration to bypass this screen and boot directly to the desktop environment upon user authentication.
When the automatic login to desktop is enabled, the system alters the initial shell sequence. However, it remains unclear how this configuration affects the behavior of Win32 applications that are pinned to the Start screen but launched via external triggers or automated startup scripts during the boot process.
Does the bypass configuration prevent the Modern UI shell from initializing entirely during the launch of a pinned Win32 app? Under what conditions will the system still trigger a full-screen context shift to the Start screen despite the desktop login setting?
The automatic desktop login configuration does not prevent the Modern UI shell (the Start screen) from initializing; it merely changes the default target of the shell sequence upon authentication. The Modern UI shell remains a resident process in the background to manage the Start screen and Charms bar, regardless of whether the user lands on the desktop first.
When a Win32 application is launched via an external trigger (such as a startup script or a scheduled task) while the desktop bypass is active, the system initializes the explorer.exe process. Because Win32 applications run within the desktop environment, they launch directly into the desktop window manager (DWM) context without triggering a transition to the Start screen.
Despite the desktop login setting, the system will still trigger a full-screen context shift to the Start screen under the following specific conditions:
explorer.exe crashes and restarts, the system may default to the primary shell interface (the Start screen) depending on the specific build version and registry state.To verify if a Win32 application is bypassing the Modern UI shell during boot, you can monitor the process tree using a tool like Process Explorer. A standard Win32 launch should show the following hierarchy:
winlogon.exe > explorer.exe > [YourWin32App].exe
If the application is being routed through the Modern UI shell, you may see ShellExperienceHost.exe appearing in the process chain immediately prior to the application launch.
Diagnostic Detail Required: Are the "external triggers" mentioned using standard .exe paths, or are they utilizing shell:AppsFolder URIs? This distinction determines whether the system treats the launch as a legacy desktop call or a Modern UI app transition.
Use comments to ask for clarification. Post a solution as an answer.
2,100 reputation · 30 Jul 2024, 08:39 UTC
The ‘Boot to desktop’ setting is a per‑user configuration (stored in HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\StartPage\OpenAtLogon). It changes the default shell after logon but does not alter the system‑wide shell initialization sequence.
If a Win32 executable is started before Explorer has fully initialized – for example from a RunOnce key, a service launched during logon, or a scheduled task running in the system context – the session may briefly show the Start screen while the immersive shell loads, then transition to the desktop once Explorer takes over. This fleeting flash is expected and does not indicate a misconfiguration.
Launching a Win32 program via its Start‑screen tile still invokes the tile’s activation path. Unless the tile is explicitly wrapped to launch a Store‑app protocol, the app runs on the desktop without a full screen shift. However, if the tile’s ApplicationUserModelID points to a protocol that defaults to the immersive shell (e.g., a ms‑weather: URI), the Start screen will appear briefly before the desktop context is restored, even with the desktop bypass enabled.
Verification can be done by monitoring the process tree with Process Explorer: a standard Win32 launch after logon shows winlogon.exe → explorer.exe → [YourApp].exe. An early‑launch that runs before Explorer will appear as a child of winlogon.exe directly, and the immersive shell process (ImmersiveShell.dll) will be present in the background during the brief Start‑screen flash.