无论将哪个帐户配置为运行计划任务,每次运行任务时都会为该帐户创建登录会话,为该登录创建一个窗口站,并在该窗口站/登录会话中创建窗口.任务完成后,用户帐户将被注销…当然,系统帐户除外.他们从未注销.

此外,Server 2003没有2008年的会话0隔离.值得注意的是,2008年的工作方式与2003年相比有很大不同.2008年,计划任务由taskeng.exe生成,由svchost.exe生成,这意味着无论任务是否运行,计划任务都在会话0中运行作为SYSTEM或普通用户.但是,如果将任务设置为在2003上以SYSTEM身份运行,则其工作方式与2008年中的任务由会话0中的svchost.exe创建的工作几乎相同.在Server 2003中,会话0只是“控制台”会话,并且您可以使用/ console(/ Vista中的/ admin)通过RDP访问它,然后您将登录到会话0,但它会为您生成一个新的窗口站,因此您将无法看到该计划任务的系统启动的窗口.

在Vista / 2008中,此类活动可能会触发交互式服务检测服务,该服务旨在在弹出交互式对话框时将您转移到会话0的桌面,但除非另一个用户同时登录ISD服务提醒.

因此,当您需要迁移10年前的操作系统时,请记住这一点.

来自NTDebugging博客：

What are all these window stations and desktops in Session 0 anyway?

Now that we know how to tweak the sizes of session view space and the
varIoUs desktops,it is worth talking about why you have so many
window stations and desktops,particularly in session 0. First off,
you’ll find that every WinSta0 (interactive window station) has at
least 3 desktops,and each of these desktops uses varIoUs amounts of
desktop heap. I’ve alluded to this prevIoUsly,but to recap,the
three desktops for each interactive window stations are:

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

· Disconnect desktop – desktop heap size is 64k on 32-bit
systems

· Winlogon desktop – desktop heap size is 128k on 32-bit
systems

Note that there can potentially be more desktops in WinSta0 as well,
since any process can call CreateDesktop and create new desktops.

Let’s move on to the desktops associated with non-interactive window
stations: these are usually related to a service. The system creates
a window station in which service processes that run under the
LocalSystem account are started. This window station is named
service-0x0-3e7$. It is named for the LUID for the LocalSystem
account,and contains a single desktop that is named Default. However,
service processes that run as LocalSystem interactive start in Winsta0
so that they can interact with the user in Session 0 (but still run in
the LocalSystem context).

Any service process that starts under an explicit user or service
account has a window station and desktop created for it by service
control manager,unless a window station for its LUID already exists.
These window stations are non-interactive window stations. The window
station name is based on the LUID,which is unique for every logon.
If an entity (other than System) logs on multiple times,a new window
station is created for each logon. An example window station name is
“service-0x0-22e1$”.

来自旧的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.

没有办法将进程及其所有窗口传递到另一个用户的会话中,或以某种方式将其注入到桌面中……至少没有一些主要的编程……这将是一个非常有趣的程序.

最后,对Mark Russinovich’s blog这篇文章的评论非常有趣和相关：

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.