NUnitEngineException : Unable to acquire remote process agent

@niwe commented on Fri Apr 27 2018

I’m trying to start some tests with nunit3-console.exe (v3.8.0) on a virtual machine running Windows 10 (x64) but before any tests get executed NUnit stops. I get the following error messages:

Unhandled Exception: NUnit.Engine.NUnitEngineException: Failed to start remote test agent.
   at NUnit.Engine.Services.TestAgency.OnAgentExit(Object sender, EventArgs e)
   at System.Diagnostics.Process.OnExited()
   at System.Diagnostics.Process.RaiseOnExited()
   at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   at System.Threading._ThreadPoolWaitOrTimerCallback.PerformWaitOrTimerCallback(Object state, Boolean timedOut)

And after a few more seconds this is shown:

1) Error :
NUnit.Engine.NUnitEngineException : Unable to acquire remote process agent
--NUnitEngineException
   at NUnit.Engine.Runners.ProcessRunner.CreateAgentAndRunner()
   at NUnit.Engine.Runners.ProcessRunner.RunTests(ITestEventListener listener, TestFilter filter)

I recently added the flag –x86 to NUnit and that’s when this issue started. I added the flag because I also added an external file (Microsoft Exression Encoder) to my test project, and it seems to be x86 only. I read (on Stackoverflow I think) that using –inprocess works. I used to have that flag but it is not compatible with –x86. So I can’t get it to work no matter how I try.

This is the command I use to run NUnit: nunit3-console.exe C:\...\GUITests.dll --x86 --where "cat == .NIGHTLY" --result="C:\...\Logs\TestResult.xml;format=nunit2"

---

@rprouse commented on Fri Apr 27 2018

Are any of the other assemblies that your tests reference or that your code references x64?

How did you install NUnit Console and what version are you using?

I will likely move this issue to the NUnit.Console repository, but would like to confirm here first.

---

@niwe commented on Mon Apr 30 2018

I’m not entirely sure how I can see if assemblies are x64 or not.

In my Visual Studio solution I have three projects. The project where NUnit is used (and Microsoft Expression Encoder) I only reference some standard .NET 4.5.2 assemblies (and one of the other projects). In the other two projects I reference WebDriver and Netwonsoft.Json.

On the machine (VM) where it’s not working I installed NUnit with NUnit.Console.msi (3.8.0). On the machine where it’s working (my workstation) I installed NUnit via NuGet, in Visual Studio, and I start the tests within Visual Studio using NUnit3TestAdapter.

I see now that I’m running NUnit 3.9.0 on my workstation. I will upgrade to 3.9.0 on the VM and see if this helps…

---

@niwe commented on Mon Apr 30 2018

Hmm, I think I have mixed it up. I thought nunit-console and nunit was pretty much the same thing. Now I see that version 3.8.0 is the latest as far as nunit-console goes. So I am running the latest versions on both machines.

Any tips on how I can get this working?

---

@ChrisMaddock commented on Mon Apr 30 2018

Try uninstalling the NUnit3Adapter NuGet package, and then running with the NUnit.Console msi on your VM.

I think there may be a discovery issue with the adapter and msi currently using different using different version of the NUnit engine.

---

@cmoonExpedia commented on Tue May 01 2018

Could anyone expert in NUNIT library explain why NUNIT needs to acquire the remote agent even though the tests run in only local? What is going on under the hood?

Thanks.

---

@CharliePoole commented on Tue May 01 2018

In this case “remote” merely means “in another process.” NUnit console runs each assembly in a separate process by default. The process has to be started and then connected to in order to issue commands telling it to load and run the tests. The technology used to do this is called “.NET Remoting.”

---

@WereDev commented on Thu May 10 2018

I recently started getting this issue as well. It happens with all solutions/assemblies. I’ve tried uninstalling/reinstalling NUnit which didn’t help, though don’t much expect it to given that it’s using the one pulled down from NuGet local to the solution. Tried deleting those files to have them pulled down again, but that didn’t help either. Again, not really surprised as this suddenly affected all of my solutions at once. I’m not sure what might have changed on my system to cause the issue.

---

@ChrisMaddock commented on Thu May 10 2018

@WereDev do you have nunit installed via the msi, on anything nunit-y on you path vars- in addition to our nuget packages?

---

@WereDev commented on Thu May 10 2018

Had it installed (and reinstalled) via the MSI. Actually have it uninstalled now as the scripts seem to be running console from the nuget packages. Nothing in the environment vars. Haven’t checked the registry yet, but I’m unsure what to look for there.

---

@niwe commented on Thu May 24 2018

I finally found a solution to my issue. Hopefully someone can I explain why this is happening.

I ran my tests using (which gave an exception): C:\PROGRA~1\NUnit.org\nunit-console\nunit3-console.exe C:\...\GUITests.dll

But running it this way works: "C:\Program Files\NUnit.org\nunit-console\nunit3-console.exe" C:\...\GUITests.dll

Don’t know it doesn’t work the original way. No big deal for me, I found a workaround so I’m happy. Maybe it helps someone else running into the same problem.

FYI The reason why I use PROGRA~1 instead of Program Files is (I think… it was a long time ago 😕) because I couldn’t install NUnit (MSI package), using the flag TARGETDIR, without using the old DOS 8.3 name. And then I reused that path variable when starting NUnit.

---

@rprouse commented on Wed May 30 2018

@niwe what version of the Console do you have installed?

---

@niwe commented on Thu May 31 2018

@rprouse I installed NUnit using NUnit.Console-3.8.0.msi (from https://github.com/nunit/nunit-console/releases)

---

@Hu3bl commented on Thu Jun 21 2018

We see the same issue on our CI server (Windows Server 2012R2). Occasionally, we get the error

NUnit.Engine.NUnitEngineException : Unable to acquire remote process agent --NUnitEngineException at NUnit.Engine.Runners.ProcessRunner.CreateAgentAndRunner() at NUnit.Engine.Runners.ProcessRunner.RunTests(ITestEventListener listener, TestFilter filter) for every test DLL in a larger project. While looking into it, we discovered that the nunit-agent.exe processes that get launched all crash before connecting to the runner and the Windows Event Log has the following to say about that:

Application: nunit-agent.exe Framework Version: v4.0.30319 Description: The process was terminated due to an unhandled exception. Exception Info: System.ArgumentException at System.Diagnostics.Process.GetProcessById(Int32, System.String) at System.Diagnostics.Process.GetProcessById(Int32) at NUnit.Agent.NUnitTestAgent.Main(System.String[])

We suspect that something is amiss with the command line that is passed to the agent process, but cannot yet prove it.

EDIT: We checked the log files of nunit and everything looks right in the command line passed to agent. Furthermore, we found the issue #117 that describes a similiar behaviour of nunit. The described workaround to run nunit --inprocess does not work for us since we don’t have a 32bit process. However, adding --agents=1 results in running tests, but really slow.

When checking the output of nunit without the --agents=1 option, we see that at least one process finds some tests in a test DLL, but every other test DLLs show the exception we described above. We pass a complete solution file including all tests projects to the nunit console. As said above, we’re using Windows Server 2012 R2 with .NET Runtime 4.5.1, nunit console 3.8.0 and our test projects use nunit framework 3.10.1.

---

@ChrisMaddock commented on Fri Jun 22 2018

@Hu3bl This is an interesting stack trace…but I’m unsure how this could occur! Are you able to share your full logs, including the agent log?

---

@Hu3bl commented on Mon Jun 25 2018

Of course I’m allowed to share the logs with you, however, I had to replace all assembly names by xxx because I’m not allowed to publish them. I called nunit with nunit3-console.exe build\xxx.sln --result:TestResult.xml;format=nunit3 --trace=Verbose The resulting files are attached as zip file. nunit.zip

---

@ChrisMaddock commented on Mon Jun 25 2018

@Hu3bl Is this all the logs that were written? No nunit-agent_6132.log? 😞

---

@ChrisMaddock commented on Mon Jun 25 2018

Never mind. Based on your stack trace, the agent will be crashing before it initialises the log.

But I’m still not sure why. 🤔 Looking at the Agent code - the line which is crashing could be delayed. The Process.GetProcessById() could be deferred to the point where the process is actually used - and we could hold on to the ID instead, and then just look it up when we need to check if it’s exited. (Which is already an ‘error-case’ in itself!)

Would you be able to give that a try, and see if it fixes your issue, or if this is just hiding a second problem? The file I’m looking at is Program.cs in the nunit-agent project.

---

@ChrisMaddock commented on Mon Jun 25 2018

@nunit/engine-team

Nice self-contained issue here. How could Process.GetProcessById() be throwing an ArgumentException from some agents but not others, when the process it is looking up (appears to be) alive and well? It’s only documented to throw this when the process is dead - I had a quick look in ReferenceSource, which seems to suggest the same…

---

@CharliePoole commented on Mon Jun 25 2018

Is it possible that the argument is not being parsed correctly in some cases?

---

@ChrisMaddock commented on Mon Jun 25 2018

I thought that at first, but I can’t see how that could be the case. The agents all receive the same command line, and 2/n connect fine. @Hu3bl’s stack trace also shows the int.Parse line doesn’t throw, but the Process.GetProcessById() does.

---

@CharliePoole commented on Mon Jun 25 2018

Locale? Grasping at straws here!

---

@ChrisMaddock commented on Mon Jun 25 2018

I think we may need to add more logging!

---

@jnm2 commented on Mon Jun 25 2018

and we could hold on to the ID instead, and then just look it up when we need to check if it’s exited. (Which is already an ‘error-case’ in itself!)

Process IDs are recycled. If possible, you want to open the process handle (GetProcessById) ASAP in case the process closes and a new process starts with the same ID. If there isn’t a reliable way to be sure the process is still running even when you call GetProcessById ASAP, the usual technique to uniquely identify a process over time is pid + start time.

---

@ChrisMaddock commented on Mon Jun 25 2018

Good shout!

---

@ChrisMaddock commented on Wed Jun 27 2018

@Hu3bl - this issue really should be in the nunit/nunit-console repo. I’m going to move it over now, and comment further over there. 🙂

[Hu3bl]

I tested another project with a much longer execution time for the tests. With the restriction to four agents, it ran 2h 5min, without restriction 2h 14min.

Like @aolszowka already mentioned, it slows down notriceable, but it is kinda project dependent. For the project we had the issues with we did not really notice a difference (only a few seconds).

[Hu3bl]

@ChrisMaddock the new version you provided does not change anything. Still the same behaviour like before. Our CI server is a virual machine with 4 cores attached. I had no issues the last days running nunit with --agents=4.