I have a Windows 10 machine with jenkins installed. It runs as a service under the local admin account (though I see the same issue when it runs with java -jar jenkins.war).
I configured a git/c++ project which as part of the build process runs some googletest unit test executables. The tests execute some opengl calls.
When I manually start the build process (by having a remote desktop connection to the jenkins pc and by clicking on the build button in the webinterface running on the jenkins pc), everything works ok. When a build is automatically started (because of a git commit), or when I start it manually from the webinterface on another machine, the googletests fails with “SEH exception with code 0xc0000005 thrown in the test body”. I’m pretty sure it’s the pointers to the opengl calls which are null because of failed initialization. Except for having an active screen, I don’t see any difference between the two executions. Even when i start the build on another machine’s webinterface and i have a remote desktop session open to the jenkins machine, it still fails. Anybody has an idea on how to solve this?
Hello @Jan and welcome to this community.
The behavior you’re describing, where the behavior of your tests differs when started manually versus automatically through Jenkins, can be caused by a few factors related to how Jenkins runs builds, and interacts with the Windows desktop environment. Here is one potential cause and proposed workaround:
Desktop Interaction: When Jenkins is run as a Windows service, it typically runs in the background without access to the desktop environment. When you run it manually with a remote desktop connection, it has access to the desktop. Some applications, especially those involving GUI interactions like OpenGL, may behave differently or fail when run in a non-interactive session.
Proposed workaround: To enable Jenkins to run in an interactive session, you could configure the Jenkins service to run with the “Allow service to interact with desktop” option. However, this is generally not recommended for security and stability reasons.
There are other workarounds proposed there: Jenkins windows slave service does not interact with desktop - Stack Overflow .
thanks and thanks for the suggestion. I did already try to run the service as the local system account with the option “Allow service to interact with desktop” enabled (as well as the local admin account). That does not work, it still throws the exception. Also the other workarounds of starting jenkins turn out to give the same error. It seems like it really needs a screen to be attached(or a real one, or via remote desktop connection) to be able to work…