I'm configuring Windows 7 Professional x64 to run a custom application as the shell, in "kiosk" mode. That is, replacing the default shell (explorer.exe) with my application and autologon as a specific user.

[HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon]
"Shell"="c:\Program Files\my-app\whatever.exe"

I've also turned off the Windows logo splash screen on boot (in msconfig). The machine is not on any domains.

When I power on the machine, I see the BIOS screen, then a black screen (where the Windows logo would have been), then the user logon page flashes by quickly (during autologon), then it sits at a blank screen for several minutes.

The cursor is on screen but inoperable. And I'm fairly certain it's not my application, because when I run it in a regular desktop scenario, it starts very quickly. This is a bad experience for the user that's starting up the kiosk or may be approaching the kiosk after it's been booted, but before the application starts.

Does anyone know what Windows is doing behind the scenes in kiosk mode that might explain this delay? Or how to track down what's happening?

Or does anyone have any fancy ideas on tricking the user into thinking the kiosk is operating? (I don't know what else I have control over at this point in Windows kiosk startup... can I splash up a background image instead of the drab geen/blue screen?)

  • If you replace your custom application with something like notepad.exe does the same slowness issue occur?
    – Nate
    Feb 24 '12 at 19:10
  • Is "kiosk" mode actually a real "mode" supported by MS, or do you mean that you've got a Windows 7 computer acting as a kiosk?
    – joeqwerty
    Feb 24 '12 at 19:55
  • Is the computer in a domain? Did you adjust the policy to force all login-scripts and policy processing to complete before the shell starts?
    – Zoredache
    Feb 24 '12 at 19:56
  • Thanks for the comments, I'll be trying these thing asap next week when I'm back in the office. Feb 24 '12 at 21:43
  • If you can't move the mouse, then maybe you're facing some other lag and boot logging would be applicable. The shell explorer.exe is executed unless the Winlogon Shell value is set. Also, make sure your users can't access the system level Ctrl-alt-delete screen by hitting ctrl-alt-delete, opening task manager and starting explorer.exe. Was the computer a member of a domain (ever)? It might still be loving itself some group policy settings.
    – mbrownnyc
    Feb 24 '12 at 22:09

Most likely you are not telling Winlogon that you're application is ready to go. Put the following code at the top of main() (this is all C++ so you may have to translate to your language of choice):

 * Signal to Winlogon that the shell has started and the login screen can be dismissed
HANDLE hShellReadyEvent;
hShellReadyEvent = OpenEvent(EVENT_MODIFY_STATE, false, L"msgina: ShellReadyEvent");
if( hShellReadyEvent != NULL )
    SetEvent( hShellReadyEvent );
    CloseHandle( hShellReadyEvent );

This will shave at least 30 seconds from your start-up process.

  • I haven't been able to try this answer and I don't know when I'll get time to work on the problem, but until I hear different, I'll mark this as the answer. Mar 20 '13 at 12:14

Be sure that there are no mapped drives unreachable from the place of your kiosk is installed. If you map a drive in your lab or test facility and try to access it from a place without network access, the login takes too much time until windows realize that the remote drive is unreachable.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.