Допустим, мы выбрали удовлетворяющий нас инструмент(и тут я имею в виду не только ту штуку из прошлой статьи, но и вменяемые инструменты навроде TFS etc), даже заставили его делать какую-то часть работы за нас. Мы смогли автоматизировать установку продукта и вот уже казалось, что счастье, оно — вот, протяни руку и… обнаружь, что на последнем этапе инсталляции нам необходимо пережить перезагрузку системы. А может быть даже в последствии загрузиться под ограниченной учетной\доменной\прочей записью. А если не повезло настолько, что Ваш продукт — изменяет msgina.dll, то… да-да, я имею в виду, что нам надо влезть под winlogon и автоматизировать вход учетной записи. 
Казалось бы — что может нас остановить? Создадим службу, стартующую после перезагрузки, которая оживит процесс с нужным автотестом, а он уже прочтет из файлика — под каким пользователем загрузиться и сделает всю работу.Анамнез
Как и задумано, я создал службу, посмотрел, что она может запускать команду
ping localhost > c:\outping.txt сразу после перезагрузки, до входа в систему. Заменил ping на свой автотест, и ничего не сработало. Службы, которые могут запуститься до первого входа в систему, запускаются от имени системной учетной записи localsystem и не могут быть интерактивными. Это значит, что будучи запущенным мой автотест не получил объекта системы, который описывает отображаемые на экране окна, так называемый desktop. Суть в том, что в системе windows существует три области в которые можно отображать окошки — default(грузится после ввода логина\пароля), winlogon(отображает всем знакомый запрос аутентификации) и невидимая область для неинтерактивных служб.
Фраза такая обтекаемая
Переключение между этими областями можно осуществлять вызовом функции winapi SetThreadDesktopЯ тут сознательно избегаю терминологии, дабы статья не выросла в это или цитирование главы «Сеансы, оконные станции, рабочие столы и оконные сообщения» книги Марка Руссиновича «Утилиты Sysinternals. Справочник администратора»
-Ок, — подумал кодер, — Всего-то надо вызвать одну функцию winapi, стартануть свой автотест, ну и скомпилить статической линковкой, чтоб тестер не мучился с зависимостями.
-Ок, — подумал тестер, — Всего-то теперь надо будет проверить на всех системах еще и прогу для запуска прог.
Нельзя же не тестировать инструмент тестирования. Однако я не пошел по этому пути — с недавних пор, при встрече с непонятными вещами в поведении Windows, грозящими изобретением велосипедов, я стал прибегать к построению запроса к гуглу, начинающемуся с фамилии: Руссинович. Это сработало и сейчас. Нас выручит PSexec.
Рецепт
- Скачаем srvAny и инсталлируем ее в тестовую среду
- Укажем в параметре Application программы srvAny строчку
"полный\\путь\\к_psexec\\PSexec.exe /x /s /d /accepteula cmd.exe".
Собственно параметр /x и обеспечивает запуск в рабочем окружении winlogon - Перезагрузимся, дождемся приглашения к аутентифиации, если все сделали правильно — на заднем фоне замаячит консоль cmd(на windows 7 может не замаячить, но переключиться на него можно нажав alt+tab). Заменим cmd на свой автотест( для tfs я так понимаю надо запускать тест-агента с некими параметрами) вводящий логин-пароль\проверяющий работоспособность новой msgina. Готово.