Failed to initialize client proxy: could not connect to vstest.discoveryengine.x86.exe

Question

Before, I was able to run the unit tests of a particular project under Visual Studio 2013 just fine. This has recently stopped working without major changes to the project, and unfortunately I do not recall when it did last work, nor what changed since. However, any modifications to the project itself were minimal (one or two new methods), and did not involve any configuration file changes or similar frequently reported issues. I believe rather that a change in Visual Studio (perhaps a recent update), or plug-ins or third party software is causing the following issue.

While loading the project, after one minute the "Tests" output in the Output Window shows:

------ Discover test started ------
Failed to initialize client proxy: could not connect to test process vstest.discoveryengine.x86.exe.
========== Discover test finished: 0 found (0:00:59.8853102) ==========

Similar to a previously reported problem where just debugging stopped working, running Visual Studio as administrator seems to 'resolve' the issue. However this is simply an indication the problem might have got something to do with access rights.

I found a related Microsoft Connect bug report, which also hints at the problem being caused by a third party application. Apparently vstest.discoveryengine.x86.exe uses named pipes to communicate with devenv.exe. Another application could consume the request, thus resulting in a failed connection for Visual Studio. However, verifying which named pipes were in use, I did not find any immediately obvious culprits. I also imagine the connection might fail for other reasons.

After enabling logging for devenv.exe, vstest.executionengine.exe and vstest.discoveryengine.exe I found the following exceptions related to the discovery engine in the devenv log:

E, 10048, 42, 2014/12/22, 01:47:13.683, 63637924754, devenv.exe, TestRunnerServiceClient: Could not connect to test runner service within the available time 60000. Reason:System.ServiceModel.EndpointNotFoundException: There was no endpoint listening at net.pipe://steven-flip/vstest.discoveryengine/8232 that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.

Server stack trace: 
   at System.ServiceModel.Channels.ConnectionUpgradeHelper.DecodeFramingFault(ClientFramingDecoder decoder, IConnection connection, Uri via, String contentType, TimeoutHelper& timeoutHelper)
   at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.SendPreamble(IConnection connection, ArraySegment`1 preamble, TimeoutHelper& timeoutHelper)
   at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.DuplexConnectionPoolHelper.AcceptPooledConnection(IConnection connection, TimeoutHelper& timeoutHelper)
   at System.ServiceModel.Channels.ConnectionPoolHelper.EstablishConnection(TimeSpan timeout)
   ...

... and later on, a similar exception for vstest.executionengine.exe

E, 10048, 40, 2014/12/22, 01:47:15.600, 63642778910, devenv.exe, TestRunnerServiceClient: Could not connect to test runner service within the available time 60000. Reason:System.ServiceModel.EndpointNotFoundException: There was no endpoint listening at net.pipe://steven-flip/vstest.discoveryengine/9884 that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.

Server stack trace: 
   at System.ServiceModel.Channels.ConnectionUpgradeHelper.DecodeFramingFault(ClientFramingDecoder decoder, IConnection connection, Uri via, String contentType, TimeoutHelper& timeoutHelper)
   at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.SendPreamble(IConnection connection, ArraySegment`1 preamble, TimeoutHelper& timeoutHelper)
   at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.DuplexConnectionPoolHelper.AcceptPooledConnection(IConnection connection, TimeoutHelper& timeoutHelper)
   at System.ServiceModel.Channels.ConnectionPoolHelper.EstablishConnection(TimeSpan timeout)

The execution engine seems to start correctly and waits for incoming requests. The last entry is: TestExecutorService: Created/Started the listening channel. ChannelUri=net.pipe://steven-flip/TestExecutor/4912.

Same goes for the discovery engine of which the last line is: I, 8232, 1, 2014/12/22, 01:46:13.942, 63486587413, vstest.discoveryengine.exe, ServiceMain: Started the service host 8232

Did anyone encounter similar problems? How to best tackle this? I do not find constantly running Visual Studio as administrator to be a suitable solution.

Answer 1

I had the same problem using Visual Studio 2015 on Windows 10. After doing a lot of debugging, it turned out the problem was in another program:

The separate vstest executables communicate with the main engine (running in Visual Studio or in the VSTest Console) using WCF over named pipes (the net.pipe protocol, with an endpoint URL e.g. net.pipe://machinename/vstest.discoveryengine/12345). As it turns out, whenever an application running under a privileged account listens on a net.pipe URL which is a prefix of another URL, no other unprivileged account can listen on the longer URL (only when running as administrator they can).

And, as it turns out, there are various applications out there which run as administrator or local system listen on net.pipe://localhost/. In that case, no WCF application, including the VSTest processes, running under an unprivileged user can run a server on named pipes at all. You can try creating a minimal WCF example running on netpipes. Even that trivial example worked on my machine only when run as administrator (otherwise, “There was no endpoint listening at net.pipe://…” ensued).

I used Sysinternals Process Explorer, Ctrl+F and searched “net.pipe” to find processes with netpipes open. In my case, it was Razer’s “RzWizardService” keeping a WCF server with an endpoint directly under “net.pipe://localhost/” running as a local system service. When I stopped the service, everything started to work fine.