I am trying to do HLK testing for my own driver by this instruction https://msdn.microsoft.com/ru-ru/library/windows/hardware/dn915002(v=vs.85).aspx , but I have problems.
I can not do step 5 as I do not see my driver in the list of .sys files I can select for testing in HLK Studio selection tab.
My driver is stored on test machine in location C:\MyDriver\mydriver64.sys. It is 64-bit kernel mode driver used by my application for RAM analysis.
What can I do to add my driver to the selection list and run HLK tests for it?
Thank you.
Make sure the driver is running on the machine
Make sure the machine status is set to ready.
Restart the HLK service on client. (go to services, search for hlk, R-click, restart)
Restart the HLK service on server. (same as client)
Check the machine status again, give it some minutes to get ready
If still not working, try restarting both systems
Sometimes HCK Infrastucture Service crashing, but HLK Communication service still works. You need restart HCK Infrastructure service too. On my job, we had a problem with very long start time of this service and Windows throws timeout error for service start. Because of this, service never starts. We solved this problem, by setting bigger time for service start in Windows registry.
Registry key is HKLM\SYSTEM\CurrentControlSet\Control\ServicesPipeTimeout
Make sure the driver is running on the test machine.
Start "HLK Manager", click on "My Machines..."
Select your test machine from the list, right click, "change-status" to "unsafe"
Open "HLK Studio" ... "Configuration"
Find your test machine, right click, "change machine status" to "ready"
Load your project and check for your driver under "Selection"
What kind is your driver? Please provide your inf file or registry entry.
Do you search it under "software device" or "device manager"?
Be sure to
install driver prior to client
start driver
select software device in Studio's Selection tab
I was looking for my driver in "device manager" which was the default and not finding it as it is a driver hence software. Spent far more time on that problem than I'd like to admin
Restart Client Machine
Restart HLK Communication service.
Restart HLK Infra Service.
Now try to load the machine pool, Issue should have resolved now.
Related
We are attempting to do our testing remotely, so we set up some Virtual Machines to run our GUI tests and to free up our local machines. What we were hoping for was to have the tests run just like they would on a physical machine, however they seem to require an active Remote Desktop Connection up in order to run properly. These tests are written using LeanFT and it is a windows app so this is not mobile GUI testing.
Is there a certain way to configure this VM to set it up properly for automated GUI testing that does not require an active Remote Desktop Connection? It seems as if its sharing the controls on our physical machine..
Or am I completely wrong here.. Is a Remote Machine different than a Virtual Machine? Thanks!
It's possible to run a GUI test without an active Remote Desktop Connection
I achieved this with leanft through the following 2 steps:
Configure how you execute your tests
Whether you're running via a Jenkins slave or through another kind of "listener" (maybe ssh, or bamboo, etc.), you need to configure this listener to start after a specific user is logged on.
In my case I was running through the Jenkins slave, so I've configured the startup of the slave to launch as soon the user logged in.
Tell windows to login the user when the computer starts. You can achieve that via the following registry:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"DefaultDomainName"="DOMAIN"
"DefaultUserName"="USERNAME"
"AutoAdminLogon"="1"
"DefaultPassword"="PASSWORD"
The core requirement is that you need to have an active session (regardless of whether you are using Jenkins, TeamCity, Grid or other tools to launch the tests).
For your virtual machine, you will need to have access to the console. For VMWare vSphere, there is a native client or website. For VMWare Workstation or VirtualBox, these automatically display.
Using the console access, log into the system and set it up to never log out or sleep or hibernate. This is a variety of OS settings that you can look up.
Essentially, these boxes need to always be logged in. With this setup, you need to be sure access to these systems is controlled so that you don't have random people logging in / or logging out.
So that we may perform front-to-back web UI testing, we are using Selenium and ChromeDriver to automate page loads/interaction as part of our testing pack.
This is behaving as expected during developer testing (on a developer's local machine), but we are struggling to perform these checks as part of our continuous integration build.
Our server plant is *NIX based, and all of our CI infrastructure runs on these machines. So that we may test Chrome under Windows (our delivery mechanism), we have configured a Selenium Grid. When the CI tests run, they access the grid, in order to locate a Windows node to run the tests on.
We have had a Windows desktop provisioned solely for the purpose of running these tests. This contains our standard enterprise build of Windows 7. This machine will be periodically rebooted in-line with the IT department's update policy.
In an effort to ensure the Selenium server is always running, we have added the Selenium Server (running in "node" mode) as a Windows service. The selenium Server is configured to start-up ChromeDriver to invoke the simulated user-interaction.
However, when running the tests from CI they fail due to timeout. Our working theory is, the system user that is running the service cannot create interactive windows. A web search has raised reference to the "Session 0" problem, but with little to no constructive advice on how to move forward.
Starting the Selenium Server process manually from an interactive session is not a viable solution, as this is leading to brittle tests - which are failing due to an infrastructure problem, rather than a genuine test regression.
How can we have an instance of Selenium Server started via a Windows Service whenever the system reboots, that is capable of launching Chrome instances?
It could be easily done with NSSM.
Installation of services looks like these:
nssm install seleniumhub java -jar C:\selenium\selenium-server-standalone-2.45.0.jar -role hub -hubConfig C:\selenium\hub.json
nssm install seleniumnode java -jar C:\selenium\selenium-server-standalone-2.45.0.jar -role node -nodeConfig C:\selenium\node.json
It provides easily way to remove service if needed:
nssm remove seleniumnode confirm
Add destination to nssm to your PATH variable and run from console as admin
UPDATE April 2021
NSSM is not supported for more than 3 years. So please consider other options like winsw or any other. WinSW does the same job as NSSM and allows to keep run configuration in xml.
You cannot run Selenium Grid as a windows service ever since Windows Vista. Microsoft calls it "Session 0 Isolation". You could do it in Windows 2000 or XP but since the time that Vista came out, Microsoft no longer will let Grid interact with the desktop (or any other UI programs for that matter). Regardless of the fact that you still see that "interact with desktop" checkbox, it is a red herring. So, you MUST run Selenium Grid in the foreground on that server in order for it to get access to the session. If it is running Windows Server, you could in theory have multiple sessions and leave Grid running in the foreground on one of the non-zero user sessions.
Right now you can't help it - it used to work fine in session 0 but for the past few days after chrome update only works for interactive sessions.
Related bugs:
https://code.google.com/p/selenium/issues/detail?id=8029
https://code.google.com/p/chromium/issues/detail?id=422218
My preferred solution to this problem (and my default choice for running Selenium Grid as a service) is to use a simple tool called AlwaysUp. It has a free 30 day trial to try it out.
What to do:
Download AlwaysUp
Configure AlwaysUp to start the Selenium Grid node on startup
Configure AlwaysUp to run the Selenium node as a specific user (not the default System user)
This way the the node will run as a service, survive machine restarts and work with the latest version Chrome.
If the user account you use to login to the machine is different from the user account you specify to run the node as a service then you will not see the browsers pop up on the desktop as they are running in a different user session. The end result is that it is almost identical to running as a normal service but gets round the Session 0 issue.
Yeah, you should use NSSM. Important is, that you add your windows account in the "Log on" tab, or any other valid account. If you run your node with the "Local System account" option, you will get the session 0 problem. With a normal user session, the nodes run smoothly invisible in the background :)
we don't use selenium GRID, we were disappointed with its stability. We use a "Jenkins Grid", that is jenkins slaves nodes on various servers.
The slaves are services with the interact with desktop flag. They run as services with NSSM, and the SERVICE_INTERACTIVE_PROCESS flag. Making sure that NoInteractiveProcess is set to 1 (cf https://learn.microsoft.com/en-us/windows/desktop/services/interactive-services).
We don't have the fancy features of the grid (that is balancing according the browser types slots). Instead, we have Jenkins balancing the test jobs using a slave node or another.
Initially we did not use the interact with desktop flag, having browsers to run without "real" display, but the behavior was not very stable (especially with resize commands).
Hope this helps.
As I explained on this thread, I found that using a small paid tool FireDaemon Pro saved me a lot of time from trying to configure NSSM and other free tools.
It works well in the background, and restarts Selenium along with the server, which was my main requirement for running Selenium Standalone Server as a Windows Service.
This free tool would probably do it:
http://yajsw.sourceforge.net/
For that to work, you need a wrapper.conf file and a script to run the YAJSW wrapper. I takes time to read the documentation, but it is a free solution.
I wrote an example shared here, that installs JBoss7 as a Windows service.
Of course, you can simplify my example by a lot.
Apologies, I'm still fairly new to selenium so please bear with me as I explain this.
Currently my selenium tests are running on a remote machine but no window opens when I'm remotely logged into that machine!
My setup is:
Remote machine has 2 admin users with Selenium Grid2 and a node as a windows service.
The machine is running windows server 2012 with the services having Interactive services enabled.
I am using Selenium 2.42.1 with IEDriver version 2.42.0
Tests are being built and run remotely on our build server.
I think that's everything, if there's any more information then please let me know as I'd really like to know why I cannot view my tests running.
Just for clarification, the tests are running and they successfully pass or fail where necessary, but I just can't see it if I'm remote logged into the machine.
UPDATE
There has been some interesting progress on this issue but still no resolution.
I decided to try and run a node from command line and funny enough the tests run with no problems and the browser window is displayed.
So if anyone has any idea why a browser window would appear when running a node from command line but not when running a node as a service would be great.
I'm using java service wrapper to create my service and im using the same nodeconfig.json when running the node.
This can happen when you are running the node as a windows service. There is an option in service to say whether the job should run in background or interact with desktop. Check that and you should see the windows.
I configured Jenkins as Selenium Grid and some Jenkins Nodes as Selenium Nodes (controlled by Jenkins Selenium plugin).
The nodes are connected with the option "Let Jenkins control this Windows Slave as Windows Service".
The service is defined automatically at the node as "interact with desktop".
Jenkins slave enables Selenium remote driver service
The problem is that the resolution of UI tests is really low (1036 x 780) where we need (1600x1200).
Opening an RDP session doesn't help since the service was started by Jenkins.
How to change the default resolution of windows service that can interact with Desktop?
I had the same problem as yours. Difference was I also have GUI automation besides Selenium tests. I ended up installing VNC service on all the nodes and wrote a script to change the desktop resolution before running any tests. However the highest resolution by doing that we got is 1280x1024, which resolved my problem.
If you don't mind giving up running Jenkins Slave as Windows Service you can use this way:
Jenkins on Windows and GUI Tests without RDC
Still - that would make you maintain an open RDP session that runs Jenkins JNLP process... So that solution is working, but not very optimal.
I have a jenkins agent set up on window 7 and a jenkins server on Linux. I am running GUI testing on the windows agent. It runs fine if I have a remote desktop connection connected to it, but fails otherwise. I found this link, Jenkins on Windows and GUI Tests without RDC
But the solution provided there is pretty vague.. It seems like the only solution is to somehow make Jenkins server to have a remote desktop connection open at all times. But I can't find such an option to do so.
Could anyone please clearly teach me how to solve this issue?
Much appreciated!
Your slave machines have to be at a desktop before the test can run
properly. We had the same problem.
Solution was to have the test machine start up and auto-logon to the
desktop. To ensure that the test would ONLY start after the desktop
was available, we added a scheduled task, set to run at user login,
that would launch the Jenkins slave via Java Web Start. That way,
Jenkins would only see the slave once the desktop was running. After
that, everything worked fine.
This is the winning answer to the question you linked to and it is very clear on what to do. The whole setup is outside of Jenkins. Jason Swager discribed on how he automated a user logging into a windows desktop machine and then starting the Jenkins slave in the user session.
And now Step by step:
1. make sure you have a GUI evailable
Solution was to have the test machine start up and auto-logon to the desktop
Configure a standard Windows desktop to login a specific user automatically when windows start. This way nobody needs to physically log into the desktop. (see How to turn on automatic logon in Windows 7)
2. start Jenkins slave
You need to start the Jenkins slave within this user setting. Otherwise, the Jenkins slave won't have access to the Windows UI components (or in other words can not interact with the desktop).
To ensure that the test would ONLY start after the desktop
was available, we added a scheduled task, set to run at user login,
that would launch the Jenkins slave via Java Web Start.
So you have to create a scheduled task and configure it to start your Jenkins client using Java Web Start.
3. use it
That way, Jenkins would only see the slave once the desktop was running. After
that, everything worked fine.
When the slave is online, you can use it to run your UI tests.
To solve it, set Windows Auto-Logon as I explain here:
https://serverfault.com/questions/269832/windows-server-2008-automatic-user-logon-on-power-on/606130#606130
Then create a startup batch for Jenkins slave (place it in Jenkins directory), which will launch it's console on desktop, and will allow GUI jobs to run:
java -jar slave.jar -jnlpUrl http://{Your Jenkins Server}:8080/computer/{Your Jenkins Node}/slave-agent.jnlp
(slave.jar can be downloaded from http://{Your Jenkins Server}:8080/jnlpJars/slave.jar)
EDIT :
If you're getting black screenshots (when using Selenium for example), create a batch file that disconnects Remote Desktop, instead of closing the RDP session with the regular X button:
%windir%\system32\tscon.exe %SESSIONNAME% /dest:console
The following thing did the trick for me:
In Jenkins execute windows shell command:
cmdkey /generic:TERMSRV/<servername> /user:<username> /pass:<password>
mstsc /v:<servername> /w:<width> /h:<height>
cd <path to your pom.xml>
<maven command>(e.g. mvn test -Dfiles_to_run=groupLaunch.xml
cmdkey /delete:TERMSRV/<servername>
It creates real mstsc session (Win-to-Win) with specified width and height in your virtual mstsc session (Jenkins-to-Win) powered by Jenkins.
I tried the solutions provided here but nothing worked for me. At the end, I came up with a workaround.
I opened an RDP connection to the VM in a different VM (VM2).
I left the first connection open inside VM2 and disconnected from it.
It worked but that implies having two virtual machines available.
You still need to use RDP but in my case, we can use loopback of the RDP in same VM.
The procedure:
In a VM, create two different accounts, and create Jenkins slave for both of account.
Now you'll have two Jenkins slave for two accounts in one VM
slave 1 - account 1
slave 2 - account 2
Enable multiple RDP follow guide
https://www.serverwatch.com/server-tutorials/how-to-enable-concurrent-remote-desktop-sessions-in-windows.html
In slave 2(with account 2), run rdp command to connect to slave 1(with account 1), like following
Start /b "" "C:\RDP\rdp.exe" /v:127.0.0.2 /domain:\ /u:admin /p:xxxx /fullscreen /w:1920 /h:1200
127.0.0.2 is very important, it's a loopback connection for RDP
Put above command into Jenkins job with the name such as "OpenRDP_ToVMXXX, and then you can run any test on slave 1 with GUI enabled, enjoy.
As the solutions above seemed a bit overkill, I used this approach:
Disable Jenkins service
Start Jenkins from command line using java -jar C:\Program Files (x86)\Jenkins\jenkins.war
For some reason I had to install all plugins and everything when starting it this way, so I recommend creating a backup, there is a plugin for that. Good luck. :)