NCrunch unable to find sn.exe (VS2017 only)

Hey Remco,
We are seeing an issue where machines that only have VS2017 installed are hitting an error where they cannot find sn.exe:

NCrunch was unable to find sn.exe for re-signing an instrumented assembly. Please ensure you have the Windows SDK or Visual Studio installed on the system building this project - otherwise turn off signing using the 'Prevent signing of output assembly' NCrunch project-level configuration option, or turn off instrumentation for this project

We are seeing this in VS2017 as well as the console tool. Looking at other threads, it seems that NCrunch uses the registry to find sn.exe, but it seems on a clean machine with only VS2017 installed, the SDK path found in the registry does not contain sn.exe.
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\Windows\v10.0\InstallationFolder = C:\Program Files (x86)\Windows Kits\10\
(That is the only entry in the Microsoft SDKs\Windows node)

When I run "where sn" from a VS2017 developer prompt, I see the following path for it:
C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\sn.exe

Does the logic NCrunch uses need to be updated for VS2017 in order to support a different location in the path? Are we missing a required VS component in the install? Unfortunately we are not able to use the "Prevent signing output assembly" option.

Thanks,
Omeed

Hi Omeed,

My assumption at the moment is that these machines have a configuration set in which the sn.exe tool is being stored in a different location relative to historical norms. Every few years this tool gets moved around and NCrunch then needs to have extra logic added to find it.

We'll take a look at how we can extend the search logic to account for this use case. Thanks for sharing such detailed information about the paths you have on this machine. How/when was this machine configured? Is it a fresh install of both Windows 10 and VS2017 at the latest versions of each?

To get NCrunch to find sn.exe on this machine, the simplest option is copy the file (and it's dependencies) to an expected location. Because your registry is pointing to 'C:\Program Files (x86)\Windows Kits\10\', you'll need to create a 'bin' directory under this path and copy sn.exe there. The other option is to change the registry value to point to your existing installation of sn.exe, but I don't recommend this as other software may have a dependency on this key.

We are seeing this on machines that we configure as VSTS Build Agents and I was able to repro locally on a clean machine (imaged last week) with Windows 10 and VS2017 installed (no previous VS installed). My other machine that had VS2015 on it previously works fine with the exact same project

Copying sn.exe would work for a local workaround for me, but I was hoping to find a workaround that we could apply to the image in the build agents as well as deploy to dev machines. Do you know of any online package or install/download that would install sn.exe into a place where NCrunch searches? Is this something fixable with the next version?

I have also tried installing older SDKs and that doesn't work out of the box either so I don't really know how this works for other people. While we do have a bunch of our own custom build rules, our VS and NCrunch installation is mostly the default.

Omeed

My previous experience here has been that sn.exe is usually deployed in the Windows SDK, and although the .exe paths have varied somewhat inside the install directory. I would have thought that installing a previous version of the Windows SDK would place the file in a well known location, though as you've mentioned that you've tried this already, I wonder if perhaps we're not understanding everything there is to know about this problem. It's possible there is something unique about your situation that is causing SDKs to be installed in a way that isn't the same for other users.

Is there a reason you're unable to simply make a copy of sn.exe on the machine before the image is created? I appreciate this is not a super clean and tidy solution, but it would get you up and running. We're building up a bit of a backlog of issues to address at the moment so it may be a couple of weeks before we can publish an NCrunch build with a fix for it.

Upon further investigation, I think you are right that something different is happening here. I created a new key to one that was previously indicated was searched (HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Microsoft SDKs\Windows\v8.0\), set the InstallationFolder to a known directory that has a bin folder with sn.exe in it, and still got the same error that it could not find sn.exe. Is there something else it is looking for here? I ran the console tool with verbose logging and didn't see anything that looked obviously wrong. I did notice that there were some loading of a DLL named VSIntegration2017.dll - does that mean that the NCrunch console tool runs based on the local VS install instead of actually being seperate, or is this not related? The reason I ask is that I know that VS2017 has extensive registry changes and are using a file-based virtual registry now, so wondering if that happens to be related here, perhaps it is not reading my actual system registry at all and thats why copying sn.exe didnt work?

The build below contains a fallback that will try to find sn.exe using normal install locations on the file system if the registry attempts don't provide it. I recommend giving this a try. We were unable to produce an image with registry paths configured in the way that you've described, even when using the latest version of both VS2017 and Windows 10. We suspect something may be wrong with your image.

http://downloads.ncrunch.net/NCrunch_Console_3.13.0.2.msi
http://downloads.ncrunch.net/NCrunch_Console_3.13.0.2.zip
http://downloads.ncrunch.net/NCrunch_GridNodeServer_3.13.0.2.msi
http://downloads.ncrunch.net/NCrunch_GridNodeServer_3.13.0.2.zip
http://downloads.ncrunch.net/NCrunch_LicenseServer_3.13.0.2.zip
http://downloads.ncrunch.net/NCrunch_VS2008_3.13.0.2.msi
http://downloads.ncrunch.net/NCrunch_VS2010_3.13.0.2.msi
http://downloads.ncrunch.net/NCrunch_VS2010_3.13.0.2.zip
http://downloads.ncrunch.net/NCrunch_VS2012_3.13.0.2.msi
http://downloads.ncrunch.net/NCrunch_VS2012_3.13.0.2.zip
http://downloads.ncrunch.net/NCrunch_VS2013_3.13.0.2.msi
http://downloads.ncrunch.net/NCrunch_VS2013_3.13.0.2.zip
http://downloads.ncrunch.net/NCrunch_VS2015_3.13.0.2.msi
http://downloads.ncrunch.net/NCrunch_VS2015_3.13.0.2.zip
http://downloads.ncrunch.net/NCrunch_VS2017_3.13.0.2.msi
http://downloads.ncrunch.net/NCrunch_VS2017_3.13.0.2.zip

Thanks, I will try it with the build and let you know how it goes.

In the meantime, any ideas why even setting the registry values didn't work as a workaround? On a clean Windows 10 machine with only VS2017 installed, are you guys getting different values than I am for the windows SDK paths?

Got the following error with the build:
System.IO.DirectoryNotFoundException: Could not find a part of the path 'C:\Program Files\Microsoft SDKs\Windows'.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileSystemEnumerableIterator`1.CommonInit()
at System.IO.Directory.GetDirectories(String path)
at nCrunch.Common.IO.DirectoryPath.GetDirectories(String wildcardSpec)
at nCrunch.Compiler.AssemblySigner.(String )
at nCrunch.Compiler.AssemblySigner.()
at nCrunch.Compiler.AssemblySigner.SignAssemblyWithKey(FilePath assemblyFilePath, FilePath keyFilePath)
at nCrunch.Compiler.RemoteBuildRunner..()
at nCrunch.Common.PerformanceTracking.PerfTracker.TrackActivity(String name, Action activity)
at nCrunch.Compiler.RemoteBuildRunner.(ComponentBuildParameters , FilePath , BuildOutput , DirectoryPath[], FilePath[] )
at nCrunch.Compiler.RemoteBuildRunner..()
at nCrunch.Common.PerformanceTracking.PerfTracker.TrackActivity(String name, Action activity)
at nCrunch.Compiler.RemoteBuildRunner.(ComponentBuildParameters )

For reference, there was no Microsoft SDKs folder in Program Files but there is in Program Files (x86)

omusavi wrote:Thanks, I will try it with the build and let you know how it goes.

In the meantime, any ideas why even setting the registry values didn't work as a workaround? On a clean Windows 10 machine with only VS2017 installed, are you guys getting different values than I am for the windows SDK paths?

Unfortunately it's hard for me to draw any conclusions here because the problem only seems to appear in your environment and we have no way to reproduce it. This also means that any code adjustments we make cannot be reliably tested (we're pitching blind). I'm sorry that the build didn't work for you. We'll try to make some adjustments to the fallback when we have a chance to publish a new build. The following registry extract was taken from a machine with several different versions of the Windows SDK installed. These registry values match with sn.exe install locations and work correctly with NCrunch:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows]
"CurrentVersion"="v6.0A"
"CurrentInstallFolder"="C:\\Program Files\\Microsoft SDKs\\Windows\\v6.0A\\"
"ProductVersion"="v6.0A"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.0A]
"InstallationFolder"="C:\\Program Files\\Microsoft SDKs\\Windows\\v6.0A\\"
"ProductVersion"="v6.0A"
"CurrentInstallFolder"="C:\\Program Files\\Microsoft SDKs\\Windows\\v6.0A\\"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.0A\VistaClientHeadersLibs]
"InstallationFolder"="C:\\Program Files\\Microsoft SDKs\\Windows\\v6.0A\\"
"ProductVersion"="6.0.6001.17011"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.0A\VistaClientSDKTools]
"InstallationFolder"="C:\\Program Files\\Microsoft SDKs\\Windows\\v6.0A\\"
"ProductVersion"="6.0.6001.17011"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.0A\VistaClientSDKTools\1033]
"SP"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.0A\VistaClientWin32Tools]
"InstallationFolder"="C:\\Program Files\\Microsoft SDKs\\Windows\\v6.0A\\"
"ProductVersion"="6.0.6001.17011"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.0A\VistaClientWin32Tools\1033]
"SP"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.0A\WinSDKIntellisenseRefAssys]
"InstallationFolder"="C:\\Program Files\\Microsoft SDKs\\Windows\\v6.0A\\"
"ProductVersion"="6.0.6001.17011"
"ComponentName"="Windows SDK Intellisense and Reference Assemblies"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.0A\WinSDKNetFxTools]
"InstallationFolder"="C:\\Program Files\\Microsoft SDKs\\Windows\\v6.0A\\"
"ProductVersion"="v6.0A"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.0A\WinSDKNetFxTools\1033]
"SP"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A]
"InstallationFolder"="C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0A\\"
"ProductVersion"="7.0.30319"
"ProductName"="Microsoft Windows SDK for Visual Studio 2010"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A\WinSDK-NetFx35Tools]
"ProductVersion"="7.0.30319"
"ComponentName"="Windows SDK .NET Framework 3.5 Multi-targeting Utilities"
"InstallationFolder"="C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0A\\Bin\\"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A\WinSDK-NetFx35Tools-x64]
"ProductVersion"="7.0.30319"
"ComponentName"="Windows SDK .NET Framework 3.5 Multi-targeting Utilities (x64)"
"InstallationFolder"="C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0A\\Bin\\x64\\"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A\WinSDK-NetFx35Tools-x86]
"ProductVersion"="7.0.30319"
"ComponentName"="Windows SDK .NET Framework 3.5 Multi-targeting Utilities"
"InstallationFolder"="C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0A\\Bin\\"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A\WinSDK-NetFx40Tools]
"ProductVersion"="7.0.30319"
"ComponentName"="Windows SDK Tools for .NET Framework 4.0"
"InstallationFolder"="C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0A\\Bin\\NETFX 4.0 Tools\\"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A\WinSDK-NetFx40Tools-x64]
"ProductVersion"="7.0.30319"
"ComponentName"="Windows SDK Tools for .NET Framework 4.0 (x64)"
"InstallationFolder"="C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0A\\Bin\\NETFX 4.0 Tools\\x64\\"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A\WinSDK-NetFx40Tools-x86]
"ProductVersion"="7.0.30319"
"ComponentName"="Windows SDK Tools for .NET Framework 4.0"
"InstallationFolder"="C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0A\\Bin\\NETFX 4.0 Tools\\"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A\WinSDK-SDKTools]
"InstallationFolder"="C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0A\\Bin\\"
"ProductVersion"="7.0.30319"
"ComponentName"="Windows Common Utilities"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A\WinSDK-Win32Tools]
"InstallationFolder"="C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0A\\Bin\\"
"ProductVersion"="7.0.30319"
"ComponentName"="Windows Utilities for Win32 Development"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A\WinSDK-WindowsHeadersLibs]
"InstallationFolder"="C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0A\\"
"ProductVersion"="7.0.30319"
"ComponentName"="Windows Headers and Libraries"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.0A\WinSDK-WinSDKIntellisenseRefAssys]
"InstallationFolder"="C:\\Program Files (x86)\\Reference Assemblies\\"
"ProductVersion"="7.0.30319"
"ComponentName"="Windows Intellisense and Reference Assemblies"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1A]
"InstallationFolder"="C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.1A\\"
"ProductVersion"="7.1.51106"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1A\XPSupport]
"InstallationFolder"="C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.1A\\"
"ProductVersion"="7.1.51106"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.0A]
"InstallationFolder"="C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v8.0A\\"
"ProductVersion"="8.0.50727"
"ProductName"="Microsoft .NET Framework 4.5 SDK"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.0A\WinSDK-NetFx35Tools]
"ProductVersion"="8.0.50727"
"ComponentName"="Windows SDK Multi-targeting Utilities for .NET Framework 3.5"
"InstallationFolder"="C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0A\\Bin\\"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.0A\WinSDK-NetFx35Tools-x64]
"ProductVersion"="8.0.50727"
"ComponentName"="Windows SDK Multi-targeting Utilities for .NET Framework 3.5 (x64)"
"InstallationFolder"="C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0A\\Bin\\x64\\"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.0A\WinSDK-NetFx35Tools-x86]
"ProductVersion"="8.0.50727"
"ComponentName"="Windows SDK Multi-targeting Utilities for .NET Framework 3.5"
"InstallationFolder"="C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0A\\Bin\\"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.1A]
"InstallationFolder"="C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v8.1A\\"
"ProductVersion"="8.1.51636"
"ProductName"="Microsoft .NET Framework 4.5.1 SDK"

Thanks for the info, I am going to investigate to see what is happening on our machines that is placing the SDKs in a different location and will let you know what I find!

Just a quick follow-up, we updated our VSTS agents to use 3.14 and this error is fixed, I am guessing through the path search. Thanks so much for taking a look and glad the fix worked!