I've installed VS 2017 on Windows 7 machine and built the C++ project targeting 8.1 SDK, but the binaries are not starting on windows 7. The same works on Windows server 2016 and Windows 10 OS.
I had checked VC 2015 runtime is installed on both the windows server and windows 7 machine. And windows 8.1 SDK (as part of VS 2015?) is installed on my local machine running on Windows 7. Previously, I had Visual studio 2015 installed and the binaries used to work fine both on windows 7 and windows server.
I am not sure if the runtime dlls in windows\system32 are corrupted or changed due to VS 2017 installation.
PS: I noticed the same issue of exe not starting when running the newly installed firefox which comes with C-runtime dlls packed.
The problem turned out to be due to the use of the instruction set (AVX2) used by the dependency project, that wasn't available in the windows machine.
Related
I'm facing the following issue:
Background
I have a Win32 legacy application (exe & dll's) and drivers (dll's) written on Visual Studio 6.0 that used to run
well in Debug version on Windows Xp (Please Note: We need it in DEBUG configuration & not Release).
I copy the Visual studio 6.0's msvc* type dll's, MFC dll's & manifest files along with the exe to make it run.
Issue:
The same legacy 32-bit application & driver dll's have now been newly compiled in Visual Studio 2008 DEBUG mode.
It is then copied to a PC running on 64-bit Windows 10 PC (also tried Windows 7 without success) without having VS2008
installed. I copy the VS2008's msvc* type dll's (msvcp90d.dll, msvcr90d.dll), MFC dll's and manifest file (Microsoft.VC90.DebugCRT.manifest) also along with the exe.
On launching this debug version of the application (it does many initialization activities on startup and also calls the init methods of driver dll's) it crashes on starting up both on a 64-bit Windows 10 & Windows 7 PC.
What works:
When VS2008 is installed on the Windows 10 PC, the application's debug version launches correctly without crash and works fine.
(Also please note that same application's Debug build using the old Visual Studio 6.0 works fine on Windows 10).
What DOESN'T work:
When VS2008 is NOT installed on a Windows 10 PC, the application's debug version crashes while it is being launched.
Requirement
We absolutely need the DEBUG configuration of the application to run on the Windows 10 PC.
Development environment
OS for development: 64-bit Windows 7
Target OS: 64-bit Windows 10
IDE: Visual Studio 2008 SP1
Application & driver dlls/exe's: 32-bit
I have tried many workarounds like building by using 32-bit paths in VS2008 ($\Program Files (x86)\Microsoft SDKs\Windows..),
installed redistributables of VS2008 (both x86 & x64),
running as 'Administrator' user,
running in compatibility mode (Win Xp..),
copying dll's from system32 folder of a PC having VS2008 installed to a PC without VS2008 etc.. but the Debug build always crashes on it's startup.
Any help or pointers would be appreciated.
Please let me know if you would like to have further details.
Thank you in advance.
I have a directory "C:\Program Files (x86)\Windows Kits". An exe in the subfolder of this folder is being called when I build a winPhone App. I did not install this specifically. How was this installed on my system? I am guessing maybe it came with windows install or some visual studio install. How do I update this?
I have 8.0, 8.1 and 10 as subfolders too. I think I can manually update each version from here. https://developer.microsoft.com/en-us/windows/downloads/sdk-archive
Just trying to figure out how these are installed and how are they supposed to be upgraded.
Windows Kits are available in stand-alone downloads, but primarily they are deployed and upgraded by Visual Studio.
Visual Studio 2013 includes Windows 8.1 SDK (for Windows Store apps and Windows desktop apps on Windows Vista SP2 or later) and the Windows 7.1A SDK (for Windows desktop apps on Windows Server 2003 SP1 or Windows XP SP3). VS 2013 Update 5 included the Windows 8.1 SDK (Spring 2015 Refresh).
Visual Studio 2015 includes the Windows 8.1 SDK (Spring 2015 Refresh) and Windows 7.1A SDK by default, and installing the Windows Tools option for UWP development adds a Windows 10 SDK. There are currently three versions available: 10240 (RTM), 10586 (Version 1511), and the latest is 14393 (Version 1610). A little bit of the Windows 10 SDK is always installed to support the Universal CRT used by Visual Studio 2015.
Windows 10 SDK versions are side-by-side installed.
See A Brief History of Windows SDKs.
For more on using the Windows 7.1A SDK for targeting Windows XP SP3, see Visual Studio 2012 Update 1
UPDATE: VS 2017 initially shipped with Windows 10 SDK (14393). Later updates included 15063, 16299, 17134, and 17763. VS 2019 shipped with Windows 10 SDK (17763) but was updated to include 18362 and 19041.
VS 2015 is only officially supported up to Windows 10 SDK (14393). VS 2017 can use Windows 10 SDK (18362) or Windows 10 SDK (19041), but you have to install it separately from VS 2017.
I have Visual Studio 2013 running on Windows 7 Pro. I needed the Windows Driver Kit for a project so I downloaded and installed this WDK 8.1 Update (for Windows 8.1, 8, and 7 drivers).
In this case I had not installed components such as the Windows Driver Kit Version 7.1.0 before installing WDK 8.1 Update.
Now I do not see the build environments created anywhere so I am not sure if this version of WDK requires either an earlier version of WDK as well, if something went wrong during installation, or if Microsoft made changes to the build environments.
However, when I had the aforementioned Windows Driver Kit Version 7.1.0 installed on another machine, it had created the build environments shown below.
Should the WDK 8.1 Update be sufficient on its own to create the build environments and if so, where can they be accessed?
Starting with Window 8 all tools (Debugger, Windows performance Tools, ADK, WDK) are installed under C:\Program Files (x86)\Windows Kits\VERSION and can be found under Windows Kits in the startmenu. Look a bit under your current position to access the Windows Kits folder.
I have old source that needs to be compiled on VC 6 C++ version.
For that I run a Windows 2008 (32bit) virtual machine and installed the 2003 platform SDK.
I wanted to make a new machine running windows 2008 R2 and therefor it is Windows SDK for Windows Server 2008 and .NET Framework 3.5 available to install.
So here is the question: Does this platform SDK include the old includes, header files and libs so I can compile the sources or is that not possible at all?
Tho I can't install the 2003 platform SDK on the 2008 R2 machine (at least the default setup won't let me do it).
Just for everyone to know asking the same: I had no problem installing VC++ 6 on a Win2k8 R2 even with warnings. Moved all SDK Files to the machine as well and manually setup all the include, libs, app pathes in the correct sort order I had on the other machine.
Compiled all components without a problem. So finally it seems it works even with some stress-calls from the setup program that there is no support for this.
I have a Windows 7 machine with Visual Studio 2005 SP1 installed. Using this, I build an application which loads a DLL at runtime compiled with VS2005 SP1 but on Windows XP. This fails, with the following error:
"...\foo.dll": The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.
The DLL loaded is compiled against the debug CRT. The answer to this question hints that vcredist_x86.exe only contains release-versions of the CRT. I'm not sure if that is relevant in this case, since both my machine and the machine on which the DLL was compiled on both have the full VS2005 SP1 installed.
Should I attempt to rebuild the DLL on Windows 7 (I'd prefer not to), and will that cause the DLL to become unusable on the Windows XP machine?
Problem solved. The problem was that the Windows 7 machine did not have the KB971090 update which was installed on the Windows XP machine which built the DLLs. I had to explicitly tell Windows Update that I wanted to receive non-Windows updates in order to be able to install the update.