Closed ks-jeppe closed 7 years ago
Thank you for the detailed report. I am unable to repro this even in a fast loop. Also, on what version of vswhere and the query API (newer versions will print both in the header for the default formatter) are you running?
Pausing the process could yield any possible stack trace. Are you able to generate a dump when the process is hung?
Version header says: Visual Studio Locator version 1.0.66-g24f19ddd29 [query version 1.10.80.60812]
The backtraces from the report are when the process is hung. They always look the same.
Do you mean a .DMP file? I could, but I lack a place to host it as it's about 14 megabytes zipped.
Those seem to be privately built bits. Can you repro with official builds? Are you building with a Preview release of VS? If not, what version of VS?
If you've signed into VS, your Microsoft Account is already hooked up to OneDrive or signing up for other services like Dropbox could provide space for a .dmp.
I can't seem to reproduce it with official builds.
The one I built was built with VS 2017, version 15.2 (26430.6) Release
Release or Debug configuration? This might be an issue to take up with the Visual C++ team. From the stack it seems there could be a deadlock scenario but the query API and vswhere don't directly create or use any locks.
It happens all the time in the Debug configuration. I'm not seeing it right now in release configuration, but I think it might have happened once.
I found a way to reproduce it on multiple computers with the debug build where it has 2017 and at least also 2015 installed.
for /l %i in (1,1,10000) do vswhere.exe -legacy -latest
It definitely sounds like a Visual C++ runtime bug with a DLL loader deadlock
About the time it is done loading the solution vswhere.exe will be hanging in a state where it cannot be killed with Ctrl+C
Maybe related: happens also when I hit Ctrl-C during VsDevCmd.bat
, process hangs.
Seems this is a known issue that was fixed in a newer, currently non-default UCRT. To work around this issue in your own code, you can add the following to the vcxproj files:
<TargetUniversalCRTVersion>10.0.14393.0</TargetUniversalCRTVersion>
I'll not be making this change to the vswhere code base since the default is for the LTS release of Windows 10. When the default changes, we'll get it automatically. Until then, since it does not repro in release builds and with a work around available, I'm resolving the bug. If this becomes a larger problem we can reconsider making the change for all builds.
Sometimes when I call vswhere with '-latest -legacy' multiple times it will hang indefinitely.
This happens both with the release and debug version, but a colleague couldn't reproduce the issue with a fairly similar setup.
My machine has VS2015 Pro, and VS2017 Pro. It also has remnants of uninstalled versions going back to VS2008 but these are correctly not being detected when vswhere works correctly.
Attaching and pausing the process running a debug build shows two threads with the following stack traces: