Issue
I am automating some software testing using Jenkins on our in-house test software. It is written in C# with WPF. I am using the version of the program that has no frontend, but it still makes calls to WPF in order to start the service. The test application is launched through python scripts using subprocess.Popen
When running under the Jenkins slave process I get the following error:
Unhandled Exception: System.ComponentModel.Win32Exception: The operation completed successfully
at MS.Win32.UnsafeNativeMethods.RegisterClassEx(WNDCLASSEX_D wc_d)
...
From my research it seems that something is going wrong with the windows atom tables. The weird thing is that I don't run into the same issue when running the python scripts as a local user, it only crashes when it is the Jenkins service running the scripts.
Is there some limitation on the local atom table for windows services?
Is Jenkins hogging atom table entries?
Update 1:
I did some more research on the crash and some resources said for WPF there might be a windows handle leak, so I inserted some power shell calls to check how many active handles there are on the system.
It doesn't look like there is a handle leak from any of the software under test, I am seeing around 50-60k handles while jenkins is running the test scripts, which is consistent with what I was seeing while running it under my user account. It looks like Jenkins is interfering with WPF's ability to construct the program (The full callstack for the error is on the Main() constructor), but I have no idea why it would be doing that.
Update 2: Some extra information since I think it is relevant, here is the full call stack:
Unhandled Exception: System.ComponentModel.Win32Exception: The operation completed successfully
at MS.Win32.UnsafeNativeMethods.RegisterClassEx(WNDCLASSEX_D wc_d)
at MS.Win32.HwndWrapper..ctor(Int32 classStyle, Int32 style, Int32 exStyle, Int32 x, Int32 y, Int32 width, Int32 height, String name, IntPtr parent, HwndWrapperHook[] hooks)
at System.Windows.Threading.Dispatcher..ctor()
at System.Windows.Threading.Dispatcher.get_CurrentDispatcher()
at System.Windows.Application..ctor()
at <TestingApplication>.ScriptHost.App..ctor()
at <TestingApplication>.ScriptHost.App.Main()
So what appears is happening is the following:
- Jenkins calls the python scripts. They perform setup and all pre-condition work such as bringing up the software under test
- Python calls the TestingApplication through Popen
- The executable starts and attempts to construct the application
- WPF checks to see if there is a Dispatcher already on the thread, there is not
- WPF attempts to create a Dispatcher since one doesn't already exist
- Crash because a Dispatcher cannot be created
Again, this only happens when launched under the Jenkins service user.
Solution
So here's what I did to fix the problem: The software under test also uses WPF to create the displays, so I wanted to see if maybe i'm running out of resources by having too many things open. There are 5 SUT applications. Luckily, one of the pieces of software we run is a console that I don't need open when running tests through Jenkins. Thus I was able to not launch the console application and that freed up enough resources for the test application to run.
What this doesn't answer is:
- Why do I have less resources on a service compared to a regular user?
- Is this because of Jenkins/Python or because of Windows?
- Is there a workaround for this problem?
Those questions could be asked outside of this question so I am answering just so that it is available to someone with a similar problem and to close it. For someone who doesn't have the luxury of closing extra applications, I would ask those questions yourself.
Answered By - Jared Dobry
Answer Checked By - Katrina (JavaFixing Volunteer)