Related
TL;DR: Where do I find the MS source files that are referenced as d:\th\minkernel\crts\ucrt\... when debugging in Visual Studio 2015.
I'm trying to debug into a CRT call to see what MS is actually doing, and unfortunately it seems the ucrt source files are not available with an installation of VS2015. At least I cannot find these files in C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\crt\src at all.
Is the (mostly) full source set of the MS CRT still available somewhere as it used to be at least up to VS2010, or are some parts of the CRT now fully closed source?
Answered on MSDN by RLWA32:
The ucrt source can be found under the Windows Kits folder. For example, in a 32 bit VM with VS2015 installed the path to the ucrt source is -
C:\Program Files\Windows Kits\10\Source\10.0.10240.0\ucrt.
You can find the path by examining the VC++ directories property for any C+ project -
$(VC_SourcePath)
This folder is in fact on Program Files (x86) on my machine, but it's there.
I missed it, because there is another folder C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\... and this one doesn't contain any sources.
I use Visual Studio 2012 and this is the only version of Visual Studio I have installed. I need to build certain C++ projects with the v90 platform toolset (of Visual Studio 2008), but I can't install Visual Studio 2008.
I understand it is possible to use the v90 platform toolset by installing Windows SDK 7.0. How exactly is it done? If I simply use the web installer of 7.0 SP1, I still don't see v90 as one of the possible platform toolsets.
It is possible, but apparently requires some maneuvering and will not support building MFC applications. The following assumes that VS2012 update 4 is installed, but neither VS2010 nor VS2008 are installed.
Download the x86 DVD of SDK 7.0 SP1 (GRMSDK_EN_DVD.iso). Mount the ISO or extract its contents, and manually install the MSI files from the following folders under the Setup folder:
WinSDK (this may fail, it's ok)
WinSDKBuild
WinSDKInterop
WinSDKTools
WinSDKWin32Tools
vc_stdx86
vc_stdamd64
winsdk_intellidocs
WinSDKIntellisenceRefAssys
WinSDKNetFxTools
Download the x86 DVD of SDK 7.1 (GRMSDK_EN_DVD.iso). Mount the ISO or extract its contents, and manually install the MSI files from the same folders listed above (except winsdk_intellidocs, which doesn't exist).
Go to C:\Program Files (x86)\Microsoft Visual Studio 9.0. Copy the following files from Common7\IDE to VC\bin:
msobj80.dll
mspdb80.dll
mspdbcore.dll
mspdbsrv.exe
Now you should be able to choose the v90 platform toolset in Visual Studio 2012 and build with it.
Explanations (and sources):
Individual MSI installation is based on the second workaround from this connect report.
The requirement for both 7.0 and 7.1 is based on this question (both VS2010 and VS2008 are required to use v90 in VS2012!). SDK 7.1 is not needed if you have VS2010.
DLL/EXE copying requirement is based on yet another question. If you do not copy them, you will see error MSB6006: "CL.exe" exited with code -1073741515.
In addition to this answer I want to add that
You can install SDK 7.0 simply by running setup, there is no problem with it.
You can install SDK 7.1 by running setup, if you remove Microsoft Visual C++ 2010 Redistributables first and fix following registry values:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Client]
"Version"="4.0.30319"
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full]
"Version"="4.0.30319"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v4\Client]
"Version"="4.0.30319"
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\NET Framework Setup\NDP\v4\Full]
"Version"="4.0.30319"
You can (and probably should) restore these values to whatever they originally were after installation is complete.
Do not forget to install KB2519277 after this, it updates compilers in SDK 7.1 to SP1.
You don't need to copy any dll. MSBuild uses
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\Setup\VC#ProductDir
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\9.0\Setup\VC#ProductDir
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\Setup\VS#ProductDir
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\9.0\Setup\VS#ProductDir
to set up paths. It's probably wise to fix them to point to "C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\VC\\" and "C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\" as it might be useful elsewhere in build process.
Same goes for version 10.0 if you plan to use Windows7.1SDK toolset.
Use WindowsSdkVer.exe to set current SDK to 7.1 to defeat cryptic error in Microsoft.Cpp.x64.Targets(63,5) about missing unnamed required file. If the tool gives you error, then set these values manually:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows#CurrentInstallFolder
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows#CurrentInstallFolder
to point to newly installed SDK. The tool needs some registry keys from Visual Studio installation to work properly, but there are many and I'm not sure which are important.
Reboot. None of the above asks you to, but without reboot I got errors when trying to build a project.
As an aside, SDK7.1 adds v100 toolset, but it won't work, saying something about Could not find WindowsSDKDir variable from the registry. This is because v100 actually requires SDK7.0A which comes with Visual Studio 2010 and is not available separately. Windows7.1SDK toolset is the one which utilises VC2010 compilers if you need them.
Microsoft.Cpp.Win32.*.props files have a lot of relevant stuff if something fails in build system.
One addition/update for VS2013 to Yodans answer:
My working setup:
VS2013 has to use VS2010 libs
Using WinSDK 7.1 (Yodans 2.) build tools (v100) in VS2013
clean install, uninstalling everything mentioned in the sdk release notes (can be downloaded at http://www.microsoft.com/en-us/download/details.aspx?id=8279 under category Details)
Microsoft Windows SDK for Windows 7 (7.1) (the Windows SDK core-component files)
Application Verifier
Debugging Tools for Windows
Windows Performance Toolkit
Microsoft Help Viewer 1.0
Microsoft Visual C++ 2010 Redistributable
Microsoft Visual C++ 2010 Standard Edition
Additionally removed all .NET and VC++ related MS Software (not tested if necessary)
choosing Windows7.1SDK as Platform Toolset in VS2013
error MSB6006: "CL.exe" exited with code -1073741515
cl.exe uses msobj100.dll, mspdb100.dll, mspdbcore.dll and mspdbsrv.exe
Added to PATH C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE
Build works and binary is usable ( So now its tested Yodan ;-) )
My mistake:
copied files in 7. above to C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin (Yodans 3.), believing this dir is in PATH, but it was not!
So better do as sugested by Yodan and tested by myself in 8. above
p.s. same answer is solving this problem:
Visual Studio 2013: CL.exe exited with code -1073741515
I've searched online and couldn't find anything that resembled to my issue.
I created an empty C++ project and added a main.cpp with a return and I can't get it to build. Here is the message I receive :
1>------ Build started: Project: Project1, Configuration: Debug Win32 ------
1>LINK : fatal error LNK1158: cannot run 'rc.exe'
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Is there somewhere within VS2012 where I can specify where to find this executable? I have installed the Windows 7 SDK and I have this executable at:
C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin
I come from Code::Blocks and using mingw-gcc without any trouble, but lately I've been needing VS for managed implementations so I hope someone has an idea.
Found this on Google... I would assume that in your case you would copy rc.exe and rcdll.dll to visual studio 2012\vc\bin or wherever you have it installed:
Part 2: FIX LINK : fatal error LNK1158: cannot run ‘rc.exe’
Add this to your PATH environment variables:
C:\Program Files (x86)\Windows Kits\8.0\bin\x86
Copy these files:
rc.exe
rcdll.dll
From
C:\Program Files (x86)\Windows Kits\8.0\bin\x86
To
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin
Or I also found this:
Microsoft left a few things out of their MSVT package. Since no one knows whether they were left out by mistake or for license reasons, no one with MSVC is too interested in giving them out. A few Google searches turn up some tricky sources. Fortunately, Microsoft has finally wised up and solved this problem and many more.
http://msdn.microsoft.com/vstudio/express/support/faq/default.aspx#pricing
http://msdn.microsoft.com/vstudio/express/support/install/
A good amount of MSVT missing files are there but the missing SDK files aren't.
and this:
I had the same problem which I solved by doing this:
Installing the Microsoft .Net Framework 2.0
Adding the path of the .NET Framework files (for me "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727") to Global compiler settings > Programs > Additional Paths within Code::Blocks.
Now I can build and link resource files without errors.
We hit this issue with our CMake/Visual Studio 2015 builds after also installing VS2017 on the machine. The correct solution in our case is to specify the Window Kit version (8.1) to the Visual Studio Command Prompt - otherwise you get the Windows 10 Kit by default which doesn't include rc.exe in the bin directory.
e.g. Start Menu->Visual Studio 2015->VS2015 x64 Native Tools Command Prompt
%comspec% /k "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" amd64 8.1
Note the 8.1 option on the end
From what I have found, if you have a windows 7 OS, doing the following steps will fix the problem:
1) go to C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin
2) then copy RC.exe and RcDll from this file
3) go to C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin and paste the two files you have copied into it.
I had the same problem, and the above posted solution did not work. My solution was derived from it, and it worked for me, if the ones above do not work you can give this one a try.
This rc.exe error can occur if the Visual C++ compiler and the Windows 10 SDK versions don't correspond to the same Visual Studio year. In general, the solution is to make sure you have on your system, and are using in the compilation, VC++ and Windows SDK for the visual studio year you are using.
For instance, if you have Visual Studio 2017 or 2019, and you installed Build Tools 2015 without selecting to install its own 2015 Windows SDK (default installation does not install it!), and are trying to use it to compile, you may run into this problem.
In my case, I already had Visual Studio 2017. When I tried to use Build Tools 2015 to compile a python library (or probably any program), this same 'rc.exe' error occurred. I read that the VS2015 14.0 C++ compiler can glitch if it tries to use the Windows 10 SDK from Visual Studio 2017.
I uninstalled Build Tools 2015, and reinstalled it, this time as a custom installation, selecting to install both visual C++ and Windows 10 SDK components. This fixed the issue.
UPDATE: I just looked at Build Tools 2015 again, and apparently there is no custom installation option anymore. If so, installing Visual Studio 2015 with C++ and Windows SDK components should also work. Edit: commenter has found the customizable build tools installer
In my case, I had a mix and match error between projects created in VS2015 and VS2017. In my .vcxproj file, there's this section called PropertyGroup Label="Globals">. I had a section for TargetPlatformVersion=10.0.15063.0. When I removed the TargetPlatformVersion, that solved the problem.
Sorry I can't copy and paste the block here, but stackoverflows coding format did not allow that.
In my case, VS 2019 on Windows 10 x64,
I followed mostly what it was said in the answers but pasted rc.exe and rcdll.dll from C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x86 to C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin, which is where link.exe is.
I'm on Windows 7 x64 and Visual Studio 2017. I get this error trying to compile a cython script.
That's how I solved:
I copied and pasted rc.exe and rcdll.dll from:
C:\Program Files (x86)\Windows Kits\8.1\bin\x86
to
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64
Here is my almost similar case:
I have VC2010 working project under Win7 32bit. I make clean install of VC2013 under Win8.1 64bit
After successful converting of my project from VC2010 to VC2013, during 1st compilation the following error rise:
Finished generating code
LINK : fatal error LNK1158: cannot run 'rc.exe'
Solution 1:
Delete whole line “<ExecutablePath Condition=”...”>...</ExecutablePath>” in element “<PropertyGroup>” in NameOfYourSolution.vcxproj file in notepad before to run VC2013
Solution 2:
Copy only two files: rc.exe and rcdll.dll from “c:\Program Files (x86)\Windows Kits\8.1\bin\x86\” to “c:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\” and compilation will be successful!!
Note:
a)It is not need to touch any PATH or other Windows or VC environment variables.
b)“Platform Toolset” (Project Property Pages –> Configuration Properties –> General) will be automatic set to “Visual Studio 2013 (v120)” (not change it to “Visual Studio 2010” to be able to continue to develop your project under VC2013 concepts)
In my case the error was due to a bad setting in a vcxproj. The vcxproj was from a third party, so I'm not sure how it got in that state.
Specifically, for one of the platform/profile combos, the platform folder was missing from the Windows SDK bin folder:
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
<ExecutablePath>$(VCInstallDir)bin\x86_amd64;$(VCInstallDir)bin;$(WindowsSdkDir)bin\NETFX 4.0 Tools;$(WindowsSdkDir)bin\x86;
is correct, where
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
<ExecutablePath>$(VCInstallDir)bin\x86_amd64;$(VCInstallDir)bin;$(WindowsSdkDir)bin\NETFX 4.0 Tools;$(WindowsSdkDir)bin;
was incorrect. Might need to scroll to the end of the code boxes to see the difference.
Note also, that for some strange reason $(WindowsSdkDir)bin\x64; did NOT work for me. Tried to figure out why, when rc.exe definitely exists in that folder, but I gave up.
In my opinion, the solutions from previous posters that involve copying rc.exe all over the place are wrong, because your project will not work on anyone else's machine. If you fix up the paths in the project correctly, it should work on any machine with a correct installation of the Windows SDK.
I'm on Windows 10 x64 and Visual Studio 2017. I copied and pasted rc.exe and rcdll.dll from:
C:\Program Files (x86)\Windows Kits\8.1\bin\x86
to
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64
it's works with: ( qt creator 5.7.1)
This might be a little outdated. But if copying the rc.exe and exdll.dll did not work, there is a chance that the windows sdk is not installed properly even if the windows sdk folder exists. You can update the sdk for win 8 in the following page:
http://msdn.microsoft.com/en-US/windows/hardware/hh852363
After re-installing the sdk, the problem would get solved. Also make sure that platform toolset is set properly.
I've encountered this issue recently. I have both VS 2015 and VS 2017 installed, Windows kits 8.1 and 10 installed.
Command prompt from VS 2017 works as expected, rc.exe is visible. In VS 2015 this is not true.
Actually, vcvarsall.bat script from VS 2015 does add a path to Windows 10 kit to PATH variable, but it adds a slightly wrong path. It adds path to
"C:\Program Files (x86)\Windows Kits\10\bin\x86"
while the actual path is
"C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x86"
It seems that updating Windows 10 kit (or installing VS 2017) led to this issue.
So the solution is simple: just create symbolic links in "C:\Program Files (x86)\Windows Kits\10\bin" folder pointing to the corresponding folders in the underlying folder, e.g. a symbolic link "x86" for folder "10.0.17763.0\x86", "x64" for "10.0.17763.0\x64" etc.
I'm on Windows 10 Pro x64, VS 19..
When trying to install mod_wsgi for apache in cmd.
C:\>python -m pip install mod_wsgi
This is the error I was getting from my command prompt.
LINK : fatal error LNK1158: cannot run 'rc.exe'
error: command 'C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\VC\\BIN\\x86_amd64\\link.exe' failed with exit status 1158
I had to copy rc.exe & rcdll.dll from
C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x86
and add it to
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64
result from cmd
C:\>python -m pip install mod_wsgi
Collecting mod_wsgi
Using cached mod_wsgi-4.7.1.tar.gz (498 kB)
Installing collected packages: mod-wsgi
Running setup.py install for mod-wsgi ... done
Successfully installed mod-wsgi-4.7.1
Hope this helps someone.
I had the same problem on VS 2013 and was able to fix it by changing the Platform Toolset.
You can find it in project settings, general.
E.g. switching Platform Toolset to VS 2010 will cause VS to use the Windows\v7.0A SDK.
You can check which SDK path is used by adding this to your prebuild event:
echo using SDK $(WindowsSdkDir)
I'm using Windows 7 with VS 2013 (Update 3) and Intel Parallel Studio XE Composer Edition for Fortran Windows (Update 5). Out of the box I had the same issue.
Once I fixed the missing rc.exe problem I had another issue. The linker was missing kernel32.lib.
I corrected both issues by updating the Intel Composer Options (TOOLS->Options...->Intel Composer XE->Visual Fortran->Compilers).
For the Win32 tab I added:
Executables: C:\Program Files (x86)\Windows Kits\8.0\bin\x86; (just before $(PATH))
Libraries: C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x86; (at the end)
For the x64 tab I added:
Executables: C:\Program Files (x86)\Windows Kits\8.0\bin\x64; (just before $(PATH))
Libraries: C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\x64; (at the end)
Update...
I was also missing some SDK header files (winver.h and winapifamily.h). I added the following to the same TOOLS->Options... area.
For both the win32 and x64 tabs
Includes: C:\Program Files (x86)\Windows Kits\8.0\Include\um;C:\Program Files (x86)\Windows Kits\8.0\Include\shared;
I just figured out one (out of the 3 in total) projects in my VS2010 (SDK7.1) solution (projects are linked in a sequential linear dependency chain), had a .rc file in the project files that was empty.
Removing the empty .rc file (from the project, without deleting it) solved the "fatal error LNK1158: ... cvtres.exe" problem.
Update: The following copy fixed the problem:
xcopy "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\cvtres.exe" "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\x86_amd64\"
This will enable WinSDK7.1, via MSBuild, to be able to compile .rc files into the executables.
This is even easier than that with Visual Studio 2017. Follow these instructions: https://learn.microsoft.com/en-us/visualstudio/install/modify-visual-studio to modify using Microsoft Visual Studio Installer.
Once inside the Microsoft Visual Studio Installer, click modify under your installed Visual Studio package, make sure the Desktop development with C++ is checked, and the MFC and ATl support (x86 and x64), under summary.
This can be caused by a vcxproj that originated in previous versions of Visual Studio OR changing the Platform Toolset in Configuration Properties -> General.
If so, possible Solution:
1) Go to Configuration Properties -> VC++ Directories
2) Select drop down for Executable Directories
3) Select "Inherit from parent or Project Defaults"
Add to your environment variable window sdk 8.1 path
C:\Program Files (x86)\Windows Kits\8.1\bin\x64
then open Visual studio x64 Native tools command prompt and enter
vcvarsall.bat
If you really need to use the SDK Windows 10 with Visual Studio 2015, you have to download an older version on sdk-archive. Newer version of the SDK changed the place of the rc executable and MSBuild of Visual Studio 2015 update 3 (latest version) can't locate it.
At least the version 10.0.14393.795 of the SDK Windows is still compatible with Visual Studio 2015.
Maybe project file was touched by VS2017. Then when you link the project in 2015 "LINK : fatal error LNK1158: cannot run 'rc.exe'" can brake the build.
In vcxproj try to:
1) replace:
<WindowsTargetPlatformVersion>10.0.17763.0</WindowsTargetPlatformVersion>
with:
<WindowsTargetPlatformVersion>8.1</WindowsTargetPlatformVersion>
2) remove:
<VCProjectVersion>15.0</VCProjectVersion>
3) replace:
<PlatformToolset>v141</PlatformToolset>
with:
<PlatformToolset>v140</PlatformToolset>
I got the OP's link error about rc.exe when trying to execute pip install inside a bash task within an Azure DevOps pipeline that I was using to build a Python package from source with C++ extensions. I was able to resolve it by adding the path to rc.exe inside the bash task just before calling pip install, like so:
PATH="/c/Program Files (x86)/Windows Kits/10/bin/10.0.18362.0/x64":$PATH
That was inside an Azure job that was using vmImage: 'windows-2019' for its agent; i.e., Windows Server 2019 with Visual Studio 2019.
I was able to make it work for me also this way in windows
Set your environment variable to point to the location of your rc.exe
assuming you're using x86 version
C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x86
You can easily set your environment variable using
C:> setx path "%path%;C:\Program Files (x86)\Windows
Kits\10\bin\10.0.18362.0\x86"
Restart your Qt Creator
Clean and Rebuild
My answer to this quesiton.
Modify file C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Tools\vcvarsqueryregistry.bat
The content of :GetWin10SdkDir
From
#REM ---------------------------------------------------------------------------
:GetWin10SdkDir
#call :GetWin10SdkDirHelper HKLM\SOFTWARE\Wow6432Node > nul 2>&1
#if errorlevel 1 call :GetWin10SdkDirHelper HKCU\SOFTWARE\Wow6432Node > nul 2>&1
#if errorlevel 1 call :GetWin10SdkDirHelper HKLM\SOFTWARE > nul 2>&1
#if errorlevel 1 call :GetWin10SdkDirHelper HKCU\SOFTWARE > nul 2>&1
#if errorlevel 1 exit /B 1
#exit /B 0
to
#REM ---------------------------------------------------------------------------
:GetWin10SdkDir
#call :GetWin10SdkDirHelper HKLM\SOFTWARE\Wow6432Node > nul 2>&1
#if errorlevel 1 call :GetWin10SdkDirHelper HKCU\SOFTWARE\Wow6432Node > nul 2>&1
#if errorlevel 1 call :GetWin10SdkDirHelper HKLM\SOFTWARE > nul 2>&1
#if errorlevel 1 call :GetWin10SdkDirHelper HKCU\SOFTWARE > nul 2>&1
#if errorlevel 1 exit /B 1
#setlocal enableDelayedExpansion
set HostArch=x86
if "%PROCESSOR_ARCHITECTURE%"=="AMD64" ( set "HostArch=x64" )
if "%PROCESSOR_ARCHITECTURE%"=="EM64T" ( set "HostArch=x64" )
if "%PROCESSOR_ARCHITECTURE%"=="ARM64" ( set "HostArch=arm64" )
if "%PROCESSOR_ARCHITECTURE%"=="arm" ( set "HostArch=arm" )
#endlocal & set PATH=%WindowsSdkDir%bin\%WindowsSDKVersion%%HostArch%;%PATH%
#exit /B 0
Modify this single place will enable the support for all Windows 10 sdk along with all
build target of visual studio, including
VS2015 x64 ARM Cross Tools Command Prompt
VS2015 x64 Native Tools Command Prompt
VS2015 x64 x86 Cross Tools Command Prompt
VS2015 x86 ARM Cross Tools Command Prompt
VS2015 x86 Native Tools Command Prompt
VS2015 x86 x64 Cross Tools Command Prompt
They are all working.
In my case, I installed the Windows SDK 10586 via Visual Studio 2015 -> Modify, then the following paths are installed.
C:\Program Files (x86)\Windows Kits\10\bin\arm64\rc.exe
C:\Program Files (x86)\Windows Kits\10\bin\x64\rc.exe
C:\Program Files (x86)\Windows Kits\10\bin\x86\rc.exe
For Visual Studio Community 2019, copying the files in the answers above (rc.exe
rcdll.dll) to C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.21.27702\bin\Hostx86\x86 did the trick for me.
"Error LNK1158 cannot run 'rc.exe" could be resulted from your project was opened by newer MS VS version. For instance, your project was created in VS 2015, then later was opened by 2017. Then later your project is opened in 2015.
To resolve this issue, open yourProjectName.vcxproj, look for WindowsTargetPlatformVersion, and change to the correct VS version
For VS 2015, it should be 8.1
for VS 2017, it should be 10.0.17763.0
There are a lot of answers here, but I didn't see this one, which I believe is the right way to fix this Visual Studio bug. I recently had to install Visual Studio 2015 on a system that already had Visual Studio 2017 and 2019 along with multiple versions of the Windows SDK. When building either x86 or x64/debug or release, it could not find RC.EXE. The reason is that the Project's executable path (the $(VS_ExecutablePath)) value is incorrect. For x86 and x64, it's set to
C:\Program Files (x86)\Windows Kits\10\bin\x86
C:\Program Files (x86)\Windows Kits\10\bin\x64
which appears to be correct if 10 is replaced by 8.1 but I want to use the Windows 10 SDK not the Windows 8.1 SDK.
The Windows 10 SDK executables are actually in these directories (i.e. these are the SDKs I have installed right now):
C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\arm64\rc.exe
C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64\rc.exe
C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x86\rc.exe
C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\arm64\rc.exe
C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x64\rc.exe
C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x86\rc.exe
C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\arm64\rc.exe
C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x64\rc.exe
C:\Program Files (x86)\Windows Kits\10\bin\10.0.18362.0\x86\rc.exe
C:\Program Files (x86)\Windows Kits\8.1\bin\x64\rc.exe
C:\Program Files (x86)\Windows Kits\8.1\bin\x86\rc.exe
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin\RC.Exe
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin\x64\RC.Exe
In Windows 10 SDKs, the TargetPlatformVersion is part of the path, which allows the SDK executables/include/libs to be updated for each new TargetPlatform as it's released.
Choosing an RC.EXE and copying it to a directory in the path would work but each TargetPlatformVersion SDK directory has a different RC.EXE, so you might not know which one you are using -- especially if you have multiple developers and build machines. It's best to fix it in the projects.
To fix this,
Select all of the affected projects with Shift-Click
Right-click a selected project and select Properties,
Select VC++ Directories on the left
Select Executable Directories
Click the pull-down at the far right and select Edit.
Double-click the top blank line and for x86/win32 projects, add this to both Debug and Release configurations:
$(WindowsSdkDir)bin\$(TargetPlatformVersion)\x86\
For x64 projects, add this to both Debug and Release configurations:
$(WindowsSdkDir)bin\$(TargetPlatformVersion)\x64\
Leave "Inherit from parent or project defaults" checked. The "Evaluated Value" window may appear garbled but it seems to get fixed once you save and close the property pages.
I did not have to update "Library Directories" nor "Include Directories" but they might require similar changes.
This will make a number of entries in each Visual Studio project file that look like this:
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">
<ExecutablePath>$(WindowsSdkDir_10)bin\$(TargetPlatformVersion)\x86\;$(ExecutablePath)</ExecutablePath>
</PropertyGroup>
The right way to fix this is by editing the property sheet for Microsoft.Cpp.Win32.user or to define your own property sheet to add this value to the inherited values, but the Visual Studio 2015 property manager seems to be buggy (2017/2019 is much better) so I found it best to just put the value directly into the projects. This also means every other developer or build machine that uses these projects will be able to build, as long as the chosen Windows 10 SDK is installed.
I am facing a problem with integrating Microsoft Platform SDK with Visual Studio 2005 Express, now it looks like it does not include it with the default installation.
So I installed Microsoft Platform SDK for Windows 2003 (as reccomended by http://www.zedwood.com/article/134/visual-studio-express-2005-and-the-platform-sdk) and carried out accordingly) - Althogh I could not find C:\Program Files\Microsoft Visual Studio 8\VC\VCProjectDefaultscorewin_express.vsprops, so I could not comment out what he reccomended.
But the problem I face is that I have compiling from command line cl.exe, and it does not seem to be finding io.h (which I understand is part of the Microsoft Platform SDK) and doesn't seem to be included in Visual Studio 2005 Express.
How would I include this (io.h) file when compiling? (I know you can add INCLUDE values in the IDE, but as it's command line I don't think it will work - I have tried)
Note: Unfortunately I am restricted in using Visual Studio 2005 express, so I can't upgrade etc.
This has been driving me mad, so any help would be appreciated.
io.h should be in the C runtime include directory, not the SDK's. Something like:
C:\Program Files\Microsoft Visual Studio 8\VC\include\io.h
If you're running builds from the command line make sure the environment is set correctly. One way to do that is to run the \Program Files\Microsoft Visual Studio 8\Common7\Tools\vsvars32.bat script which should have been installed by VC2005 Express (there should be a shortcut to it on the start menu).
I'm using CUDA (VC++, Visual studio 2008sp1) to debug a FEM program. The program can only run on a Win32 platform, for the insufficiency of cuda. I think the library files linked are all compiled on the x86 platform, but when I compile it, I get the error message
fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86'.
I have tried to convert the platform to x64, but it didn't work. Please tell me: what is "module machine type" and what is "target machine type"? How can I overcome it?
I wrote a blog entry about this, as I encountered this maddening problem, and finally yanked my system back into working order.
These are the things to check, in this order:
Check your properties options in your linker settings at: Properties > Configuration Properties > Linker > Advanced > Target Machine. Select MachineX64 if you are targeting a 64 bit build, or MachineX86 if you are making a 32 bit build.
Select Build > Configuration Manager from the main menu in visual studio. Make sure your project has the correct platform specified. It is possible for the IDE to be set to build x64 but an individual project in the solution can be set to target win32. So yeah, visual studio leaves a lot of rope to hang yourself, but that's life.
Check your library files that they really are of the type of platform are targeting. This can be used by using dumpbin.exe which is in your visual studio VC\bin directory. use the -headers option to dump all your functions. Look for the machine entry for each function. it should include x64 if it's a 64 bit build.
In visual studio, select Tools > Options from the main menu. select Projects and Solutions > VC++ Directories. Select x64 from the Platform dropdown. Make sure that the first entry is: $(VCInstallDir)\bin\x86_amd64 followed by $(VCInstallDir)\bin.
Once I did step 4 everything worked again for me. The thing was I was encountering this problem on all my projects where I wanted to compile towards a 64 bit target.
In addition to C Johnson list I would add the following point:
Check in Visual Studio:
Project Properties -> Configuration Properties -> Linker -> Command line.
"Additional Options" should NOT contain /machine:X86
I have such key, generated by CMake output: CMake generated x86 project, then I added x64 platform via Configuration Manager in Visual Studio 2010 - everything was created fine for the new platform except that the linker command line, specified /machine:X86 separately.
I experienced the same problem in VS2008 when I tried to add a X64 build to a project converted from VS2003.
I looked at everything found when searching for this error on Google (Target machine, VC++Directories, DUMPBIN....) and everything looked OK.
Finally I created a new test project and did the same changes and it seemed to work.
Doing a diff between the vcproj files revealed the problem....
My converted project had /MACHINE:i386 set as additional option set under Linker->Command Line. Thus there was two /MACHINE options set (both x64 and i386) and the additional one took preference.
Removing this and setting it properly under Linker->Advanced->Target Machine made the problem disappeared.
All project settings seemed perfect, but I still got the error. Looking into the .vcxproj file and searching for "x86" revealed the problem:
<Lib>
<AdditionalOptions> /machine:X86 %(AdditionalOptions)</AdditionalOptions>
</Lib>
A quick search/replace for all occurrances (ten individual file settings) fixed the problem.
You probably have one .OBJ or .LIB file that's targeted for x64 (that's the module machine type) while you're linking for x86 (that's the target machine type).
Use DUMPBIN /HEADERS on your .OBJ files and check for the machine entry in the FILE HEADER VALUES block.
Since the problem is due to the difference in compilation and target machine specifications (x86 & x64)
Follow the steps below:
Open the C++ project that you want to configure.
Choose the Configuration Manager button to open the Configuration Manager dialog box.
In the Active Solution Platform drop-down list, select the option to open the New Solution Platform dialog box.
In the Type or select the new platform drop-down list, select a 64-bit platform.
It solved my problem.
In Visual Studio 2012 +/-, the property page for "Configuration Properties'.Linker."Command Line" contains a box labeled "Additional Options". If you're building x64, make sure that box doesn't contain /MACHINE:I386. My projects did and it generated the error in question.
I came across this problem when building QT. The instructions I read somewhere suggested that I configure nmake using VS command prompt.
I chose the x64 command prompt and performed configure without much hassle. When i tried nmake, it gave this error.
I think some of the components were pre-built for 32-bit. The error even reported which modules were built for x86.
I used the 32 bit default VS command prompt and it worked.
"project property - CUDA Runtime API - GPU - NVCC Compilation Type"
Set the 64 bit compile option -m64 -cubin
The hint is at compile log.
Like this:
nvcc.exe ~~~~~~ -machine 32 -ccbin ~~~~~
That "-machine 32" is problem.
First set 64bit compile option,
next re setting hybrid compile option.
Then u can see the succeed.
In Visual Studio 2013,
1) Check in the Project Property Pages / Configuration Properties / Linker / All Options and correct all the miss configured machine and directories.
2) Check in the Project Property Pages / Configuration Properties / Linker / Input and correct all the miss configured directories.
See example of 1)
If your solution has lib projects check Target Machine property in Property->Librarian->General
vcxproj file may contain 'MACHINE:i386'
Edit vcxproj file with editor. remove it !
My target is a x64 Windows 10 text mode DOSBox application in C language.
Using "Visual Studio 2019 Community" to compile through DOS prompt "nmake -f makefile".
The error is similar but on the opposite side:
fatal error LNK1112: module machine type 'x32' conflicts with target machine type 'X64'
It's ok to compile by VC++ 2010 on another computer. But failed on this computer by "Visual Studio 2019 Community". So my settings are correct and all above answers do not work.
I'd like to share you that the solution is a make.bat like this:
call "c:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Auxiliary\Build\vcvars64.bat"
nmake -f makefile
You will find there are many other vcvarsxxxx.bat, only this one words.
In my case, setting environment variable PROCESSOR_ARCHITECTURE to AMD64
fixed the problem.
https://social.msdn.microsoft.com/Forums/en-US/f9303904-81ce-405d-85b3-b66d97e49971
In addition to Jhonson's list, also check library's folders
In visual studio, select Tools > Options from the main menu. select Projects and Solutions > VC++ Directories. Select x64 from the Platform dropdown.
$(VCInstallDir)lib\AMD64;
$(VCInstallDir)atlmfc\lib\amd64;
$(WindowsSdkDir)lib\x64;
This happened to me today because I had added a library directory while still in x86 mode, and accidently removed the inherited directories, making them hardcoded instead.
Then after switching to x64, my VC++ Directories still read:
"...;$(VC_LibraryPath_x86);$(WindowsSDK_LibraryPath_x86);"
instead of the _x64.
I was using CMake & then added a win32 configuration. The property page showed x86 but actually when opening the vcxproj file in a text editor it was x64! Manually changing to x86 solved this.
First of all try the following things:
1. goto configuration Manager and create a new x64 if it is not already there.
2. select the x64 solution.
3. go to project properties and then Linker->Advanced select x64 machine.
4. Now rebuild the solution.
If still you are getting the same error. try clean solution and then rebuild again and open visual studio you will get list of recent opened project , right click on the project and remove it from there. Now go to the solution and reopen the solution again.
It's a very frustrating and annoying problem but once you understand it, it's quite simple: you have some element in you're build that building one architecture type (in your case x64) despite the fact that it's been target for another type (say x86).
You can dissect the source of your problem by looking at which obj file is causing the crash and start looking for the problem there. Every obj will have a source code analog: either in cpp, c, asm etc. There may be special build events around it that are using the wrong tool. Check for that in the property sheets.
I'd look there first before going through C Johnson list of things to do.
I solved this problem by changing Win32 to *64 in Visual Studio 2013.
Many good suggestions above.
Also if you are trying to build in x86 Win32:
Make sure that any libraries you link to in Program Files(x86) are actually x86 libraries because they are not necessarily...
For example a lib file I linked to in C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\SDK threw that error, eventually I found an x86 version of it in C:\Program Files (x86)\Windows Kits\10\Lib\10.0.18362.0\um\x86 and everything worked fine.
Properties->configurationManager-> ActiveSolutionPlatform . Here select x64 .thats all.
It should take care of all dependencies and compilation should work smoothly
module machine type is the machine on which you are compiling and the target machine type is the the architecture x86 or x64 for which you are building your binaries.
This problem may also happen if your project set up to have the same intermediate directories in Project Properties -> Configuration Properties -> General
this happens to me when i convert my VS2008 solution to VS2010 & change win32 configuration to X64, in my old solution I have mfcs90d.lib (Configuration->Linker->Input->Additional dependencies), as I am using VS010 i just checked in VS2010 folder where it is mfcs100d.lib, so I changed mfcs90d.lib to mfcs100d.lib in (Configuration->Linker->Input->Additional dependencies) it worked fine.
For those who are with QT Creator, the issue is same (as described by #c-johnson).
Make sure the compiler settings for MSVC in your kit is set to x86 as shown below.
for some using command prompt (dos prompt)
this might be helpful:
call "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" --help
Error in script usage. The correct usage is:
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" [option]
or
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" [option] store
or
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" [option] [version number]
or
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" [option] store [version number]
where [option] is: x86 | amd64 | arm | x86_amd64 | x86_arm | amd64_x86 | amd64_arm
where [version number] is either the full Windows 10 SDK version number or "8.1" to use the windows 8.1 SDK
:
The store parameter sets environment variables to support
store (rather than desktop) development.
:
For example:
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86_amd64
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86_arm store
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86_amd64 10.0.10240.0
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x86_arm store 10.0.10240.0
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x64 8.1
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\vcvarsall.bat" x64 store 8.1
:
Please make sure either Visual Studio or C++ Build SKU is installed.
Also If you do like this:
CL "%1%2%3" /EHsc /link user32.lib Gdi32.lib Winmm.lib comctl32.lib *.obj /SUBSYSTEM:CONSOLE /MACHINE:x86
you have to del *.obj before; to avoid confusing linker with both 64 and 32 bit objects left over from prior compilations?
I have fixed this problem for myself as follows.
First of all, I followed the other answers for this question, only to conclude that all the project settings were correct.
Then I inspected the .vcxproj file with an editor and noticed that the < Link > properties for the two (Debug and Release) x64 configurations did not specify < TargetMachine >, while the Win32 configurations both contained < TargetMachine > MachineX86 < /TargetMachine >.
However, I had already verified, looking from Visual Studio at Properties > Configuration Properties > Linker > Advanced > Target Machine, that the x64 configurations said MachineX64 (/MACHINE:X64).
So, I edited the .vcxproj file to include < TargetMachine > MachineX64 < /TargetMachine > in the two x64 configs. Going back to the Visual Studio project properties dialog, I noticed that the MachineX64 (/MACHINE:X64) setting was there as before, except that now it showed in bold (apparently meaning that the value is not the default one).
I rebuilt, and it worked.