Building in VS2015 gives SideBySide error - c++

I have an x86 C++ app that works in VS2013 and I'm upgrading to VS2015. The build and link work fine but when I run I get an error:
Unable to start program. This application has failed to start because
the application configuration is incorrect. Review the manifest file
for possible errors. Reinstalling the application may fix this
problem. For more details, please see the application event log.
The application event log shows:
Activation context generation failed for "MyApp.exe".
Dependent Assembly Microsoft.VC80.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762" could not be found.
Please use sxstrace.exe for detailed diagnosis.
So I ran sxstrace and got:
=================
Begin Activation Context Generation.
Input Parameter:
Flags = 0
ProcessorArchitecture = Wow32
CultureFallBacks = en-US;en
ManifestPath = MyApp.exe
AssemblyDirectory = MyApp\Debug\
Application Config File =
-----------------
INFO: Parsing Manifest File MyApp.exe.
INFO: Manifest Definition Identity is (null).
INFO: Reference: Microsoft.VC80.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762"
INFO: Resolving reference Microsoft.VC80.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762".
INFO: Resolving reference for ProcessorArchitecture WOW64.
INFO: Resolving reference for culture Neutral.
INFO: Applying Binding Policy.
INFO: No publisher policy found.
INFO: No binding policy redirect found.
INFO: Begin assembly probing.
INFO: Did not find the assembly in WinSxS.
INFO: Attempt to probe manifest at C:\Windows\assembly\GAC_32\Microsoft.VC80.DebugCRT\8.0.50727.762__1fc8b3b9a1e18e3b\Microsoft.VC80.DebugCRT.DLL.
INFO: Did not find manifest for culture Neutral.
INFO: End assembly probing.
INFO: Resolving reference for ProcessorArchitecture x86.
INFO: Resolving reference for culture Neutral.
INFO: Applying Binding Policy.
INFO: No publisher policy found.
INFO: No binding policy redirect found.
INFO: Begin assembly probing.
INFO: Did not find the assembly in WinSxS.
INFO: Attempt to probe manifest at C:\Windows\assembly\GAC_32\Microsoft.VC80.DebugCRT\8.0.50727.762__1fc8b3b9a1e18e3b\Microsoft.VC80.DebugCRT.DLL.
INFO: Attempt to probe manifest at MyApp\Debug\Microsoft.VC80.DebugCRT.DLL.
INFO: Attempt to probe manifest at MyApp\Debug\Microsoft.VC80.DebugCRT.MANIFEST.
INFO: Attempt to probe manifest at MyApp\Debug\Microsoft.VC80.DebugCRT\Microsoft.VC80.DebugCRT.DLL.
INFO: Attempt to probe manifest at MyApp\Debug\Microsoft.VC80.DebugCRT\Microsoft.VC80.DebugCRT.MANIFEST.
INFO: Did not find manifest for culture Neutral.
INFO: End assembly probing.
ERROR: Cannot resolve reference Microsoft.VC80.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762".
ERROR: Activation Context generation failed.
End Activation Context Generation.
I'm not sure how this helps and I still don't understand why I'm getting this error if I built the app from scratch in VS2015. I've tried installing Microsoft Visual C++ 2005 SP1 Redistributable Package (x86) which corresponds to the version 8.0.50727.762 but it hasn't helped.
A lot of the older posts on this subject (e.g. Why installing vcredist_x86.exe doesn't fix SideBySide error when I develop an EXE on one machine and run it on another one?) mention checking the .manifest file generated by the build but I can't find one. Does VS2015 no longer generate them?

One of your used library is build against the Debug Runtime of Vs2005 (Microsoft.VC80.DebugCRT). Those debug files are NOT part of the normal Visual C++ 2005 SP1 Redistributable Package.
Do a trial & error search to figure out which library and get the release version which uses the release Dlls which are part of the Redistributable Package.

What type of 3d party libraries are you using and how are they being linked? For example are you using DLLs, Libs or both? If you are using statically linked 3rd party libraries, then they must be compiled and built using the same version of VS you are using with the same code generation flags. You may also want to visit the developer's websites of those libraries and look to see if they have a newer version and one that is already compiled with your current version of VS. If they only have 2010, 12 or 13 they should work but you will have to open them in 2015 and build them out yourself
For example; I use libpng, openal, ogg-vorbis, glm & others, For all of the 3rd party libraries that my applications depend on I have created a file directory where they are stored and I created environment variables on my main machine for an easier linking process. For all of these libraries except for glm since glm is a headers only library I had to create different environment variables for each version of visual studio I'm using; for example OGG-Vorbis are 2 different libraries used for doing audio; so I would have OGG_SDK_2010, VORBIS_SDK_2010 ... OGG_SDK_2015, VORBIS_SDK_2015 where these libraries being the newest version from their websites are loaded and built out in both release & debug versions of each version of Visual Studio that I may be using.
Before I redid my pc I did have VS2008, 2010, 2012, 2013 and 2015; now that I reinstalled my OS I currently only have VS2013 & 2015. So any of my older programs from VS2008, VS2010 & VS2012 I will have to first port them to 2013 and fix any dependencies and take care of any deprecation. Once that process is completed I'll then be able to port them over to 2015.
Now, from my experience on porting one of my programs over to 2015 from 2013 there was a little bit of a process that had to be done, however, I do not recall off of the top of my head exactly what had to be done. I do know that it did take a little bit of time reading different threads and trial and error to get everything to work properly.
It may also be that you could be using a library that has not been updated and that there is currently no more work or support being done for it that the library dependency that you may have may be considered deprecated in itself and if that is the case, then you may have to do some research to find an alternative library that will fit your needs. Once you find the appropriately library, then it is a matter of stripping out all of the old method calls and replacing them with the equivalent calls to the newer library. However in some cases this may involve a complete rewrite of your existing program.
For example; I use OpenGL and when I first started to learn it I was using version 1.0 where everything that was used to do render calls was all done on the CPU. Now that I'm using Modern OpenGL and using GLSL Shaders on the GPU and have successfully created a 3D Graphics Shader Rendering Engine; the transition from OpenGL 1.0 to 4.5 was quite a bit to take in and the difference between the two versions of the same Library or API by OpenGL was a challenge. Porting from an older version of a compiler to a newer version is sometimes fairly easy like porting from 2012 to 2013, there wasn't that much of an overhead change, but sometimes porting from an old version to a newer version can be tedious such as going from 2005 to 2015.
Also do not forget to check these 3rd party libraries props files to make sure they are pointing to the correct version of VS.

#magicandre1981's answer is correct but didn't give any clues how to help track it down. I eventually noticed that when Visual Studio links my app it prints out:
glew32sd.lib(glew.obj) : warning LNK4099: PDB 'vc80.pdb' was not found with 'glew32sd.lib(glew.obj)' or at 'MyApp\Debug\vc80.pdb'; linking object as if no debug info
I rebuilt glew32sd.lib from the glew source code and my problem was fixed.

Related

Application not working on Windows XP, despite using XP toolset. Troubleshoting ideas needed

I'm developing a dll library. My solution (cmake core, Visual Studio sln generated) consists of a few static .lib projects that are used to build this dll and the dll project itself. There are also some 3rd party dependencies (boost, nana and some more). I'm using hell dependencies manager (https://rilis.io/projects/hell) to download my dependencies. I know it's not widely used, but to put it short it is just a simple tool that after reading config file downloads dependencies using git, generates projects using cmake and compiles using the requested generator.
I need my dll to support Windows XP. I develop on Windows 10 machine and I copy the dll to Windows XP SP3 machine, which is where I run the tests. However my dll fails to load on windows xp. LoadLibrary returns nullptr. The name and architecture are matching. I'm not getting any system error, just the pointer returned is nullptr. I used to have system errors but I eliminated them by switching to functions that were present in Windows XP API. I enabled Snapping and ran profiling in DependencyWalker. I got errors about
api-ms-win-core-synch-*
api-ms-win-core-fibers-*
api-ms-win-core-localization-*
failing to load (probably also through dynamic loading during dll initialization. I found out its Windows XP compatibility issue. I figured out that I need to build my module using v140_xp toolset. Cmake provides options to specify toolset and hell is supposed to propagate this setting to build other dependencies using provided toolset. To the best of my knowledge about hell, cmake and visual studio that should be the case. However my dll still fails to load and DependencyWalker + snapping still show the same failed load attempts.
I want to know whether I missed something in my approach or if the toolset setting is not propagated to all static libraries. The second one could cause one or more of dependencies to be compiled with non xp toolset, resulting in linking with non-xp cruntime (I'm linking statically with crt - MTd/MT) and failed dependency.
I need some ideas that would help me troubleshot this issue. Anyone knows how I can check which obj or lib that my dll consists of could add dependency to non-xp API? Or maybe someone has an idea what I could have missed when building my module?
Thank you for your time!

LoadLibrary() fails when called from plugin but works in test program

I'm working on a plugin for Autodesk 3ds Max 2017. As per Max's documentation, the plugin is compiled inside VS 2017 using the VS 2015 toolset against the 10.0.10586.0 Windows SDK.
When the plugin is loaded by 3ds Max, it in turn programmatically loads a number of DLLs using LoadLibrary(). Until recently, that was working fine on my machine. It's also still working fine on other developers' machines.
What happens now on my machine is that LoadLibrary() fails and returns a null handle. The error code is 127, i.e. "The specified procedure could not be found."
I am quite sure that DLLs that the one I'm trying to load to depends on are available on the system. I have triple-checked with both Dependency Walker and its modern incarnation, Dependencies.
In fact, the following program run inside Visual Studio 2017 (also using VS 2015 toolset against the 10.0.10586.0 Windows SDK) is able to load that DLL just fine:
#include <Windows.h>
int main(int argc, char* argv[])
{
auto result = LoadLibrary(L"C:\\path\\to\\appleseed.dll");
}
To investigate this problem further, I've turned to GFlags which is part of the Debugging Tools for Windows 10.
Here is the full debugger output emitted when calling LoadLibrary(): https://gist.github.com/dictoon/b3f9f7cb52d2d81078965133d5035a03
I believe (but I'm not 100% sure) that the relevant error from this output is the following:
5f4c:54bc # 131346281 - LdrpReportError - ERROR: Locating export "StackWalkEx" for DLL "C:\Windows\SYSTEM32\dbgeng.dll" failed with status: 0xc0000139.
Exception thrown at 0x00007FFCC6A9EAA8 (ntdll.dll) in 3dsmax.exe: 0xC0000139: Entry Point Not Found.
5f4c:54bc # 131346281 - LdrpGenericExceptionFilter - ERROR: Function LdrpSnapModule raised exception 0xc0000139
Exception record: .exr 000000000223F030
Context record: .cxr 000000000223EB40
dbgeng.dll appears to be Visual Studio's debugger so I thought that maybe the error would only occur when 3ds Max was run inside Visual Studio with the debugger attached but that's not the case: the DLL also fails to load when 3ds Max is launched on its own.
Inspecting C:\Windows\SYSTEM32\dbgeng.dll with Dependencies reveals that it does export a StackWalkEx() symbol:
Edit 1: #RbMm commented that StackWalkEx() is actually not exported by dbgeng.dll but by dbghelp.dll as the screenshot below shows:
Edit 2: With a release build of the DLL I'm trying to load, everything works fine too. Looking at the debugger's output, no attempt is made at loading dbgeng.dll or finding StackWalkEx().
Edit 3: It appears that the debug version of the library I'm trying to load does have a dependency toward dbgeng.dll:
But a small test DLL written from scratch doesn't!
Edit 4: I now suspect that Boost 1.69 (on which the DLL I'm trying to load depends) to which we recently switched (from Boost 1.55) has introduced a dependency on dbgeng.dll via its Stacktrace library introduced in Boost 1.65.
The problem is an older version of dbghelp.dll which ships with 3ds Max and conflicts with the newer version the appleseed.dll has been linked with during the debug build.
The call to the function StackWalkEx, which failed, has a dependency on dbghelp.dll
StackWalkEx function
The solution is to inactivate or replace the older, incompatible version of dbghelp.dll inside the Max root directory.
StackWalkEx is part of DbgHelp and used by System Services. It may have been updated recently during a Windows update causing the breaking change.

How do I check which module causes LINK1112 error?

Is there a way to tell the full path of every DLL used while compiling?
I am trying to make a DLL with easy-to-Marshal functions to communicate between a C# application and a filesystem Minifilter (currently using the Minispy sample to check if everything is running smoothly).
It was successfully compiling and running when using "Win32" as my target platform in Visual Studio 2013, but when printing out pointers with printf("%p",...); their length was only 8 characters where they should have been 16 (my computer is 64 bits) which threw off future pointer juggling.
My active solution platform has always been x64 for the other projects. Unfortunately, changing the platform in the Configuration Manager to x64 for the DLL generates the following error during compilation:
Error 1 error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
I checked online and this seems to be a configuration problem of some part of the solution, but all my projects should be compiling in x64. Cleaning and rebuilding to remove old files had no effect either.
I have used dumpbin.exe to check the Machine types of the DLLs I think my library is linking to and everything seems in order. I got these by checking the linker command line options in my project's Properties, but their names don't show where they are read from ( ex: kernel32.lib; user32.lib; gdi32.lib; fltLib.lib ... ). Since I'm still having this problem, I think it might be linking to the wrong (32bit) versions of the same DLLs.
Is there a way to tell the full path of every DLL used while compiling? Or better yet, is there a way to tell which DLL specifically is causing the LINK1112 error?
I have used the /VERBOSE:LIB command and removed the /NOLOGO option but the output is underwhelming, stopping right after the command to be executed with no other information.
I should have answered this when I solved it a couple months ago but I forgot I posted it here. But I'll try to recall what I did.
In the end, if I remember correctly, I'm pretty sure that what saved me was using Dependency Walker on the successfully compiled (x86) library. I used it before, but I was running it in the wrong mode (x64 or x86) and using the correct one revealed the missing modules for the x64 architecture.

Visual Studio "Application failed to start because the application configuration is incorrect" error

I obtained some code from a friend, developed on the same system (Windows 7) and same Visual Studio Ultimate 2010, with all the libraries relatively mapped.
The code builds, but when trying to run it I get the error:
Application failed to start because the application configuration is incorrect"
Running Dependency Walker on the executable showed that msvcr90.dll, ieshishm.dll, ieframe.dll and freeglut.dll could not be found. I copied these to the execs directory and that solved these problems. However, two issues remain:
Error: The Side-by-Side configuration information for "e:\projects\darwin\code\debug\GLTEMPLATE.EXE" contains errors. 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 (14001).
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.
With SHLWAPI.DLL and IEFRAME.DLL modules being marked red (assuming error message relates to these two, how do I fix that?).
Also, the sxstrace gave following result:
Begin Activation Context Generation.
Input Parameter:
Flags = 0
ProcessorArchitecture = x86
CultureFallBacks = en-US;en
ManifestPath = E:\Projects\Darwin\Code\Debug\GLTemplate.exe
AssemblyDirectory = E:\Projects\Darwin\Code\Debug\
Application Config File =
INFO: Parsing Manifest File E:\Projects\Darwin\Code\Debug\GLTemplate.exe.
INFO: Manifest Definition Identity is (null).
INFO: Reference: Microsoft.VC90.DebugCRT(...)
INFO: Resolving reference Microsoft.VC90.DebugCRT
INFO: Resolving reference for ProcessorArchitecture x86.
INFO: Resolving reference for culture Neutral.
INFO: Applying Binding Policy.
INFO: No publisher policy found.
INFO: No binding policy redirect found.
INFO: Begin assembly probing.
INFO: Did not find the assembly in WinSxS.
INFO: Attempt to probe manifest at C:\Windows\assembly\GAC_32\Microsoft.VC90.DebugCRT\9.0.21022.8__1fc8b3b9a1e18e3b\Microsoft.VC90.DebugCRT.DLL.
INFO: Attempt to probe manifest at E:\Projects\Darwin\Code\Debug\Microsoft.VC90.DebugCRT.DLL.
INFO: Attempt to probe manifest at E:\Projects\Darwin\Code\Debug\Microsoft.VC90.DebugCRT.MANIFEST.
INFO: Attempt to probe manifest at E:\Projects\Darwin\Code\Debug\Microsoft.VC90.DebugCRT\Microsoft.VC90.DebugCRT.DLL.
INFO: Attempt to probe manifest at E:\Projects\Darwin\Code\Debug\Microsoft.VC90.DebugCRT\Microsoft.VC90.DebugCRT.MANIFEST.
INFO: Did not find manifest for culture Neutral.
INFO: End assembly probing.
ERROR: Cannot resolve reference Microsoft.VC90.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="9.0.21022.8".
ERROR: Activation Context generation failed.
End Activation Context Generation.
(...)
And some more similar.
I also tried changing the runtime library as suggested on other related posts from multi-threaded debug DLL (/MDd) into multi-threaded debug (/MTd). However, I get the:
MSVCRTD.lib(MSVCR100D.dll) : error LNK2005: _printf already defined in LIBCMTD.lib(printf.obj)
And some five more similar. Excluding LIBCMTD.lib allows me to build. However, I still cannot run the application. I get the same error as in the very beginning.
What is going wrong and how do I fix this?
No other related posts gave me the answer so far.
Your project uses one or more libraries that were built with Visual Studio 2008, the previous version of Visual Studio. They require the C runtime library for that version to be available; that's why it is complaining about msvcr90.dll. You've got Visual Studio 2010; you only have msvcr100.dll installed on your machine.
Just copying msvcr90.dll isn't going to work; that DLL needs to be installed in the Windows side-by-side cache. You can get an installer from Microsoft or from your friend. That's, however, not the true fix; you still have a problem with your application depending on two versions of the CRT. Very unhealthy, that can cause very-hard-to-diagnose crashes and memory leaks. You need to get the libraries rebuilt with Visual Studio 2010. That's where my advice fizzles out; I can't guess what those libraries are from your question.
"msvcr90" <- I'm pretty sure that's not the 2010 version; not the release anyway. My bet is that somewhere in the mix you're linking to something built against an older runtime but not old enough to be installed with win7.
You don't want to switch to the static runtime while linking to 3rd party DLL's, or your own DLL's.
It is possible the problem in manifest.
I set Configuration Properties/Linker/Manifest file/ Generate manifes==No
and program began starting.

Problem with Visual C++ program-- can't find the Debug CRT

I have a friend who's taking over a Visual C++ project from me and is having trouble running it. It's a graphics application and it uses the Qt GUI library. The reason I mention this is because of the error below.
He can build and link the program using Visual Studio 2010, but when he runs it this message comes up in the event viewer:
Activation context generation failed
for
"D:\Test\Qt\4.2.2\bin\QtGuid4.dll".
Dependent Assembly
Microsoft.VC80.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",
type="win32", version="8.0.50608.0"
could not be found. Please use
sxstrace.exe for detailed diagnosis.
When we do as the message asks and run sxstrace.exe, here's what we see:
Begin Activation Context Generation.
Input Parameter: Flags = 0
ProcessorArchitecture = Wow32
CultureFallBacks = en-US;en
ManifestPath =
D:\Test\Qt\4.2.2\bin\QtGuid4.dll
AssemblyDirectory =
D:\Test\Qt\4.2.2\bin\
--------------- INFO: Parsing Manifest File D:\Test\Qt\4.2.2\bin\QtGuid4.dll.
INFO: Manifest Definition Identity is
(null). INFO: Reference:
Microsoft.VC80.DebugCRT,processorArchitecture="x86"type="win32",version="8.0.50608.0"
INFO: Resolving reference
Microsoft.VC80.DebugCRT,processorArchitecture="x86""win32",version="8.0.50608.0".
INFO: Resolving reference for
ProcessorArchitecture WOW64. INFO:
Resolving reference for culture
Neutral. INFO: Applying Binding
Policy.
INFO: No publisher policy found.
INFO: No binding policy redirect found. INFO: Begin assembly
probing.
INFO: Did not find the assembly in WinSxS.
INFO: Attempt to probe manifest at C:\Windows\assembly\GAC_32\Microsoft.VC80.DebugCRT\8.0.50608.0__1fc8b3b9a1e18e3b\Microsoft.VC80.DebugCRT.DLL.
INFO: Did not find manifest for culture Neutral. INFO: End assembly
probing. INFO: Resolving reference
for ProcessorArchitecture x86. INFO:
Resolving reference for culture
Neutral. INFO: Applying Binding
Policy.
INFO: No publisher policy found.
INFO: No binding policy redirect found. INFO: Begin assembly
probing.
INFO: Did not find the assembly in WinSxS.
INFO: Attempt to probe manifest at C:\Windows\assembly\GAC_32\Microsoft.VC80.DebugCRT\8.0.50608.0__1fc8b3b9a1e18e3b\Microsoft.VC80.DebugCRT.DLL.
INFO: Attempt to probe manifest at D:\Test\Qt\4.2.2\bin\Microsoft.VC80.DebugCRT.DLL.
INFO: Attempt to probe manifest at D:\Test\Qt\4.2.2\bin\Microsoft.VC80.DebugCRT.MANIFEST.
INFO: Attempt to probe manifest at D:\Test\Qt\4.2.2\bin\Microsoft.VC80.DebugCRT\Microsoft.VC80.DebugCRT.DLL.
INFO: Attempt to probe manifest at D:\Test\Qt\4.2.2\bin\Microsoft.VC80.DebugCRT\Microsoft.VC80.DebugCRT.MANIFEST.
INFO: Did not find manifest for culture Neutral. INFO: End assembly
probing. ERROR: Cannot resolve
reference
Microsoft.VC80.DebugCRT,processorArchitecture="x86", publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50608.0".
Sorry for the length of that message, but I thought it might jog some memories. Is this a case of his not having the Visual C++ 2005 (I believe that's where the VC80 comes from) C runtime libraries installed? If so, can he download the VC++ redistribution package and install it, and will all be well then? Or is this a completely different problem?
If your friend doesn't have VS2005 installed, he will not have the debug runtime libraries for it. They're not part of the redistributable runtimes and IIRC, Microsoft prohibits you from distributing them yourself so you have to have VS2005 installed in order to get them.
I would suggest that he'd rebuild the affected library if possible; I vaguely recollect that there are a couple of articles out on the web on how to rebuilding the GPL QT using Visual Studio, which I believe is not officially supported.
Mixing C++ runtimes requires a lot of care and you can fall into a fairly nasty trap if you don't get it exactly right. If rebuilding all libraries with VS2010 is not an option, your friend will have to get hold of VS2005. It might be worth checking if MS still offers the Express Edition of VS2005 for download.
You might as well do below: LOL
If you are running your application on Windows 7 X64 mode which build in X64 target, you have to install the following X64 SP1 redistributable package
http://www.microsoft.com/download/en/details.aspx?id=2092
Note: The manifest file should change to processorArchitecture = X64 and type="win64"
If you are building your application with X86 (32 bit mode) which run on top of WOW64 layer you have to install X86 SP1 redistributable package
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=5582