If I built my app against D3DX June2007_d3dx9_34 and the target system has a newer version Nov2007_d3dx9_36 should that be a problem?
I distribute D3DX DLLs using MS' redist-installer tool but I noticed one one 'clean' PC (no D3DX previously installed) I got an error about missing D3DX DLL. Before trying to figure out if the installer itself is not working, I wondered if maybe supplying a too-new version of the DLL is the problem - will the app be looking for a DLL with the exact name?
D3DX libraries are not backwards-compatible, and the API may change between versions. So the target system must have the same version of D3DX that you build your application with - a newer version won't work.
If you use Dependency Walker on your application, it should show you that there's a dependency on a DLL with the exact version number.
The redistributable in the DirectX SDK includes the whole history of the D3DX dlls. Installing the latest version of the DirectX redistributable should have your system end up with every version of these dlls. It is possible and allowed for applications to only install the files they need by deleting cab files out of the redistributable's directory structure, in order to reduce the size of the redistributable components, and this is how you can end up with having 43 of the dll but not 37 for instance.
If you remove the dependency of D3DX and D3DCOMPILER dll's from your application you can ensure the application will work as the d3d9 d3d10 and d3d11 core dlls are version-agnostic and are also tied to the windows service pack releases (i.e. D3D11 for Vista comes from Vista SP2 or Win7 stock installs for example).
Another possible way to remove the dependency and let the app startup is to make the dll a delay load module, so it is only loaded when needed (such as compiling shaders on a development environment). As long as you are sure the shaders exist on end-user machines properly it won't need to compile shaders and won't crash. Calling LoadLibrary and invoking the functions manually would be a safer choice with a way better error message of your choosing, but is a lot more work.
Related
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
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.
I'm using third party libraries that I obtained well before KB2465367 came out. My development computer has been updated with KB2465367 so all the binaries I generate seem to now be dependant on 8.0.50727.5592 of the CRT (the 2465367 version of the CRT).
Now, when I want to deploy this application I'm using the 8.0 CRT merge module (also updated by 2465367). This installs 8.0.50727.5592 versions of MSVC libraries (like msvcrt80.dll).
But, when I run my application on a machine that's never had the VC runtime installed, it complains about "This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem." I've traced this back to a system entry in the event log: "Generate Activation Context failed for C:\Program Files\MyCompany\MyApp.exe. Reference error message: The operation completed successfully." under the source "SideBySide".
Of course, this update has basically meant I'm dead in the water.
How do I proceed from here? Do my clients need to install 8.0.50608.0 version of the CRT after installing my application because the 3rd party libraries need 8.0.50608.0 and the MSM I used didn't include it?
In my circumstance I'm using How To: Install the Visual C++ Redistributable with your installer which only describes using a single MSM. It's recommended that a policy MSM also be used to redirect any DLLs dependant on older versions of the runtime.
See also http://lynk.at/jlqsKx
This is the same thing happened when MS rolled out KB971090.
A simple solution is to remove the KB2465367.
You can reference more information about KB971090 and KB2465367 at here.
There is an uninitialized data bug in the patch that can cause DLL load failure.
Your installation program have to use two merge modules:
The runtime libraries, and
The policy file which redirects all older versions of the runtime to the new version.
The redistributable package vcredist_xxx.exe installs both the latest version of the libraries and the policy files.
You cannot assume the VC libraries are available on users machines, therefore you always have to install them. Otherwise your application won't run.
My application which is built on VC++ 2008 , when run on a freshly installed XP shows an error that asks dotnet.fx to be installed. And also i faced similar problem when i tried to run it on another xp system after i installed that, it started to run.
Is there any way that i can make my application independent of all these additional installs ?
Are you sure you didn't compile managed C++ (targetting CLR) instead of real C++. In the former case dotnetfx is the .NET runtime you absolutely need and not some optional addon. In the latter case you need only the VC_redist in either x86 or 64bit variant. That installs the C and C++ dlls only. These are side-by-side assemblies and must match the version you compiled for.
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.