Runtime Application configuration is incorrect

[dan_hensley]

Hi,

I have Fortran code compiled into a DLL that I call from another DLL. It works fine on my system, but when I take the DLLs to another system, I get the dreaded Application Configuration error. On the target system I have installed the redistributables for vs2005, vs2005sp1, vs2008, vs2008sp1, vs2010, and Fortran XE. None of these has fixed the issue, so I am at a complete loss as to what to try next.

I am using VS2008sp1, and the target system is 32bit. I have confirmed that my DLL works fine when I comment out the call to the Fortran subroutine that I am calling from that DLL. So it seems that the Fortran DLL is the culprit. I have viewed it with depends.exe and cannot see what it is missing.

Any ideas?

Thanks,
Dan

[Steven_L_Intel1]

The problem is the Visual C++ redistributables. You may not have the right version loaded on the target system. Use Dependency Walker on the target system to identify the culprit. This particular obscure message indicates that the DLL version called for in the manifest is not installed on the system. Intel Fortran doesn't use shared assemblies, so its DLLs are unaffected by this.

[Arjen_Markus]

Dependency Walker does not always get you the answers - when the information on the dependent DLLs is contained in an embedded manifest for instance. But a few days ago Isolved a very similar problem for a system running MS Server 2008. See http://www.hdfgroup.org/HDF5/release/known_problems/index.html -
installing the .NET 3.5 Service Pack 1 solved the issue we had with loading the HDF5 DLLs on that particular
system. The softwarein questiondoesn't involveanything vis-a-vis .NET, apparently the service pack installs just the right DLLs that were missing on that particular system/OS.

Regards,

Arjen

[dan_hensley]

Thanks for the help. Unfortunately, it appears that I already have .Net 3.5 sp1 installed, so that isn't it.

Here's what I have so far:

These work:

My DLL compiled previously with VS2005, linked to Fortran DLL compiled with Intel Fortran 9.1.

My DLL compiled currently with VS2008, Fortran subroutine call commented out.

This does not work:

My DLL compiled currently with VS2008, linked to Fortran DLL compiled with Intel Fortran XE.

I have checked the Dependency Walker, and it does not provide any useful information. It says that it cannot find MSVCR80.DLL and MSVCP80.DLL, even though these are installed on the target system. But it gives the same error on my development system, and all of the above combinations work there. On the target system I have copied the newest version of the MSVC DLLs into the working directory, which causes the Dependency Walker not to complain, but does not fix the issue.

I'm really pulling my hair out on this one. Clearly there is a problem with the DLL compiled with Fortran XE, but I simply cannot figure out what the issue is. One interesting thing I noted is that depends shows that it is picking up LIBIFCOREMD.DLL that ships with the EXE calling my DLL (which is version 9.1), even though I have installed the XE redist, and have the XE version of this library first in my path. So either depends is lying, or Fortran XE does not use manifests, or something else weird is going on. I did manually overwrite the EXE version of LIBIFCOREMD and LIBMMD with the XE version, but that didn't fix the problem either.

[Steven_L_Intel1]

.NET 3.5 has nothing to do with this. You need the VC2005 Redistributables. You may want to be sure that you are using a current version of Dependency Walker that knows about shares assemblies.

[Arjen_Markus]

I know it is a merely a side effect. If there is a newer version of Dependency Walker I definitely need to get that. (In our case the library requires the VC2008 redistributables. And maybe I ought to look into this issue
again, but I was glad to have found "a" solution, after weeks of struggling with it)

Regards,

Arjen

[dan_hensley]

In my case I have the VC2005, VC2005sp1, VC2008, and VC2008sp1 redistributables all installed. None of them made a difference. What else am I missing?

I'm using depends from VS2005. Is that new enough to show shared assemblies?

[Steven_L_Intel1]

I would get one from dependencywalker.com

This error is Windows' obscure way of saying that your program has a manifest entry referring to a shared assembly, but it can't find the right version of the assembly.

[dan_hensley]

Ok, I have Dependency Walker 2.2. It says that my Fortran DLL is missing MSVCR90.DLL, even though I have 4 copies of this on my system. I copied each of these 4 into a directory where it could find it, and that did not fix the problem. My C++ DLL was missing MSVCR80.DLL, of which I have 5 copies on my system. None of those fixed the issue either.

How can I use DW to identify which version of what stupid DLL it can't seem to find?

I'm about to give up on the Fortran XE compiler.

[dan_hensley]

Tried the 11.1 compiler; same issue. I know it absolutely is the Fortran DLL causing this, because I tried loading it directly from the EXE and it gave the error. When I load my C++ DLL with the Fortran call commented out, it loads fine.

[IanH]

There's more to a C runtime library DLL version than just the filename, and the symptoms you are describing indicate this might be where things are going wrong. Note also that the redistributables can get changed at a finer resolution than service packs (they can be updated on your development machine by the normal windows update process and this caught some out a couple of years ago - there were posts on this forum). The best way to avoid this sort of drama is to always redistribute the C run time library that your application was built against, with your application. There are merge modules provided for this or you can use the vcredist_*.exe thing. I've found the merge modules work quite well.

Assuming that you have a non-express edition of Visual Studio - you can open the EXE/DLL (just using File > Open) and browse it's resources, examine its manifest and get the minimum DLL version that is required. More info here. You can get the version information of a DLL from the file properties in windows explorer (but if things are setup appropriately that DLL should be stashed away in the side-by-side store somewhere anyway (note I'm not sure that just blindly copying the DLL's into the DLL search path works when manifests are involved - but if it does I can imagine that being a recipe for confusion) or dependency walker.

There's plenty more stuff accessible through the related links for the VS2008SP1 redistributable download.

I'm curious how your C++ DLL ended up with a different DLL version requirement than the Fortran DLL. Are you building them on the same machine? Do you have the runtime library settings the same for both DLLs?

IanH


(As a barely related post-script I just noticed that there's a merge module in the redist part of the XE folder structure. If this is what I think it is then that is a welcome addition.)

[dan_hensley]

Thanks for the detailed input. I didn't realize VS could open the EXE/DLL and show the manifest.

I'm building both DLLs on the same machine. Not sure about the runtime settings. Something must be different, but I can't see what.

I'm compiling the Fortran DLL in VS2008sp1 Pro with the Fortran overlay. When I look into this DLL, I see that it wants version 21022.8 of the MSVCR DLL. I have that exact version installed on my target system in the C:\WINDOWS\WinSxS directory tree. I also see that the manifest lists both the release and debug versions of this file. I only have the release version installed on the target system. So maybe the FORTRAN DLL wants the debug version? The Dependency Walker doesn't indicate this though.

The C++ DLL is actually a Matlab MEX file, created by using Matlab's compile scripts. So I don't know exactly what it does with the manifests (it's not quite the same as what Fortran does, because when I open the DLL it doesn't show it the same way). But if I search this DLL for a manifest, I find one that also only points to the exact same version of MSVCR as the Fortran DLL, but just the release one.

Note that I have already installed the version of the VS2008SP1 redistributable from the link you provided on the target system.

I also installed the Fortran XE redistributable on the target machine (should be the same as the merge module shipped with the compiler, but I downloaded it from Intel's site).

[IanH]

I don't think you should see both debug and release DLL's being referenced. Make sure that you don't have a debug static lib or similar being pulled into your dll.

[Steven_L_Intel1]

The Fortran DLL does not depend on any MSVC DLLs. You can see this by opening LIBIFCOREMD.DLL with Dependency Walker.

Be sure that you have not created a dependency on debug MSVC DLLs, which are not redistributable.

[dan_hensley]

At long last I found the solution. I had forgotten that the Fortran DLL linked in a static library with C and C++ functions. It turns out that this library was being compiled with /MD, and that was the problem. I changed it to compile with /MT. Ugh. Though I don't know why it worked on my development system with /MD, but not my target systems. There were no debug flags set anywhere in the static C library configuration at all.