How to enable UTE logs?

Unit test explorer has bunch of processes (client-process, discovery/datacollection process, execution process) and depending upon what you want to debug, you should select the appropriate process and enable its logs. Once you have enabled the logs, the logs will get generated in %Temp% folder with log file names of the format <ProcessName>.TpTrace like vstest.executionengine.TpTrace.log Here are the steps to enable log for a given process: –

  • Open the configuration file of the process like (vstest.executionengine.exe.config)
  • Change the TpTraceLevel from 0 to 4.

<add name="TpTraceLevel" value="0" />

Note: – This xml does not exist in devenv.exe.config, so if you want to enable logs of visual studio, you should copy the above xml with TpTraceLevel as 4 and put it in devenv.exe.config.

  • Save the configuration file.
  • Restart your client so that the configuration file gets applied.
  • Do a discovery or a test run and now you will observe the logs in %temp% folder.


  • Discovery/datacollection happens in vstest.discoveryengine* process and execution happens in vstest.executionengine* process when done from VS (out of process mode). For command-line by default discovery/execution happens in the same process (vstest.console.exe)
  • The UTE binaries (like vstest.console.exe, vstest.executionengine*.exe… ) are installed typically in %VSInstallDir%\Common7\IDE\CommonExtensions\Microsoft\TestWindow folder.
Comments (15)

  1. leniel says:


    I changed the value from 0 to 4 and also placed that XML in devenv.exe.config. Restarted VS 11 Ultimate Beta and then tried the Run All in Unit Test Explorer. I got the same error and when I went to check the %Temp% folder there were no logs there. I restarted Windows 7 and even after that nothing got generated.

    I tried to find any files with TpTrace in Windows Explorer and nothing appeared…

    What's the problem?


  2. Leniel,

    This seems strange. Can you please share the xml block from your devenv.exe.config file? Also can you please try changing the log level in the command-line (vstest.console.exe.config) and see whether that works or not?

    For your original problem also, you can try running the tests via above command-line (with and without switch /inisolation) and see whether the test works there or not? The idea is to check whether the failure is only for VS case or is it applicable for command-line as well.


    Aseem Bansal

  3. leniel says:


    I finally got the devenv.TpTrace.log. I was looking at the wrong %temp% path in C:WindowsTemp. I opened a command line and typed %temp% and saw that it's pointing to C:UsersLenielAppDataLocalTemp. My bad… 🙂

    This is the the log content:

    This is the exception:

    W, 2124, 19, 2012/04/19, 11:51:32.644, 53768626724, devenv.exe, Exception occured while initialization System.InvalidOperationException: Cannot start process because a file name has not been provided.

      at System.Diagnostics.Process.Start()

      at Microsoft.VisualStudio.TestPlatform.Core.Utilities.CommonUtilities.LaunchProcess(String exeFileName, String commandLineArguments, String workingDirectory, IDictionary`2 environmentVariables)

      at Microsoft.VisualStudio.TestPlatform.Client.TestRunnerServiceClient.SetupProcess(Boolean forceX86Discoverer)

      at Microsoft.VisualStudio.TestPlatform.Client.TestRunnerServiceClient.Initialize_NoLock(Boolean forceX86Discoverer)

      at Microsoft.VisualStudio.TestPlatform.Client.TestRunnerServiceClient.EnsureInitialized(Boolean forceX86Discoverer)

      at Microsoft.VisualStudio.TestPlatform.Client.TestRunnerServiceClient.EnsureInitialized_NoError(Boolean forceDiscoveryInX86Mode)

    Hope you find the cause of this problem.



  4. leniel says:


    I also tried executing the tests with the mstest.exe command-line tool (using /noisolation and with isolation).

    This is the result:

    As we can see, the tests run as expected! So the problem is really something inside VS 11 Beta.



  5. Hi Leniel,

    Thanks for the logs. From the logs, it is clear that we are not able to find the resolve the path to our discovery engine process (vstest.discoveryengine*.exe) which is typically located in %VSInstallDir%Commmon7IDECommonExtensionsMicrosoftTestWindow folder.

    I, 2124, 19, 2012/04/19, 11:51:32.582, 53768357990, devenv.exe, CommonUtilities.ResolveFilePath: File path resolved to:

    To understand the issue better, can you please check the following: –

    1. Whether the discovery engine exe is present in the above folder or not?
    2. Whether a binary named Microsoft.VisualStudio.TestPlatform.Core.dll is present in the above folder or not?

    3. Whether the binary Microsoft.VisualStudio.TestPlatform.Core.dll is present in any other folder on your machine or not? The code expects discoveryengine and this binary to be co-located, hence this question.


    Aseem Bansal

    PS: – In VS 11, there is a new command-line named vstest.console.exe which you should have used instead of mstest.exe.

  6. leniel says:


    1 – Yes, it's present.

    2 – Yes, it's present.

    3 – Yes, it's also in C:Program FilesMicrosoft SDKsWindowsv8.0ExtensionSDKsTestPlatform11.0RedistCommonConfigurationneutral

    See the screenshots:


  7. Leniel,

    Thanks for the information and they all seems correct.

    To dig little deeper, can you please share the following: –

    1. Does the test works from vstest.console? This new command-line tool is also present in the same directory as vstest.discoveryengine.exe and is available in the path from the VS command prompt.
    2. Can you please check the location from which VS has loaded Microsoft.VisualStudio.TestPlatform.Core.dll? You can find that using tools like process explorer (…/bb896653)

    3. Have you upgraded your VS from dev preview to VS 11 beta or is it a clean VS 11 beta machine?

    4. Anything else which comes to your mind on why the co-location logic is not working on your machine?

    5. Can you please try on one more machine and see whether this is a machine specific issue or not?

    6. Can we have a live meeting to debug this further?


    Aseem Bansal

  8. leniel says:


    The intriguing thing is that it's an intermittent problem. If I restart VS 11 Beta 10 times, Unit Test Explorer will work only once. :o) 9 times it'll show the error: "Unexpected error detected. Check the Tests Output Pane for details." and no test gets discovered…

    1 – Yes, the test works as expected as can be seen here:

    2 – See this screenshot:

    3 – Yes, it was a upgrade!

    4 – I have no idea… I had VS 2010 installed side by side with VS 11 Beta. Decided to uninstall it because I use VS 11 Beta only… I also had VS 11 Express for Web and then uninstalled it keeping only VS 11 Ultimate.

    5 – I have no other machine at hand.

    6 – Sure. Just tell me when…



  9. Leniel,

    From #2, it is clear that the Microsoft.VisualStudio.TestPlatform.Core.dll is getting loaded from %appData%assemblydl3…. path which is causing this problem. And on searching the web for who can be copying the binary, I found the below link which seem to indicate that shadow copy is causing the problem.…/what-is-cache-appdata-local-assembly-dl3

    Do you know why shadow copy would be enabled for VS binaries? Do you have any extension installed on your machine? Can you please try running VS in safe mode and see whether things work or not?

    Meanwhile I have filed a bug in our internal system to improve the resolution logic so that no one else faces the same problem as you are facing.


    Aseem Bansal

  10. leniel says:


    I have no idea about why shadow copy is enabled…

    These are the extensions installed in VS 11 Ultimate Beta:

    When running VS in /SafeMode => Unit Test Explorer is dead after building the Test project (it's window is blank/have no content).

    The good thing is that you identified where the problem lies! 😀

    Keep up the great work… VS 11 rocks. 🙂

    All the best,


  11. Adding info for Windows Metro style apps:

    Test executor for Metro style apps (vstest.executionengine.appcontainer.exe) do not have config file. To enable logs for appcontianer test engine set environment variable "VSTESTEXECUTOR_TRACE_LEVEL=4" at USER or MACHINE level.

    After completion of test execution tptrace logs will be available at %TEMP% folder as <processname>_<timestamp>.TpTrace

  12. Varun says:

    Thanks Aseeem for the tips. However, I enabled the tptracelevel =4 in  vstest.discoveryengine.x86.exe and ran unit tests in VS. But I didnt see the logs in %Temp% folder (yea, i was looking at the right place).

    I changed the TPTraceLevel in vstest.console.exe as well. When I ran the unit tests directly vstest.console.exe,  the logs were generated.

    It kind of tells me that when the process is launche via VS (i.e a child process) this technique does not work. Do you know how to get around this problem?

  13. Varun, You can restart VS to get the logs enabled for discovery engine process.

  14. Craig says:

    Test discovery is not working for me from a particular solution. The same tests are discovered from a different solution. I enabled logging and I see messages about paths being too long, even though the paths are only around 140 characters, well within the limit.

    E, 11756, 12, 2014/09/05, 12:54:23.409, 175558430092, vstest.discoveryengine.x86.exe, TmiDiscoveryRequest: Error occured while discovering tests from source E:tfs-RV-2013CoreMainlineWebTestUnitTestsBonePlacerOrderRedirectorUnitTestbinDebugBonePlacerOrderRedirectorUnitTest.dll. System.IO.PathTooLongException: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.

  15. Craig, This is strange. To understand the problem better, can you please share whether running the tests, for the failing solution, via command-line works or not?  (On a visual studio command prompt, run something like this: –

    vstest.console "E:tfs-RV-2013CoreMainlineWebTestUnitTestsBonePlacerOrderRedirectorUnitTestbinDebugBonePlacerOrderRedirectorUnitTest.dll"  /settings:<path to your test settings file>

    Note: – I have specified test settings because the discovery engine is using TmiDiscoveryRequest which it does typically when there is an active test settings file. Ignore the settings parameter if you don't have test settings.