My server at work has some scheduled tasks that run every night. They run when no user is logged into the system. They run batch files which open MS-Access databases with macros inside. Occasionally these are not closed by the script, their process is still running and their .ldb lock file hangs around.

I've watched them run before and I've seen that an MS-Access window popups up, and if it completes successfully, then the window closes and there isn't a problem. However, if it fails, then the lock file and the process remain. I'm assuming that maybe there's a window somewhere too...I know that in Linux if your program has a Window in an XWindows session, you can transfer it to another XWindows session; is the same thing possible on Windows?

  • Typically the tasks are run under a session for the user they are configured under. That's typically a good reason to configure the tasks with an Active Directory/local account instead of relying on system accounts. Then you can log in as the user and get their desktop. – Agent_9191 May 28 '13 at 15:16
  • @Agent_9191 This is not true - on Server 2003, when I schedule a task to run as user@domain.com even when the user is not logged in, the scheduled task is spawned in session 0, and even if I subsequently log in using the /console switch, thus logging into Session 0, I still get a different WindowStation, thus I still cannot see the window of the scheduled task. – Ryan Ries May 28 '13 at 18:02

Changing my answer since you changed the tag from Server 2008 to 2003... and I wasn't really accurate with my first answer.

Whatever account is configured to run the scheduled task, a logon session is created for that account every time the task runs, a window station is created for that logon, and the windows are created in that window station/logon session. When the task is done, the user account is logged off... with the exception of the system accounts of course. They never log off.

Also, Server 2003 doesn't have the session 0 isolation that 2008+ does. It's worth noting that this works much differently in 2008+ than it does in 2003. In 2008, scheduled tasks are spawned by taskeng.exe, which is spawned by svchost.exe, meaning the scheduled task runs in Session 0 regardless of whether the task runs as SYSTEM or as a normal user. But if the task is set to run as SYSTEM on 2003, it works almost the same as it does in 2008 where the task is created by svchost.exe in Session 0. In Server 2003, Session 0 is simply the "console" session, and you can access it over RDP with the /console (/admin in Vista/2008+) and you will log in to Session 0, but it generates a new window station for you, so you won't be able to see that scheduled task's windows that were launched by System.

In Vista/2008+, this sort of activity would likely trigger the Interactive Services Detection service, which is meant to transfer you to Session 0's desktop when an interactive dialog box pops up, but not unless another user was logged in at the same time for the ISD service to alert.

So keep that in mind when it comes time to migrate off of your 10 year old OS.

From the NTDebugging blog:



· Default desktop - desktop heap size is configurable as described below






From an old MS KB:

A Microsoft Windows NT, Windows 2000, and Windows XP service has a Window station and Desktop combination associated with it. This is based on which account the service is running in:

•If the service is running in the LocalSystem account and is not interactive (that is, the service type does not include the SERVICE_INTERACTIVE_PROCESS flag), the service will use the following Window station and Desktop: Service-0x0-3e7$\default where "Service-0x0-3e7$" is the name of the Window station and "default" is the name of the desktop.

This is a noninteractive Window station.

•If the service is running in the LocalSystem account and is interacting with the desktop (that is, the service type includes the SERVICE_INTERACTIVE_PROCESS flag), the service will use the following Window station and Desktop: Winsta0\default This is an interactive Window station.

•If the service is running in the security context of a user account, the system will create a unique noninteractive Window station and Desktop for that service. The name of the Window station will be based on the Logon Security Identifier (SID) of the user:

Service-0xZ1-Z2$\default where Z1 is the high part and Z2 is the low part of the Logon SID. Additionally, two services that are running in the same security context (same service account name) will not receive the same Window station and Desktop because Logon Security Identifier's(SID) are unique to that logon session.

There's no way to pass a process and all of its windows into another user's session or somehow inject it into their desktop... at least not without some major programming... that would be a very interesting program to try to make.

Lastly, the comments on this post on Mark Russinovich's blog are quite interesting and relevant:

The question was whether a thread could call SetThreadDesktop after it had already been assigned to a desktop by the window manager. I wrote some test code just now and it confirmed my recollection. If a thread has ever created a window on one desktop, even if that window has since been destroyed, it will never be allowed to SetThreadDesktop() to a different desktop and create windows there.

  • Aw nuts I mean Windows Server 2003. – leeand00 May 28 '13 at 15:08

Your Answer

