I've got the infamous error message in C++ build: "Cannot open include file: 'ctype.h'". I know a similar question was already asked multiple times, but my case seems different because I am using the latest Visual Studio 2022 and seems to behave differently.
I have a bunch of existing C++ projects, they use plain 32-bit Windows API with DirectX 6, and I used VC++ build tools 2015 and Windows SDK 8.1 to compile it without any issues in previous versions of Visual Studio. Everything was fine in Visual Studio 2019, no special setup was needed, until I uninstalled it and installed Visual Studio 2022.
Now I can open my solutions, it nicely shows they are using C++ build tools 2015, which I installed together with VS2022, and the solutions also shows correctly that they use Windows 8.1 SDK. But Windows 8.1 SDK is not present in VS2022 installation, I installed it separately. I also tried to "repair" VS2022 installation, but that only deleted all my UI preferences, but not fixed anything in build. Also, I tried to reinstall Windows 8.1 SDK, but it said it is already OK.
When looking to Visual Studio, I can't see any place where I can set default include and lib directories, I can only list what is being used right now. VS2022 shows this list:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\atlmfc\include
C:\Program Files\Windows Kits\10\Include\10.0.10240.0\ucrt
C:\Program Files (x86)\Windows Kits\8.1\Include\um
C:\Program Files (x86)\Windows Kits\8.1\Include\shared
C:\Program Files (x86)\Windows Kits\8.1\Include\winrt
The actual error message I receive is this:
c:\program files (x86)\windows kits\8.1\include\um\winnt.h(31): fatal error C1083: Cannot open include file: 'ctype.h': No such file or directory
So it says that winnt.h from windows kits 8.1 cannot find ctype.h. And yes, there is no ctype.h in that folder or anywhere around, I can see it only in C:\Program Files\Microsoft Visual Studio\2022\Professional\SDK\ScopeCppSDK\vc15\SDK\include\ucrt
which I think is the folder with VC++ 2015 build tools. So this seems correct, but I am wondering why this folder is not a part of default include directories when VC++ 2015 build tools are set in project settings. Because it seems that VS2022 is correctly picking my Windows 8.1 SDK, but not picking correctly the older C++ compiler.
When I try to add the folder where ctype.h resides to include folders, I receive another type of errors saying that other files are incompatible with these include files. Of course, this system of directories needs to be in sync. So please what is the correct way of using this?
Also, I tried to switch the VC++ build tools to 2022 version. Unfortunately, that also does not fix the issue. And Windows 10 SDK is not installed, the software wants to stay compatible with older Windows, so I don't need it.
I found a bug report which is related: https://developercommunity.visualstudio.com/t/windows-81-sdk-1/151682
Although Microsoft staff declined to accept it as a bug, it is happening for me as well. When I install only Windows 8.1 SDK, no project can be compiled with it. I even tried to create a new Windows API project in VS2022, the project was created, but failed to compile with the same error.
So I tried to install Windows 10 SDK (from VS2022 installed, but that is probably not important) and this added some missing files which now help to compile Windows 8.1 SDK projects. Problem seems to be solved, my old C++ code can now be compiled with Windows 8.1 SDK and both C++ build tools 2015 and 2022.
I have an application relying on user mode tracing via wpp framework. However, Microsoft introduced some changes in the couple of latest version of Windows SDK which broke the tracewpp.exe tool somehow. The actual problem I'm seeing looks as following:
& "C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64\tracewpp.exe" ... more args ...
Works as expected (I have checked older versions of SDK, down to 8.0 - all nice and good).
However, when I try to perform the same build with newer version of the SDK the build breaks with a rather cryptic error:
& "C:\Program Files (x86)\Windows Kits\10\bin\10.0.17134.0\x64\tracewpp.exe" ... all the same args ...
Results in:
provider.tpl(0) : error wpp : (Template::DoId) Var not found: Provider
tracewpp(0) : error wpp : (RealMain) Fatal error: Template parse error
The template in question originally comes from here: https://github.com/antoxar/WPPTracingSample/blob/master/sample/WppTracing/WppConfig/Rev1/provider.tpl
Can somebody point me at the change log for the tracewpp.exe tool, outlining what changes were done to it recently or otherwise shed light on the above issue?
I had the same problem and solved it. In my case Microsoft Visual Studio 2017 was using the 10.0.17763.0 SDK and running the WPP tools in:
WindowsSdkVerBinPath=C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\
But my tracewpp command was referring to an older "WppConfig\Rev1" directory. The newer tools expected a different provider.tpl configuration. I had these various version installed, and was referring to an older version (the last one) instead of the matching "17763" one.
C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\WppConfig\Rev1
C:\Program Files (x86)\Windows Kits\10\bin\WppConfig\Rev1
If using a Pre-Build step in Visual Stdio, changing the path from $(WindowsSdkDir) to $(WDKBinRoot) worked for me (your other options may vary):
tracewpp -I"$(WDKBinRoot)\WppConfig\Rev1" -odir:$(IntDir) -scan:Trace.h *.cpp
As an aside, a Debug build of my project failed as well. Make sure to use the compiler flag /Zi if you want debug symbols instead of /Zl (Debug with Edit and Continue). wpptrace doesn't support it.
I have Visual Studio 2015 installed, and I need to compile a specific project with Visual C++ 2010 compiler, which is included in SDK 7.1.
I want to use 2010 compiler within VS2015, without install VS2010.
So, I installed it (the SDK), and "Visual Studio 2010 (v100)", "Windows7.1SDK" options appear under "Platform Toolset" property in the project properties.
But, when I try to build the project, I get those errors:
With "Windows7.1SDK" -
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\x64\Microsoft.Cpp.x64.Targets(146,5): error : Required file "" is missing.
and with "Visual Studio 2010 (v100)" -
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(297,5): warning MSB8003: Could not find WindowsSDKDir variable from the registry. TargetFrameworkVersion or PlatformToolset may be set to an invalid version number.
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\x64\Microsoft.Cpp.x64.Targets(146,5): error : Required file "" is missing.
Can't figure out what the problem is..
I had the same issue for 2 weeks and just found a workaround that might help :
Without modifying anything to my VS2010 projects (not changing the toolset in the vcxproj), I use the command line build tools MSBuild tools with the toolset specified as a switch as found here Building C++ project on a PC with Windows SDK 7.1 but without VS2010
msbuild /p:PateformToolset=Windows7.1SDK project.vcxproj
(In my case, the corresponding msbuild is in the folder C:\Windows\Microsoft.NET\Framework\v4.0.30319)
If Msbuild throws an error telling its missing mspdb100.dll, you may need to add %PROGRAMFILES(X86)%\Microsoft Visual Studio 10.0\Common7\IDE\ to your %PATH% env var.
Finally, you may have some files missing like ammintrin.h (especially if like me you try to compile old InDesign plugins) even after installing the visual c++ updates.
The only (and ugly) workaround I found in my case that does not involve installing VS2010 (the common answer of MS) is to copy the missing includes from the %PROGRAMFILES(X86)%\Microsoft Visual Studio 14.0\VC\include folder to the %PROGRAMFILES(X86)%\Microsoft Visual Studio 10.0\VC\include one.
Voila ! Hope this helps
How to install SignTool.exe in Visual Studio 2015 for Windown 10?
I tried to build my project but the program threw an error :
Error An error occurred while signing: SignTool.exe not found.
You need to install the Windows 10 SDK.
Visual Studio 2015 Update 1 contains it already, but it is not installed by default. You should go to Control Panel -> Programs and Features, find Microsoft Visual Studio 2015 and select "Change".
Visual Studio 2015 setup will start. Select "Modify".
In Visual Studio components list find "Universal Windows App Development Tools", open the list of sub-items and select "Windows 10 SDK (10.0.10240)".
Windows 10 SDK in VS 2015 Update 1 Setup
Of cause you can install Windows 10 SDK directly from Microsoft: https://go.microsoft.com/fwlink/?LinkID=698771
As josant already wrote - when the installation finishes you will find the SignTool.exe in the folders:
x86 -> c:\Program Files (x86)\Windows Kits\10\bin\x86
x64 -> c:\Program Files (x86)\Windows Kits\10\bin\x64\
If you only want SignTool and really want to minimize the install, here is a way that I just reverse-engineered my way to:
Download the .iso file from https://developer.microsoft.com/en-us/windows/downloads/windows-10-sdk (current download link is http://go.microsoft.com/fwlink/p/?LinkID=2022797) The .exe download will not work, since it's an online installer that pulls down its dependencies at runtime.
Unpack the .iso with a tool such as 7-zip.
Install the Installers/Windows SDK Signing Tools-x86_en-us.msi file - it's only 388 KiB large. For reference, it pulls in its files from the following .cab files, so these are also needed for a standalone install:
4c3ef4b2b1dc72149f979f4243d2accf.cab (339 KiB)
685f3d4691f444bc382762d603a99afc.cab (1002 KiB)
e5c4b31ff9997ac5603f4f28cd7df602.cab (389 KiB)
e98fa5eb5fee6ce17a7a69d585870b7c.cab (1.2 MiB)
There we go - you will now have the signtool.exe file and companions in C:\Program Files (x86)\Windows Kits\10\bin\10.0.17763.0\x64 (replace x64 with x86, arm or arm64 if you need it for another CPU architecture.)
It is also possible to commit signtool.exe and the other files from this folder into your version control repository if want to use it in e.g. CI scenarios. I have tried it and it seems to work fine.
(All files are probably not necessary since there are also some other .exe tools in this folder that might be responsible for these dependencies, but I am not sure which ones could be removed to make the set of files even smaller. Someone else is free to investigate further in this area. :) I tried to just copy signtool.* and that didn't work, so at least some of the other files are needed.)
Here's where you'll find it:
C:\Program Files (x86)\Windows Kits\10\App Certification Kit
Screenshot:
Best solution end of 2020:
Just download Windows 10 SDK from Microsoft here:
https://go.microsoft.com/fwlink/?LinkID=698771
In setup, choose only Windows App Certification App (it's only 184 MB)
You can find signtool.exe here:
%PROGRAMFILES(X86)%\Windows Kits\10\bin\x64
Cheers!
As per the comments in the question... On Windows 10 Signtool.exe and other SDK tools have been moved into "%programfiles(x86)%\Windows Kits\".
Typical path to signtool on Windows 10.
32 bit = "c:\Program Files (x86)\Windows Kits\10\bin\x86\signtool.exe"
64 bit = "c:\Program Files (x86)\Windows Kits\10\bin\x64\signtool.exe"
Tools for SDK 8.0 and 8.1 also reside in the "Windows Kits" folder.
Another answer from 2021.
You might not need Windows SDK at all. If you have VS-2019 installed, you might already have signtool in C:\Program Files (x86)\Microsoft SDKs\ClickOnce\SignTool\signtool.exe
NOTE: The good thing about this particular signtool version (compared to the Windows SDK one), is that it's self-contained, and does not need all the dll's next to it (mssign32.dll, wintrust.dll etc, which usually lie around in Windows SDK folders).
You can even add this file to your source code repo (just one file), since this tool hasn't changed since 2016.
P.S. I had this signtool even without "ClickOnce publishing" component installed in my Visual Studio Community Edition.
Location:
C:\Program Files (x86)\Windows Kits\10\App Certification Kit\signtool.exe
In 2019, this is a quite recent link from Microsoft about how to obtain this tool:
The SignTool tool is a command-line tool that digitally signs files,
verifies signatures in files, or time stamps files. For information
about why signing files is important, see Introduction to Code
Signing. The tool is installed in the \Bin folder of the Microsoft
Windows Software Development Kit (SDK) installation path.
SignTool is available as part of the Windows SDK, which you can
download from https://go.microsoft.com/fwlink/p/?linkid=84091.
I only needed signtool, so I chose the minimal I came up with and signtool.exe is now in C:\Program Files\Microsoft SDKs\Windows\v7.1\Bin\signtool.exe
Microsoft article link:
https://learn.microsoft.com/en-us/windows/win32/seccrypto/signtool
to install just the signingtools from the winsdksetup.exe (available at the same url as the windows sdk iso mentioned above) this is an option to, straight from the Dockerfile i'm working in:
RUN powershell Start-Process winsdksetup.exe -ArgumentList '/features OptionId.SigningTools', '/q', '/ceip off', '/norestart', -NoNewWindow -Wait
so if you're in windows then that'd be:
winsdksetup.exe /features OptionId.SigningTools
winsdksetup /h gives you the options, so i won't summarise them here.
I include the dockerfile snippet, as that is what i started my day looking for the solution for.
You don't have to install the Signtool. It might already be there.
Go to C:\Program Files (x86)\ and search for signtool.exe. In my system I found it under C:\Program Files (x86)\Microsoft SDKs\ClickOnce\SignTool
No matter which version of Windows you are using, the above signtool will solve your purpose.
If you're using VS Express 2015, just go to your control panel --> programs and features --> select vs 2015 --> click change, then in the VS Express installer select 'Modify' --> select Publishing tools, and finish. Once setup completes the changes you will be able to create your installer.
You should go to Control Panel -> Programs and Features, find Microsoft Visual Studio 2015 and select "Change".
Visual Studio 2015 setup will start. Select "Modify".
In Visual Studio components list, open the list of sub-items and select "ClickOnce Publication Tools" and "Windows 10 SDK" too.
I did a modify with the Visual Studio from Control Panel, Programs and Features. The SDK was not at first apparent so I installed the Common Tools which lo and behold did include the SDK Update 3.
It's available many, many places, depending upon what is installed:
On my box, every one except the v6.0A SDK version supports the /fd option.
SignTool is available as part of the Windows SDK (which comes with Visual Studio Community 2015). Make sure to select the "ClickOnce Publishing Tools" from the feature list during the installation of Visual Studio 2015 to get the SignTool.
Once Visual Studio is installed you can run the signtool command from the Visual Studio Command Prompt.
By default (on Windows 10) the SignTool will be installed in:
C:\Program Files (x86)\Windows Kits\10\bin\x86\signtool.exe
For me in 2021 the signtool.exe was here: "C:\Program Files (x86)\Windows Kits\10\bin\x64" or in: x86
and not under: C:\Program Files (x86)\Windows Kits\10\App Certification Kit
even if I have this folder and may files in it.
I ran into an issue using this tool in a restrictive Azure DevOps Pipelines environment, where I couldn't even expand PATH or call any tools from an absolute path outside of the ADO build directories, meaning in this case anything from C:\Program Files (x86)\
My solution was to package it as a Secure File in ADO Pipelines' Library -> Secure Files section, allow my pipeline to access the file via its security settings, then download it as a build task and run it via a powershell task.
In the example below, I just query the help with the /? command. Just replace that with whatever command you want to use.
- task: DownloadSecureFile#1
displayName: "Signtool Download"
name: MSSignTool
inputs:
secureFile: 'signtool.exe'
- task : PowerShell#2
displayName: "Run Signtool"
inputs:
targetType: "inline"
script: $(MSSignTool.secureFilePath) /?
Warning 1: I'm not sure what dependencies are required for signtool.exe to work standalone, or if it even has any. The Windows 10 SDK and ADK was already installed in this build environment. If querying the help causes the tool to fail or crash, make sure one or both of those are installed. Hopefully you will have access to something like choco to install any missing dependencies.
Warning 2: Be careful if copying those code segments. ADO is pretty strict with dynamic whitespace, so if your spacing is off it will brick your whole pipelines file until you adjust the spacing to its correct position.
I installed Qt5.2 msvc2012 version on my system, and after couple of failed tries to compile my projects - which were coded in the mingw version on windows (actually the Android package one) - I tried to create a new gui project and see if that works.
No surprise it didn't work and gave me the error:
F:\ms\Qt5.2.0\5.2.0\msvc2012\include\QtCore\qglobal.h:46: error:
C1083: Cannot open include file: 'stddef.h': No such file or directory
I searched a lot of places but couldn't figure out what was causing this problem. I even uninstalled the mingw version completely (5.2.0-android-x86-win32-offline.exe) still no luck.
I had Visual Studio 2010 and Visual Studio 2013 installed on my system when I went for installing qt5.2, the mingw version worked fine till when I had to switch to msvc for my project. I tried installing 5.2.0-msvc2012-x86-offline.exe and noticed it needs Visual Studio 2012 in order to compile, so I went and installed Visual Studio 2012.
After that I am getting such error plus several ones mentioned here. I even tried installing WDK and WSDK but it's not working. The path I believe is configured correctly and files do exist. This is my include path in environmental variable on windows 7sp1 x86
J:\Program Files\Microsoft Visual Studio 11.0\VC\INCLUDE;J:\Program Files\Microsoft Visual Studio 11.0\VC\ATLMFC\INCLUDE;C:\Program Files\Windows Kits\8.0\include\shared;C:\Program Files\Windows Kits\8.0\include\um;C:\Program Files\Windows Kits\8.0\include\winrt;
What is wrong and how can I solve this problem?