I would like to perform the following:
Build a instrumented PGO exe using MSVS 2015 IDE
Copy the generated exe along with its .pgd file to several other machines
Run the exe from the command line on those machines. Note these machines do not have the MSVS compiler on them.
Currently, I can only run the exe on the machine that I compiled it on and only through the IDE option Build->Profile Guided Optimization->Run Instrumented/Optimized Application. If I try to run it through the command line (on any of the machines), I get the following error:
The application was unable to start correctly (0xc00007b)
Could someone please let me know if what I am trying to do is possible and the steps to make it work if it is? Thanks.
To get the PGO instrumented version to run on the remote machines, I had to install the MSVS 2015 redistributable package as well as use the correct pgort140.dll. On my local machine I had the following versions:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\pgort140.dll (49 KB)
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\pgort140.dll (55 KB)
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\arm\pgort140.dll (49 KB)
The one from \bin was causing the error to occur. I had to use the dll from \bin\amd64 to get my exe to run, so I copied this version to my remote machines.
Related
I'm going to use the HelixToolkit.SharpDX with VS2017 in my Windows 10 workstation, when I attempt to build the solution, it will prompt the Assertion Failed error with "No fxc.exe found".
I have checked the installation option, Windows SDK has been included, nand I have downloaded and install again, and I can see the fxc.exe in "C:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\x64" & "C:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\x86" folders, so it should be available for any windows version, but unfortunately, the same error reported.
However, I have also installed VS2017 in another Windows 7 machine, it works fine, and it has the fxc.exe in the same folder as my Windows 10 workstation, but it can be located by VS2017.
Is there any setting in VS2017 to locate the fxc.exe?
Or how can I fix this issue?
Copy fxc.exe in Bin\10.0.xxx\x86 to Bin\x86 to fix this issue. Because the HLSL compile tool hard coded the path.
One can find solution on helix toolkit github page.
Visual Studio 2017. Windows 10 SDK.
Missing fxc.exe issue with newest Windows 10 SDK:
Copy fxc.exe in C:\Program Files (x86)\Windows
Kits\10\Bin\10.0.xxx\x86 to C:\Program Files (x86)\Windows
Kits\10\bin\x86 to fix this issue. Because the HLSL compile tool hard
coded the path.
This seems to have been fixed in Visual Studio 2019 16.0.2, as of writing. Just have to make sure $(WindowsSDK_ExecutablePath) is pointing to the correct SDK directory and the build version that matches with the Targeted Platform in the Project Properties page.
https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/a3032567-d8e7-4b01-81b7-0612047a6299/why-do-we-need-to-copypaste-fxcexe-from-bin100xxxxx0x86-to-binx86-directory-in-the?forum=windowssdk
Second post answered:
The executables that the C++ build process uses from the Windows SDK directory are MIDL.exe, MT.exe and RC.exe. If you digitally sign your executables then you will find signtool.exe here too. So I am kind of surprised that it finds some critical build tools correctly but others it fails to find.
My suggestion would be:
1) Verify that you are having this problem with your project in Visual Studio 2019 16.0.2 (the latest version at the time of writing) or Visual Studio 2019 Preview (16.1 Preview 1 at the time of writing). This is to check that if this has been found to be a bug, then it could have been fixed.
2) Create a completely new project. Without touching the project's executable path, try to create a sample that shows this behaviour. It doesn't need to be a full sample, just complete enough to show that Visual Studio fails to find fxc.exe.
3) If doing all of this shows that Visual Studio fails to find fxc.exe, then through Visual Studio 2019, report it as a bug.
But I will mention that a naïve test on my end shows that Visual Studio 2019 can compile HLSL shaders without any issues using the 18362, 17763 and 17134 SDKs. These were tested because these are the versions that I have installed.
I have a small vcxproj. It is 64-bit only, uses v141 platform toolset, and was using Windows SDK 8.1, I have also tried using Windows SDK 10.0.16299.0 to see if that made any difference, but it didn't.
Previously, the project was being compiled using 32-bit MSBuild, and working fine. Recently I tried compiling using 64-bit MSBuild. The command line call to the C++ compiler is identical (including all include directories), apart from the compiler it calls is
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.11.25503\bin\HostX64\x64\CL.exe
instead of
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.11.25503\bin\HostX86\x64\CL.exe"
(changed HostX86 -> Hostx64). This results in the following error message:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.11.25503\include\crtdefs.h(10, 0): error C1083: Cannot open include file: 'corecrt.h': No such file or directory
I am at a loss as to what the problem could be; it's using the same include paths, and the same Windows SDK. I don't see why the bitness of the compiler should affect whether it can find a header file when the target architecture hasn't changed!
The machine this is running on has Visual Studio 2017 Enterprise, Windows SDK 8.1 and Windows SDK 10.0.16299.0 installed.
Slightly wider context: this came up as part of updating our build dependencies. We use Invoke-Build to run the build, and as of 3.6.3 it started detecting 64-bit MSBuild installations, and using them by default. I could, of course, simply pin to 32-bit MSBuild, but I would like to get to the bottom of why the bitness of the build tools makes a difference in this situation.
I have the big Visual Studio 2015 C++ project and can't compile it on the computer with 12GB RAM (fatal error C1060: compiler is out of heap space).
Command line:
"C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" Project.sln /t:Rebuild /p:Configuration=Release;Platform=x64
I've read this https://msdn.microsoft.com/en-us/library/x4d2c09s.aspx?f=255&MSPPError=-2147217396
and decided to use x64 compiler, but I can't figure out how it can be done using MsBuild.exe (or with another way but without generate make file - it is hard to maintain it because the project frequently changed).
I was tried to call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\vcvars64.bat" before MsBuild.exe, but it doesn't help.
Found solution here: https://msdn.microsoft.com/en-us/library/ee662426.aspx?f=255&MSPPError=-2147217396
Where is the property PreferredToolArchitecture which by default equals x86.
Set it to x64 to use the 64-bit compiler and tools to build your application.
msbuild myProject.vcxproj /p:PreferredToolArchitecture=x64
I am trying to run the code analysis of Visual Studio 2015 on my x64 VC++ project. However I get the following error:
Error C1250 Unable to load plug-in 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\\bin\localespc.dll'
I am activating the x64 toolset of Visual Studio by running the batch script "vcvarsall.bat amd64" before I start the IDE. Visual Studio is run with the "/useenv" option afterwards.
When I check the VC++ environment variables, I can see that the following path is contained in the PATH variable:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\amd64
How can I tell Visual Studio to use the code analyzer (localespc.dll) from there and not the x86 version which it apparently tries to use (according to the error message).
Thanks a lot for your help!
I was having the same issue with my 64-bit C++ projects. I discovered simply renaming/removing localespc.dll from VC\bin allowed the Code Analysis builds to succeed and still report analysis warnings. It seems if VS doesn't find this dll in the VC\bin directory then it won't add the compiler switch for /analyze:plugin but otherwise passes all the other switches required by the Code Analysis.
Set the following property in your project file: <PreferredToolArchitecture>x64</PreferredToolArchitecture>
This tells Visual Studio to use the 64-bit version of various tools, including code analysis. I found How to make Visual Studio use the native amd64 toolchain helpful on the topic.
Note that renaming localespc.dll no longer solves the problem with Visual Studio 2017. It seems that setting PreferredToolArchitecture is Microsoft's intended way to do this.
I have a Qt project I'm trying to automate. On Windows I build for both 32-bit and 64-bit platforms. I am using Visual Studio 2013. I have the following Qt Kits installed: Desktop Qt 5.5.1 MSVC2013 32bit, and Desktop Qt 5.5.1 MSVC2013 64bit. All four versions (32-bit debug and release, and 64-bit debug and release) can be built and run without any trouble from the IDE. Unfortunately, building from the command line fails with this error:
fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
My command-line system, intended for eventual use in a batch file, and run in my project directory, is:
pushd Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin
call vcvars32.bat
popd
md build64
cd build64
G:\Qt\5.5\msvc2013_64\bin\qmake.exe -spec win32-msvc2013 -o Makefile ..\Maps.pro
G:\Qt\Tools\QtCreator\bin\jom.exe -f Makefile.Release
I use this command in a command window (after setting up the path using vcvars32 so that the Visual Studio tools like nmake, rc and link can be found) and get the error. Note that the command-line method works perfectly for my 32-bit build.
The qmake command line I use is copied from the one recorded in a comment in the Makefile created by the IDE, which claims it is the command used to create that makefile. I know that the "-spec win32-msvc2013" option looks strange, but it works when the IDE uses it.
The jom command line I use is the one used by the IDE, as logged by the Compile Output window.
The only thing I can think of is that Qt sets up some 'magic' environmental variables which I don't know about.
[Yes, I have googled very extensively and looked at other questions and answers here, and can't find anything that fits this case.]
This code
pushd Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin
vcvars32.bat
popd
sets up environment for building for 32-bit architecture. Run vcvars32.bat from different directory (I think it should have amd64 in its name, don't have Windows computer at the moment so can't say the exact directory name, but you'll figure out).
Or do
pushd "<DRIVE>:\Program Files (x86)\Microsoft Visual Studio <Version>\Common7\Tools"
vsvars32 x64
popd
Update for VS2017:
For 64-bit architecture use this command:
"<DRIVE>:\Program Files (x86)\Microsoft Visual Studio\2017\<Version>\VC\Auxiliary\Build\vcvars64.bat"
and for 32 bits:
"<DRIVE>:\Program Files (x86)\Microsoft Visual Studio\2017\<Version>\VC\Auxiliary\Build\vcvars32.bat"