На моем рабочем сервере есть несколько запланированных задач, которые выполняются каждую ночь. Они запускаются, когда в систему не вошел ни один пользователь. Они запускают командные файлы, которые открывают базы данных MS-Access с макросами внутри. Иногда они не закрываются сценарием, их процесс все еще выполняется, а их .ldb файл блокировки зависает.
Я наблюдал, как они запускаются раньше, и я видел, что всплывает окно MS-Access, и если оно завершается успешно, то окно закрывается, и проблем нет. Однако в случае сбоя файл блокировки и процесс остаются. Я предполагаю, что, может быть, где-то тоже есть окно ... Я знаю, что в Linux, если ваша программа имеет окно в сеансе XWindows, вы можете передать его в другой сеанс XWindows; возможно ли то же самое в Windows?
Изменение моего ответа, так как вы изменили тег с Server 2008 на 2003 ... и я не совсем точно дал свой первый ответ.
Какая бы учетная запись не была настроена для запуска запланированной задачи, сеанс входа в систему создается для этой учетной записи каждый раз, когда задача запускается, для этого входа в систему создается оконная станция, а окна создаются в этой оконной станции / сеансе входа в систему. Когда задача выполнена, учетная запись пользователя выходит из системы ... за исключением, конечно, системных учетных записей. Они никогда не выходят из системы.
Кроме того, в Server 2003 отсутствует изоляция сеанса 0, как в 2008+. Стоит отметить, что в 2008+ это работает по-другому, чем в 2003 году. В 2008 году запланированные задачи порождаются taskeng.exe, который порождается svchost.exe, то есть запланированная задача выполняется в сеансе 0 независимо от того, работает как СИСТЕМА или как обычный пользователь. Но если задача настроена на запуск как SYSTEM в 2003 году, она работает почти так же, как и в 2008 году, когда задача создается с помощью svchost.exe в сеансе 0. В Server 2003 сеанс 0 является просто сеансом «консоли», и вы можете получить к нему доступ через RDP с помощью / console (/ admin в Vista / 2008 +), и вы войдете в сеанс 0, но он генерирует для вас новую оконную станцию, поэтому вы не сможете увидеть это запланированное окна задачи, запущенные системой.
В Vista / 2008 + подобная активность, скорее всего, вызовет срабатывание службы обнаружения интерактивных служб, которая предназначена для перевода вас на рабочий стол сеанса 0 при появлении интерактивного диалогового окна, но только если другой пользователь не вошел в систему одновременно для сервис ISD для оповещения.
Так что имейте это в виду, когда придет время отказаться от вашей 10-летней ОС.
Из блога NTDebugging:
Что такое все эти оконные станции и рабочие столы в сеансе 0?
Теперь, когда мы знаем, как настроить размеры пространства просмотра сеанса и различных рабочих столов, стоит поговорить о том, почему у вас так много оконных станций и рабочих столов, особенно в сеансе 0. Во-первых, вы обнаружите, что каждый WinSta0 (интерактивный window station) имеет как минимум 3 рабочих стола, и каждый из этих рабочих столов использует различное количество кучи рабочего стола. Я уже упоминал об этом ранее, но напомним, что три рабочих стола для каждой интерактивной оконной станции:
· Рабочий стол по умолчанию - размер кучи рабочего стола можно настроить, как описано ниже.
· Отключить рабочий стол - размер кучи рабочего стола составляет 64 КБ в 32-разрядных системах
· Рабочий стол Winlogon - размер кучи рабочего стола составляет 128 КБ в 32-разрядных системах
Обратите внимание, что в WinSta0 потенциально может быть больше рабочих столов, поскольку любой процесс может вызывать CreateDesktop и создавать новые рабочие столы.
Перейдем к рабочим столам, связанным с неинтерактивными оконными станциями: они обычно связаны с сервисом. Система создает оконную станцию, на которой запускаются служебные процессы, выполняемые под учетной записью LocalSystem. Эта оконная станция называется service-0x0-3e7 $. Он назван по LUID для учетной записи LocalSystem и содержит один рабочий стол с именем Default. Однако служебные процессы, которые выполняются как интерактивная LocalSystem, запускаются в Winsta0, чтобы они могли взаимодействовать с пользователем в сеансе 0 (но по-прежнему работать в контексте LocalSystem).
Любой процесс службы, который запускается под явным пользователем или учетной записью службы, имеет оконную станцию и рабочий стол, созданные для него диспетчером управления службами, если оконная станция для его LUID уже не существует. Эти оконные станции не являются интерактивными оконными станциями. Имя оконной станции основано на LUID, который уникален для каждого входа в систему. Если объект (кроме системы) входит в систему несколько раз, для каждого входа в систему создается новая оконная станция. Пример названия оконной станции - «service-0x0-22e1 $».
Из старого MS KB:
Служба Microsoft Windows NT, Windows 2000 и Windows XP имеет связанную с ней комбинацию оконной станции и рабочего стола. Это зависит от того, в какой учетной записи запущена служба:
• Если служба работает под учетной записью LocalSystem и не является интерактивной (то есть тип службы не включает флаг SERVICE_INTERACTIVE_PROCESS), служба будет использовать следующие оконные станции и рабочий стол: Service-0x0-3e7 $ \ default where " Service-0x0-3e7 $ "- это имя оконной станции, а" default "- это имя рабочего стола.
Это неинтерактивная оконная станция.
• Если служба запущена под учетной записью LocalSystem и взаимодействует с рабочим столом (то есть тип службы включает флаг SERVICE_INTERACTIVE_PROCESS), служба будет использовать следующие оконные станции и рабочий стол: Winsta0 \ default Это интерактивная оконная станция.
• Если служба работает в контексте безопасности учетной записи пользователя, система создаст уникальную не интерактивную оконную станцию и рабочий стол для этой службы. Имя станции Window будет основано на идентификаторе безопасности входа (SID) пользователя:
Service-0xZ1-Z2 $ \ default, где Z1 - старшая часть, а Z2 - младшая часть SID входа в систему. Кроме того, две службы, работающие в одном контексте безопасности (с одинаковым именем учетной записи службы), не получат одинаковые оконные станции и рабочий стол, поскольку идентификаторы безопасности входа (SID) уникальны для этого сеанса входа в систему.
Невозможно передать процесс и все его окна в сеанс другого пользователя или как-то внедрить его на его рабочий стол ... по крайней мере, без некоторого серьезного программирования ... это было бы очень интересной программой, которую можно было бы попробовать.
Наконец, комментарии к этой публикации на Блог Марка Руссиновича довольно интересны и актуальны:
Вопрос заключался в том, может ли поток вызвать SetThreadDesktop после того, как он уже был назначен рабочему столу оконным менеджером. Я только что написал тестовый код, и он подтвердил мои воспоминания. Если поток когда-либо создавал окно на одном рабочем столе, даже если это окно с тех пор было уничтожено, ему никогда не будет разрешено использовать SetThreadDesktop () на другом рабочем столе и создавать окна там.