Installer Testing: Automating Windows Logon

Suppose we chose a tool that satisfies us (and here I mean not only that thing from the last article , but also sane tools like TFS etc), even made him do some part of the work for us. We were able to automate the installation of the product and now it seemed that happiness, it - here, lend a hand and ... find out that at the last stage of the installation we need to survive a reboot of the system. And maybe even later boot under a limited account \ domain \ other account. And if you are so unlucky that your product modifies msgina.dll, then ... yes, yes, I mean, we need to get into winlogon and automate the login of the account.

It would seem - what can stop us? We will create a service that starts after a reboot, which will revive the process with the necessary autotest, and it will already read from the file - under which user to boot and do all the work.

Anamnesis

As planned, I created the service, looked that it can run the command
ping localhost > c:\outping.txt
immediately after rebooting, before entering the system. Replaced ping with my autotest, and nothing worked . Services that can start before the first login are started on behalf of the localsystem system account and cannot be interactive . This means that when running my autotest did not receive a system object that describes the windows displayed on the screen, the so-called desktop. The bottom line is that in the windows system there are three areas in which you can display windows - default (loaded after entering the login / password), winlogon (displays the familiar authentication request) and an invisible area for non-interactive services.Switching between these areas can be done by calling the winapi function SetThreadDesktop

“Ok,” the encoder thought, “All you need to do is call one winapi function, start your autotest, and compile it with a static link so that the tester does not suffer from dependencies.
-Ok, - the tester thought, - All in all, now it will be necessary to check the program on all systems to run the prog.
One cannot fail to test a testing tool. However, I didn’t take this path - recently, when I met with obscure things in the behavior of Windows that threatened to invent bicycles, I began to resort to building a query to Google, starting with the last name: Russinovich. It worked now. PSexec will help us out .

Recipe

1. Download srvAny and install it in a test environment
2. Specify the line in the Application parameter of the srvAny program "полный\\путь\\к_psexec\\PSexec.exe /x /s /d /accepteula cmd.exe".
   The / x parameter itself provides startup in the winlogon environment
3. We will reboot, wait for an invitation to authenticate, if everything is done correctly, the cmd console will loom in the background (on windows 7 it may not loom, but you can switch to it by pressing alt + tab). We will replace cmd with our autotest (for tfs, as I understand it, you need to run a test agent with some parameters) entering the login password \ checking the operation of the new msgina. Done.