Starting with Windows Vista in 2007 and continuing with every subsequent release, Microsoft has banned users from logging in to the first session created as Windows boots. This “Session 0 Isolation” has been accompanied by a steady erosion of the interactive capabilities of Session 0, rendering the Session 0 desktop virtually unrecognizable in the post-XP world. The prevailing wisdom in Redmond: Why support a proper working desktop in Session 0 when no one in their right mind is expected to use it?

Unfortunately those of us working with interactive applications and Windows Services in Session 0 don’t have the luxury of ignoring GUI-related issues. And users of the excellent AutoIt automation toolkit have to make special accommodations when creating scripts to click buttons and fill in forms in Session 0. Here is what we have learned while troubleshooting AutoIt with our customers:

1. WinActivate, WinWaitActive and WinActive Often Fail

   Essential AutoIt functions like WinActivate, WinWaitActive and WinActive rely on the operating system to track the active window. Unfortunately it seems that the active window is not tracked in Session 0 unless a user is actively viewing the desktop! Therefore a script that takes some action only if a window has been activated may never do its work. In this sample code, WinActivate will always return 0 when run in an unattended Session 0 and the button will never be clicked:

   ; Activate  the window and click the button.
   if (WinActivate($windowName)) Then
   	; Click the button on the window.
   	ControlClick($windowName, $buttonName, "")
   EndIf
   

   Our advice: Don’t depend on the Win* functions to find and activate a window. Simply operate on your window regardless of its active state. For example, restructure the code above to look like this:

   ; Try to activate  the window if possible. May fail in Session 0.
   WinActivate($windowName)
   ; Click the button on the window.
   ControlClick($windowName, $buttonName, "")
   

2. The Mouse Functions (MouseMove, MouseClick, etc.) Don’t Work

   As with window activation, it seems that the mouse is not tracked when session 0 is unattended. Functions that move and manipulate the mouse can fail unexpectedly.

   Our advice: Don’t use the mouse functions in your scripts.

3. AutoIt Scripts created with Au3Record Are Unreliable

   The Au3Record utility bundled with AutoIt will easily record a set of actions for later replay. It captures mouse movements, mouse clicks, key presses and more. However the script created makes heavy use of the problematic activation and mouse related functions cited above, thus rendering Au3Record scripts virtually useless in Session 0.

   Our advice: Don’t use scripts created by Au3Record in Session 0.

4. You can Rely on ControlSend and ControlClick in Session 0

   Fortunately functions like ControlSend and ControlClick continue to work as expected in Session 0. Neither of them relies on the target window being active nor the mouse being in a specific position, so they sidestep trouble related to those areas on the isolated desktop.

Are you using AutoIt in the isolated Session 0? Have you run into other functionality that does not work as expected? Please let us know what you have found! Your feedback will be much appreciated.

You may also like...

Phasing out Support for Windows XP

Q&A: What's the Difference between AlwaysUp and Service Protector?

Essential Windows Services: EventLog / Windows Event Log