I'm trying to investigate why would my app, written in VC 2008, crash on bare Windows XP with c0000005. It works great on any windows vista and 7. On XP it would crash with no additional info. Below are the details and the result of a few days worth of my headaches, eliminating one reason after another. Here's the details:
I have Win7 ultimate with XP Mode with iexplore 6 and presumably no patches whatsoever.
I install my program and nothing else, since it is supposed to be install-and-run thing with no additional packages needed.
My app has compiled-in VC2008 runtime (using /MT, as opposed to /MD compiler switch)
I'm using firebird embedded, which needs VC2005 (edited, i wrote VC2008 before) libs for itself anyway, so i put them in my app's working dir
when i install VC++ 2008 on this XP Mode machine, it doesn't crash anymore, so debugging this way is impossible
I've narrowed this error's occurence down to the VC2005 runtime - right after i install it my app stops crashing. But i don't know what could be using it's components. When running the release version under VC2008 IDE, nothing shows any vc2005 libs being loaded (weird, if i say so myself).
My app's linker's dependencies lists these (i added only the first two, the rest was there courtesy of VisualStudio): jpeg.lib, gdiplus.lib, kernel32.lib, user32.lib, gdi32.lib, winspool.lib, comdlg32.lib, advapi32.lib, shell32.lib, ole32.lib, oleaut32.lib, uuid.lib, odbc32.lib, odbccp32.lib, comctl32.lib, %(AdditionalDependencies)
I am also using IBPP firebird interface, which loads these dynamically, so they are present in my app's dir (they need msvc?80.dlls):
fbembed.dll, ib_util.dll, icudt30.dll, icuin30.dll, icuuc30.dll, msvcp80.dll, msvcr80.dll
Please advise why would vc2005 runtime be a remedy for my app to not crash on a bare Win XP. Or how could i debug that one without installing vc 2008 on target machine. I'm starting to blame windows xp's components. Ultimately i want my app to not require any additional packages, such as VC2008 or 2005, especially when no component of my app requires the latter.
I am also using IBPP firebird interface ... msvcp80.dll, msvcr80.dll
The answer is in your question, these DLLs are VS2005 runtime support DLLs. They cannot be stored in your exe directory, they must be registered in the side-by-side cache. This does not typically cause an AV, but it isn't impossible if the code doesn't check the return value of LoadLibrary(). You can download an installer for them from Microsoft. It doesn't otherwise have anything to do with Windows XP, you just happened to try to run this program on machines that already had the DLLs installed. Very common on a dev machine for example.
If you don't want a dependency on them then you'll have to rebuild those DLLs that require it. Which is a good idea, having a dependency on more than one version of the CRT is pretty unhealthy.
If you are wondering why you are having to deal with this: it was Microsoft's attempt to put DLL Hell in the developer's lap instead of the user's. They've since withdrawn this, VS2010 again makes it a user problem. That was a pretty big party in Bangalore, I'd imagine.
Related
I have spent an incredible amount of time getting our product to run properly on customers' machines after we moved to Visual Studio 2015, and I still have one problem left to solve. The problem is that I can't get any of the C++ 2015 redistributables installers to work on 32-bit Windows 7 when it hasn't been patched (Windows Update).
The full story:
We upgraded all projects in the solution from VS 2013 to VS2015 and .NET 4.5.2, which also forced us to upgrade to "Microsoft Visual C++ 2015 Redistributable (x86/64) - 14.0.23506/23026)". We've done this kind of upgrade many times before, from VS2010 and up, and it never failed before.
23506 (for short) are the DLLs that accompany VS2015. We always found it easier to just XCOPY the DLLs into our installation folder. For some reason that doesn't work with the DLLs from VS2015 (23506). The program can't find them even when placed in the same folder as the executables. Why not?
Then I ran vcredist_xXX.exe that accompany VS2015, and the program runs fine.
But I want to XCOPY, so I discovered the download of 23026 from Microsoft, but there are no DLLs in there - only vc_redist.xXX.exe. Still, I copied the DLLs from somewhere in Windows - the paths to each DLL is listed in the registry. By the way, there are two extra DLLs installed that are not present in the folders in VS2015. "mfc140.dll" and "mfcm140.dll". Why?
But XCOPYing 23026 didn't work either, not even with the two extra DLLs. Running vc_redist.xXX.exe from 23026 worked fine.
Ok, problem solved, I thought. Using vc_redist.xXX.exe instead of XCOPYing. But no.
The final problem is that vc_redist.x86.exe (from 23026) and vcredist_x86.exe (from 23506) both fail when run on a 32-bit Windows 7 machine that hasn't been patched (Windows Update) at all after installation. For reasons I won't go into, that's the kind of machines we have to install our product on - unpatched 32-bit Windows 7 - no way around it. (The problem maybe exists on 64-bit unpatched Windows also, but I haven't got the time to find out.)
How do I get around this?
I am trying to link the C++ runtime statically and drop the DLLs alltogether, but it seems impossible when you have native C++ with C++ wrappers in a .NET project. This issue has already been reported by others, so no need to go into it here.
I have tried searching for DLLs to download, or a way to extract DLLs from the installer. Anyway, as mentioned above, I already tried just copying them from somewhere below C:\Windows. Doesn't work, so I doubt I can get some DLLs that will work. But again, why? If somebody can help me figure out this, it could be the perfect solution for our problem.
I have been thinking about finding the exact Windows patch(es) needed to get that installer - vc_redist.x86.exe - to work on those crappy machines. If it's just one or a handful of KBs that doesn't destabilize these machines, that would perhaps be acceptable.
A possibility that definitely should work is to downgrade the C++ projects to VS2013, which doesn't have this problem. I am really fed up of us always having to keep two versions of Visual Studio on our developer machines as a workaround for some silly problem, but if there's no other way, then so be it, even in 2016.
Found a quick and simple workaround. Turns out we only need to change the setting "Platform Toolset" to "Visual Studio 2013 (v120)" in all the C++ projects, in order to build with the good old DLLs that still work with XCOPY deployment. I was under the impression this setting would not go together with .NET 4.5.2, which we need, but it does. VS2013 will have to be installed along with VS2015, but we can live with that.
As stated, this is a workaround. It doesn't solve the actual problem stated in the title. But since I actually asked for a way around the problem, I'll close the issue with this answer.
As for the actual problem, if anyone is interested: I found some blog entries on the Visual C++ Team Blog - "Introducing the Universal CRT" and "The Great C Runtime (CRT) Refactoring". Where that leads, I'm not sure.
I was able to get this resolved on my local PC by following the updated step 6 on that article: https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/
Once you copy the 20 or so DLLS folder it still didn't work for me, I had to grab the ucrtbase.dll and ucrtbased.dll along with all the usual 140 (mfc, mfcm,vcruntime, msvcp) from my SysWOW64 folder and finally i'm able to launch this on a windows 7 pc without requiring to install any patches!
My Unmanaged VC++ MFC (No .NET used, No CLR support, Use MFC in shared DLL) application trying to deploy with visual C++ runtime files as private assemblies.
It is properly running on windows 7 fresh installed computer.
But I gives “This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.” error in fresh installed wondows XP sp3 computer.
I checked in application event logs. But there also no more details, just showing the same error.
Then I read these threads and surf around the internet.
Thread - 1
Thread - 2
Article -1
But couldn't find any solution clue or trouble shooting method. so here looking for some assist.
The easiest way to test is to install depends on the computer. Most likely, your application is built to use a later version of C++ runtime libraries, e.g. <assemblyIdentity type='win32' name='Microsoft.VC80.CRT' version='8.0.50727.4053' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18e3b' />, but on the XP system it is an older version.
You would need to check what version of the runtime library used by analysing the program's manifest. Then check what depends is showing.
If the required version of runtime is missing, distribute it with the program's install.
On the side note, you could consider switching to the static link. The size of the binaries will be bigger, but these type of problems will be gone
We're planning moving from Visual Studio 2005 to Visual Studio 2012 (Visual-C++-11).
(We would very much like to skip 2010 if we can help it, since the newer version is already there and offers a better C++ experience.)
But we've hit a little roadblock:
Our build servers still run Windows 2003r2 (all inside dedicated virtual machines), and due to messy tool support/issues, we're in no position to upgrade the build servers to a newer OS.
Developers mostly have switched to Windows7 by now, so moving the remaining Windows XP developer boxes shouldn't pose a problem.
Since VS2012 only runs on Win7 we are wondering whether we can leverage it's tools (C++ compiler, C#) and still do a full equivalent build on the W2k3 build server - after all, we don't really need a VS GUI there, just build C++ and C# projects from VS2012.
What are our options?
Will the SDK (7.1? 8?) compilers + msbuild command line get me anywhere?
In Project Property Pages, there an option "Platform Toolset" that allow you to choose compatibility of your project. So, you can work in VS2012, but built it with "VS2008 compiler"
Here is what we do:
Use CMake
CMake allows you to create build systems for your operating system. Thus we are able to use the same code within VS2005, VS2010 and Eclipse, XCode etc.
You could do something similar: Install VS2005 on your old machines and let CMake create the projects for you from the sources. On your newer machines you can use CMake to generate VS2012 Solutions (I don't know if they have 2012 support yet, because we don't use 2012 yet too).
A big pro here is: If you plan to migrate to any other IDE or even Linux you just can re-run CMake and get your source code within these environment easily compilable.
A big con: You have to start reading about CMake and create CMakeLists.txt for all your projects (might be a lot of work depending on the amount of projects, amount of source code files within each project, specific compiler options, linker options etc.)
Our build servers still run Windows 2003r2 (all inside dedicated
virtual machines), and due to messy tool support/issues, we're in no
position to upgrade the build servers to a newer OS.
Well. Not much came out of this question. We recently re-evaluated this issue, and I see two options (I haven't tried any yet):
Just do a full VS installation on a supported OS (Win7), zip up the whole VS+WinSDK directories (as well as the neccesary runtme DLLs that live somewhere under %WINDR%), and try if you can get that thing working on an XP based OS. Might work. Not a great idea if you ask me.
Split up the build process to distribute the build across several OS, so that we can work with tools that are only supported on one of them. -- This actually sounds more complicated than it'll be. We already run our build spread over several Jenkins jobs, so I should be able to get that to work. (And all build nodes are already VMs anyway, so adding more VMs isn't that much of an issue.)
When I attempt to install Microsoft Visual C++ 2010 Redistributable I get the following error.
I have an updated msvcrt.dll to replace the current one with but every time I delete/replace the old dll windows re adds the old one into the system32 folder again.
It would be useful to know the OS version you are using. Could be Windows 2000 or XP (my guess from the screenshot, but could be over RDP as well).
When msvcrt.dll became a first-class citizen (i.e. a system DLL) some time during the lifetime of XP, some changes were also made to it. Incompatible changes, I should add. Example: if you built a program against the VS CRT in former times (e.g. using the WDK/DDK) you could rely on the fact that it works starting with the least common denominator of existing msvcrt.dll versions. However, at some point MS decided that programs built to target, say, XP could rely on the new functionality that was snuck into newer versions of msvcrt.dll. Hence the observed incompatibility.
One way to make it work could be to add a file msvcrt.dll.local in the same folder or - failing that - to create a shim that enforced your intended behavior. See here.
Got similar error. Fixed it by restarting the server before the install.
This is the error Dependency Walker gives me on an executable that I am building with VC++ 2005 Express Edition. When trying to run the .exe, I get:
This application has failed to start because the application configuration
is incorrect. Reinstalling the application may fix this problem.
(I am new to the manifest/SxS/etc. way of doing things post VC++ 2003.)
EDIT:
I am running on the same machine I am building the .exe with. In Event Viewer, I have the unhelpful:
Faulting application blah.exe, version 0.0.0.0, faulting module blah.exe,
version 0.0.0.0, fault address 0x004239b0.
Open the properties sheet for your project, go to the Configuration Properties -> C/C++ -> Code Generation page, and change the Runtime Library selection to /MT or /MTd so that your project does not use the DLL runtime libraries.
The C/C++ DLL runtimes used by VS2003 and up are not automatically distributed with the latest version of the OS and are a real pain to install and get working without this kind of problem. statically link the c-runtime and just avoid the total mess that is manifests and version specific runtime dlls.
I've had this problem. The solution has two steps:
1. Compile your program in "Release" mode instead of "Debug" mode (there's usually a combo-box in the toolbar)
2. Download from Microsoft their Redistributable Package of runtime components. Make sure to download the x86 edition for 32-bit computers and the x64 edition for 64-bit computers/OSes. Install this package on the target computer, and your application should run fine
P.S. This is a SxS thing
P.P.S. Alternatively, use a different compiler (like GCC, for example with Dev-Cpp) to compile your program's source, and your headaches will disappear.
Sorry to bump an old question, but I was able to get around this exact issue and thought I'd post a solution in case someone else needs it...
Even after installing Microsoft's redistributable DLLs I was getting this error, the fix was to copy the
C:\Program Files\Microsoft Visual Studio 8\VC\redist\x86\Microsoft.VC80.CRT
folder into the application's directory on the target PC. After that, no more problems.
BTW, the DLL that was giving me issues was a 3rd-party DLL that had never had problems before on over 100 other computers... go figure.
Run Event Viewer: it'll have more information.
Probably you've attempted to run your program on a machine that doesn't have the VC redistributables installed, or you're attempting to run a debug build on a machine that doesn't have Visual Studio installed (the debug libraries aren't redistributable).
I have had the same issue with VS 2008-built debug binaries on other winxp sp3 machines.
I first tried installing the client machine with vc redist package,as it seemed sensible. Annoyingly, it didn't work.
I tried copying all the dependent dlls to the application's directory - still didn't work
After being struck over this issue for hours, I found that the latest VS builds require manifests and policies to link with the dlls. After copying them into their respective "C:\WINDOWS\WinSxS\" folders, I got it working.
The problem was caused due to the fact that the vc redist package did not install debug versions of dlls, they somehow thought its up to the programmer to figure out.