[Updated] Problems with PSXE 2017 Update 4 and VS 2017 (missing rc.exe and digitally not signed drivers)

[mjfort]

Hi,

I am trying to install Update 4 with VS 2017. In short, I am facing the "rc.exe not found" error that was also present with VS 2015 but the instructions found on this forum don't seem to apply as I don't see any option to include "Common tools", and I did select "Desktop development with C++" when installing VS 2017.

More details:

This is a clean install of Windows 10 (1703), so no previous VS or PSXE versions are present.

When installing VS 2017 (Professional), I have selected only the "Desktop development with C++" Workload.

When installing PSXE 2017 Update 4, I received 3 warnings:

• System reboot may be required for extended GPU analysis
• Additional requirements for using Intel C++ compiler to offload application computation to Intel Graphics Technology
• Missing Visual Studio C++ 2012, with a link to the Redistributables

I downloaded the redistributables from the link provided in the setup (it is Visual Studio C++ 2012 redistributable update 4), downloaded and installed the x86 and x64 redistributables, re-launched the PSXE setup. The 3rd warning was gone, the first two warnings were still there but I assumed there were not important.

I then installed PSXE 2017 Update 4 (Professional) leaving all options to default.

During the setup, 2 "Program Compatibility Assistant" messages come up. Both say that Windows blocked the installation of a digitally unsigned driver. One message is about "vtss.sys" and the other one is about "Sampling Enabling Product". But the installer says it completes successfully.

If I create a new console application with the wizard, trying to build it results in an "rc.exe not found" error. Other examples fail as well.

Would anyone have any pointers?

Thanks,

Mat

[mjfort]

Update:

Apparently the "digitally not signed" drivers are related to VTune, so I re-imaged the computer, reinstalled VS2017 Professional (with only the "Desktop development with C++" Workload selected). The installed version is 15.2. I tried a simple C++ console program, and was able to build it. I also installed the Visual Studio C++ 2012 redistributable (x86) and rebooted, just in case.

I reinstalled PSXE 2017 Update 4 (Professional). In the PSXE setup I only selected the compiler, none of the optimization tools nor the Intel MKL. An hour or so later, I am still getting the "rc.exe not found" error with a simple console program created from the wizard.

Other threads seem to indicate that this procedure should have worked. A possible difference is that this is a fresh install of Windows 10 Creators update (1703). No other software is installed.

I can confirm that rc.exe is in fact present in C:\Program Files(x86)\Windows Kits\10\bin\10.0.15063.0\x86 (and other subfolders x64 and arm64).

Please help!

[Kevin_D_Intel]

I'm sorry you are experiencing installation/integration problems.

Under my VS2017 installation w/PSXE 2017 Update 4, under VS2017 the rc.exe appears to resolve based on $(WindowsSdkDir)bin\x86 appearing under Tools > Options > Intel Compilers and Tools > Compilers > Executables.

Is this WindowsSdkDir path setting present in that tools setting under VS2017 on your system?

Can you also confirm the setting of the system env-varialbe %WindowsSdkDir% ?   (It should be similar to what you note, like: WindowsSdkDir=C:\Program Files (x86)\Windows Kits\10\)

I don't know whether our installation logs captured anything that may help with this issue, but if you can provide those then we will inspect them to see. To locate those, please look in your TEMP directory (in a file explorer window type %TEMP% in the address bar) for a folder with a name starting with pset_ and ending with your username. Inside there will be folders from recent install attempts - zip up the latest one and send it to us. For privacy you can attach that to a private reply (use the Send Author a Message link) to me if you wish.

[mjfort]

Thank you for your answer.

I do have the $(WindowsSdkDir)bin\x86 entry Under Tools > Options > Intel Compilers and Tools > Visual Fortran > Compilers > Executables

I do not however see a %WindowsSdkDir% environment variable (I checked by opening a command prompt and typing SET).

Note that on another machine with a VS2015 / PSXE2017 setup that works, I see the same thing (i.e. I have the entry in VS>Tools>Options etc. but I do not have the environment variable).

I will send you the logs directly.

Mat

[Kevin_D_Intel]

Hi Mat - you would see this set under an Intel compiler initialized Command-prompt (i.e. opened via a shortcut like "Compiler 17.0 Update 4 for Intel 64 Visual Studio 2017 environment") from the Intel Parallel Studio XE 2017 program group.

Thank in advance for the logs.

(Internal tracking id: INST-4176)

[mjfort]

Thanks, I didn't use the proper command prompt. Here is what I found using the properly initialized command prompt:

On the machine with the VS2017 / PSXE2017 Update 4 setup that does not work:

rc.exe is in fact in C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x86
(Note that there is also a C:\Program Files (x86)\Windows Kits\10\bin\x86\ folder (without the 10.0.15063.0) but that one does not include rc.exe)

Environment variables (excerpt):

windir=C:\Windows
WindowsLibPath=C:\Program Files (x86)\Windows Kits\10\UnionMetadata\10.0.15063.0\;C:\Program Files (x86)\Windows Kits\10\References\10.0.15063.0\
WindowsSdkBinPath=C:\Program Files (x86)\Windows Kits\10\bin\
WindowsSdkDir=C:\Program Files (x86)\Windows Kits\10\
WindowsSDKLibVersion=10.0.15063.0\
WindowsSdkVerBinPath=C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\
WindowsSDKVersion=10.0.15063.0\

On the machine with the VS2015 / PSXE2017 Update 2 setup that works:

rc.exe is in fact in C:\Program Files (x86)\Windows Kits\8.1\bin\x86

Environment variables (excerpt):

windir=C:\WINDOWS
WindowsLibPath=C:\Program Files (x86)\Windows Kits\8.1\References\CommonConfiguration\Neutral
WindowsSdkDir=C:\Program Files (x86)\Windows Kits\8.1\
WindowsSDKLibVersion=winv6.3\
WindowsSDKVersion=\
WindowsSDK_ExecutablePath_x64=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\x64\
WindowsSDK_ExecutablePath_x86=C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\

Thanks!

[Kevin_D_Intel]

Ok. The disconnect that leads to the error then is as you have noted that the x86 folder does not contain an rc.exe. I don't know a lot of details about the MS SDK but I would expect rc.exe to be present in the x86 folder, but, I do not have a system with your version of the Windows SDK installed to verify that.

You might consider trying a Repair on this SDK. Control Panel > Add/Remove programs, select Windows Software Development Kit, then right-click and select Change. You could choose to do a Repair or perhaps first click Change and ensure the Windows Software Development Kit box is checked. If not then check it to add it (I expect it is checked). If checked, then backup and try the Repair and then inspect that same x86 directory again for rc.exe.

[mjfort]

Well, the box was checked and the repair did not change anything.

Since I had the same x86, x64 and arm64 folders in two locations, I just copied all the files in C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\ to C:\Program Files (x86)\Windows Kits\10\bin\

So now I have a copy of rc.exe in C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x86 and another one in C:\Program Files (x86)\Windows Kits\10\bin\x86 (the latter is the one expected by IVF I assume).

And it works!

I am not sure whether my Visual Studio 2017 installation caused the problem, I will re-download (thanks MS for not offering an iso...) and try again. But in the meantime it seems we have a workaround.

Thank you for your help.

The question of "digitally not signed drivers" with VTune remains, though. Is that the kind of error that can be safely ignored?

[rorban]

mjfort wrote:

The question of "digitally not signed drivers" with VTune remains, though. Is that the kind of error that can be safely ignored?

Starting with new installations of Windows 10, version 1607, Windows will not load any new kernel mode drivers that are not signed by the Microsoft Dev Portal. This can be a problem, because unsigned drivers will not load. The new procedure is very complex and time-consuming for driver developers, particularly from small shops.

https://msdn.microsoft.com/en-us/windows/hardware/drivers/install/kernel-mode-code-signing-policy--windows-vista-and-later-

A hack that can tide you over until properly signed drivers are available is a registry tweak that makes Windows appear to be an upgrade rather than a clean install. This should allow self-certified drivers to load.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CI\Policy]

"UpgradedSystem"=dword:00000001

https://forums.mydigitallife.info/threads/69970-Windows-10-Anniversary-Update-Digital-Signature-Question/page2?p=1272392&viewfull=1#post1272392

[mjfort]

Thank you, that is very useful information and it explains why I am having more problems with a fresh install than with an older machine that has been upgraded over time.

One thing that is not clear to me: is this registry tweak just needed during the installation or is it required each time I will run the application using the unsigned drivers? And if the tweak needs to be permanent, are there any expected side-effects?

Thanks again.

[Kevin_D_Intel]

I submitted the VTune digital signing issue to our developers for further investigation. If the drivers were blocked from being installed as the message indicated then I would expect VTune not to function as expected. The drivers should be signed accordingly for public release.

(Internal tracking id: INST-4176)

[mjfort]

I re-downloaded both Visual Studio 2017 Community and Professional versions and re-installed successively on a fresh Windows 10 Creators Update (1703) installation. In both cases rc.exe gets installed in C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x86 (and similar x64 etc. subfolders) and NOT in C:\Program Files (x86)\Windows Kits\10\bin\x86, where the Intel Visual Fortran compiler expects to find it. so apparently that was not an accident related to a failed VS2017 download or installation. The Visual Studio 2017 version (about box) is 15.2 (26430.6).

I confirm that manually copying the content of some folders fixes the problem :

• C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x86 to C:\Program Files (x86)\Windows Kits\10\bin\x86
• C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64 to C:\Program Files (x86)\Windows Kits\10\bin\x64
• Etc. if you use the ARM and ARM64 platforms I assume

I have not done further testing with VTune, I will wait for updated drivers.

[Kevin_D_Intel]

Thank you for the update. I notified our integration developers about your latest findings so they can investigate and determine the appropriate action.

(Internal tracking id: CMPLRS-43201)

[Kevin_D_Intel]

Our Developers confirmed the missing rc.exe is our defect with not adjusting paths accordingly for the change in the Windows 10 SDK (10.0.15063). You can work around this as you did to copy the contents, use a previous version of the SDK, or add the specific paths under the VS settings noted in post #3. This defect will be fixed in an upcoming PSXE 2017 update and the next major release scheduled for later this year.

There no additional guidance/update on the VTune digital signing issue yet.

[Kevin_D_Intel]

Development reported the VTune driver issue you experienced relates to inadequate signed drivers for a Secure Boot Windows 10 system and that the issue is resolved in updated signed drivers now available in the Intel® VTune™ Amplifier XE for Windows* 2017 Update 3 stand-alone package available from the Intel Registration Center.

At your convenience, you can download/install this updated package. Prior to installation, please uninstall any existing Intel® VTune™ Amplifier XE for Windows* 2017 and then install this Update 3 package. Please let us know if you experience any additional issues.

[NotThatItMatters]

I am having similar problems on a machine which is newly minted with Windows 10 Pro 1703 (15063.332) with VS 2017 (15.2) and the latest update 4 Fortran compile.  Thank you mjfort for the leg work you have done.  I have one note to make on your initial post.  You mention 3 warnings on the initial install.  I am only seeing the third of these, which for me is

Microsoft Visual C++ 2012 Redistributable* (x86) is not installed.
	Installation can continue; however, some components of this installation may not be fully functional without it. 
	Install the redistributable from here (https://www.microsoft.com/en-us/download/details.aspx?id=30679).

The last step is leading me nowhere.  The web-site has been removed and I cannot find its equivalent.  Did you specifically get your VS C++ 2012 redistributables from this web-site mjfort?  If not, where did you find them?

[Kevin_D_Intel]

It appears the link changed recently and it is unclear it this was intentional. The link is also include here. We are looking into whether there is a replacement URL. Guidance I received is the underlying requirement for this VS 2012 redist relates to our debugger component but I do not yet have details if a newer redist can be substituted. I will post again when I have updated information.

[NotThatItMatters]

The link to "Microsoft Visual C++ Redistributable Packages for Visual Studio 2012 Update 4" referenced in https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads is also inactive.

[Kevin_D_Intel]

Yes, I understand, sorry that I wasn't clear. I was just noting that our link did not appear to be incorrect. The same broken link is also found on the MS page, The latest supported Visual C++ downloads, here.

[NotThatItMatters]

Thank you, Kevin.  From Mat's comments, I am assuming he found this reference.  Perhaps he can answer this.

[mjfort]

When I installed for the first time, the download link was still working, and I kept a local copy of the redistributable package so I did not notice whether the link was down during my successive attempts. I assume re-posting the file would breach some licensing agreement, but I will contact you off list to see if I can help.