You can probably work backwards from the KB article to the underlying problem.<p>This is listed as a workaround:<p>"Configure the value of the DelayedDesktopSwitchTimeout registry entry. This value determines the time-out interval of a session before Windows 7 or Windows Server 2008 R2 switches between sessions."<p>In Windows, the login screen and user desktops run in different window manager sessions. There's a similar KB article that explains this in a little more detail:<p><a href="http://support.microsoft.com/kb/940452" rel="nofollow">http://support.microsoft.com/kb/940452</a><p>"This issue occurs because the logon process runs in session 0. However, the logon script process runs in a different session. A 30-second delay occurs before Windows Vista switches from session 0 to another session. When the logon script interacts with you before the logon script process is complete, you have to wait for the 30-second time-out interval of session 0. To fix this problem, change the time-out interval to less than 30 seconds."<p>The login scripts in Windows run before the user's desktop appears. It seems reasonable that there's a trigger sent from a process that runs after the login script terminates that tells the OS to switch from session 0 to the new user's session. This is likely to prevent the desktop from flickering between the different login states.<p>In case there's a problem with logging in that wasn't expected, there's a failsafe timer, defaulting to 30s (hence the 30s login delay in both KB articles) that triggers the switch from session 0 regardless of the login state.<p>Given that, and the reference to stopping the "Desktop Window Manager Session Manager" in the linked KB, I would imagine that the solid-color desktop interferes with the login process by either crashing the service that renders the background, therefore failing to send the appropriate trigger or triggers a different code path that fails to send the signal.