When I'm trying to compile my C++ project in Visual Studio, I keep getting the 2 following errors:
E1574: Static assertion failed with "Windows headers require the default
packing option. Changing this can lead to memory corruption. This diagnostic
can be disabled by building with WINDOWS_IGNORE_PACKING_MISMATCH defined."
and
C2338: Windows headers require the default packing option. Changing this can
lead to memory corruption. This diagnostic can be disabled by building with
WINDOWS_IGNORE_PACKING_MISMATCH defined.
I think the issue has to be something in my Visual Studio settings, cause the project compiles fine on my other PC, and I just installed Visual Studio on this PC.
From doing some searches look like the issue stems from a mismatch of Windows packages, however when installing Visual Studio I tried to install all the C++ and Windows 10 modules I saw.
Also, I'm only including windows.h in order to use ShellExecute(), so if there's a better way to use ShellExecute() I'm open to that. Thanks!
As 1201ProgramAlarm mentioned above, the solution was disabling the /Zp (structure packing) compiler option.
Related
I am trying to run a program I compiled in Visual Studio 2013. However, I get the error
The program can't start because MSVCP110D.dll is missing from
your computer. Try reinstalling the program to fix this problem.
This is not a very helpful error. However, after some Googling, I found that it is (apparently) trying to load a standard c++ library dynamically, and that to get around this I need to specify the /MT option rather than the /MD option. This leaves me with a number of questions:
What exactly is that doing?
What are the benefits of /MD as opposed to /MT? I mean, there must be a reason that it is the default options...
How would I go about getting the looked for .dll and getting Visual Studio to use it? I downloaded this, but honestly don't know exactly how to use it.
Most importantly, how to I get that error to go away and my program to run?
Some additional info: I am compiling in Release mode using an x64 build.
The problem is that you are mixing different versions of Visual Studio by using Qt that was compiled using a different compiler. Remember that each version of Visual Studio will have its own runtime/CRT. The Qt dlls that were compiled with Visual Studio 2012 and will be dependent on the Visual Studio 2012 runtime. They will not use the 2013 runtime.
The solution to this problem is to recompile all of your code and dependent libraries/dlls with the same compiler.
Warning:
Some users will try to just install the dynamic runtime (or recompile dependent libraries with static CRT) from the other version of Visual Studio however this is not a solution to this problem mainly because each runtime has its own independent heap. Having separate heaps can and will lead to random crashes caused by allocating memory in one heap and then trying to free it in a different heap. Since the heaps do not share information about allocations or deallocations this leads to having corrupt heaps. From my experience the problem does not always cause an instant crash. The crash may or may not happen on the next allocation of the corrupt heap so debugging this situation can be very frustrating.
What I'm having is that this error is displayed when I wanted to copy a exe debug project that I have created (which works witout any problems) to another machine (the error message is displayed).
According to the question posted previously, the best solution to get rid of the error message is to make a release and not a debug in the Configuration Manager.
Doing that, and when rebuilding the project with the RELEASE one, I'm having new errors in my project which were not included when doing the DEBUG.
For instance, one of them is :
Error 2 error C1083: Cannot open include file: 'opencv\highgui.h': No such file or directory c:\...\projects\...\ex\opencv.h 4
23 IntelliSense: identifier "IplImage" is undefined c:\...\ex.cpp 80
Any feedbacks?
You've probably added include paths for OpenCV to your project file. Unfortunately, Visual Studio by default makes such changes ONLY to the active configuration, which in your case was debug.
This rarely makes sense. Adding a logging library would be such a rare case, but you probably needs OpenCV in both debug and release builds.
MSVCP100.dll is part of the Microsoft Visual Studio 10 runtime. MSVCP100d.dll is the debug build of the same dll - useful for running your program in debug mode.
http://www.microsoft.com/en-us/download/details.aspx?id=5555
Basically it is a relatively new package and is not guaranteed to be on all systems, especially Windows XP, so you can distribute the required DLL files or the entire runtime with your program. EDIT: Keep in mind that debug builds are not meant to be distributed, so your program should not contain debug dll-s either such as MSVCP100d.dll.
Try downloading it, and then see what happens.
Also check out this question.
MSVCP100D.dll and MSVCP100.dll is part of the Microsoft Visual Studio 10 runtime, so if someone compile her/his programs with this package, then uninstall the package and install another one for example Microsoft Visual Studio 12 (2013).
When trying to run her/his programs , then her/his will get the message that 'so and so... try to reinstalling the program to fix this problem'. this means you have to reinstall Microsoft Visual Studio 10.
the other way is to recompile your programs under the new package!
I'm relatively new at drivers with WDK and Visual Studio.
When I compile project in debug mode I get no warnings or errors and project compiles and runs fine. However, when I compile in release mode, compilation stops and I get an error stating that a warning was found and is being treated as an error. The details of this are dumped into a log file found at the project root dir.
What I would like to do is have the compiler in debug mode be as strict as the release mode compiler. Currently they are both at default. The release mode seems stricter. I am using VS 2010 and WDK. I'm not sure how to do this. It would be ideal if this setting was at the VS level and not at a per project level.
Also, It would be great if the warnings would show up in VS IDE instead of a log file.
Visual Studio has different configuration setting for debug and release mode.
Check whether do you have relevant configuration in project > project properties -> linker etc......
If there is mismatch between debug and release mode configuration then change it. This should work
--Ali Chachar
--Pakistan
There are code differences in the debug and release compilation that may lead to warnings unrelated to strictness of the compiler. Most noticeable is in the logs; in the release version KdPrint/KdPrintEx calls will be discarded. There is a good chance that some of your function input parameters are used for printing only and in case it's being omitted you'll end up with unused parameter warnings - this is the most frequent difference in debug vs. release compilations.
Even if you have a VS2010 solution, your driver isn't being compiled with the VS compiler but rather with the WDK compiler so VS settings are irrelevant here. You can migrate your solution to VS2012 which have driver support integrated.
I am building MFC application which uses other c++ library.I am using vs 2008 and compiled all the library project in vs 2008.
It is compiling well in debug mode but failed to run in Debug Unicode mode,Release,Release Unicode mode.
I found in the net that VS 2008SP1 is required to be installed but how come it is compiling in debug mode.
Please suggest how to overcome this problem.
If compiling a solution with multiple projects you should compile all projects with the same compiler (version) to be sure it works.
I once got the same error message like you. If I remember correctly the problem occured because link time code generation was used. My solution was to rebuild all, another solution might have been disabling link time code generation.
In Microsoft terminology, P1 is the parser (front-end), and P2 is the code generator (back-end). With link-time code generation (LTGC) enabled, the result of P1 is stored in a file and P2 is performed later at link time.
If you downgraded your compiler, you should do a full rebuild, otherwise the link step will try to use the incompatible P1 output, which will trigger that error.
If you upgraded the compiler, Visual Studio automatically does a full rebuild, so this should never happen (if it does anyway, just perform a full rebuild).
I had this problem just with other numbers as well using Visual studio 2015.
The problem was in one of the libraries that I linked to my project was build using VS2015 Update 3. The solution that worked for me - update Visual Studio to 2015 Update 3.
In my case, I just installed Microsoft Visual Studio 2008 Service Pack 1 (Installer) which resolved the problem. Service Pack can be downloaded from following link:
https://www.microsoft.com/en-us/download/confirmation.aspx?id=10986
I downloaded zlib from their website and I have the link warning from the title. I also compiled zlib and still have same warning. Do you know how may I fix this? I don't like warning of any kind in my projects:)
I use Visual Studio 2010.
Apparently the compiler used to generate the .lib import for the DLL isn't entirely compatible with Visual Studio:
I thought MinGW can be a one-stop shop
that'll do what's needed, and we won't
need anymore the awkward two-tool
combination that we used to use around
zlib-1.2.3. It seems we need another,
even more awkward two-tool combination
now.
Cosmin Truta built a new version using Visual studio. It should fix the warnings.