Debugging 64-bit application on 64-bit platform

[dannycat]

I am having trouble debugging my 64-bit application from within Visual Studio. The program has compiled and linked without a problem but when I try to run it I get a message "Application failed to intialise properly (0xc-015002). Click on OK to terminate". This also appeared when running the debug exe outside Visual Studio. In a previous post, with the help of Les Neilson,I established that a DLL file MSVCR90.DLL was missing and when I tried the release version everything was OK.

I have installed Visual Studio and Intel FORTRAN Compilers on our 64-bit computer. Should the MSVCR90.DLL be installed during this operation or do I have to obtain it from elesewhere?

Any helpwill, as usual, much appreciated.

[Steven_L_Intel1]

MSVCR90.DLL is automatically installed by Visual Studio - it gets put in a "side by side assembly" that is referenced when you build your application, unless you have disabled the use of manifests. Note that when building a debug configuration, you get the debug version of this DLL, MSVCR90D.DLL.

You should not have to do anything special here. Have you run Dependency Walker on your EXE to see if it has any complaints?

[dannycat]

Quoting - Steve Lionel (Intel)

MSVCR90.DLL is automatically installed by Visual Studio - it gets put in a "side by side assembly" that is referenced when you build your application, unless you have disabled the use of manifests. Note that when building a debug configuration, you get the debug version of this DLL, MSVCR90D.DLL.

You should not have to do anything special here. Have you run Dependency Walker on your EXE to see if it has any complaints?

Steve, I did disable manifests (moral being don't meddle with thingsyou know nothing about!). I will change settings and try again. What are manifests used for?

When I tried the Dependency walker only the MSVCR90D.DLL was flagged as missing/unresolved.

[Steven_L_Intel1]

Manifests are a way to indicate which particular version of a DLL is to be used and is intended to get away from "DLL Hell", where incompatible DLLs were found on PATH. Microsoft's own DLLs are all provided as "side by side assemblies" that are found only if manifests are used, which is why you're having the problem after disabling manifests.

[dannycat]

Steve, I've tried it now with manifects enabled but stillno joyl. The output from the dependency walker displays a message "The side by side configuration information "" contains errors." The culprit still seems to be MSVC90D.DLL which is listed as unresolved.

The release version which uses MSVC90.DLL works alright.

Is there a way to check if MSVC90D.DLL exists on the machine and if it does not do I need to reinstall Visual Studio in order to get hold of it?

[Steven_L_Intel1]

Is this the same system on which the application was built?

In Dependency Walker, right click on the entry for MSVC90D.DLL in the Module display and select Show Full Paths. You should get something that looks like this:

c:windowswinsxsamd64_microsoft.vc90.debugcrt_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_2a6dacffMSVCR90D.DLL

This shows you where Windows expects to find the DLL. It is not a simple matter of copying the DLL in there if that particular one is missing (note that this one is 9.0.30729.1). It could be a difference of Service Packs for VS2008 if you are building and debugging on different systems. If one system has SP1 installed and one doesn't, you could see this problem.

[dannycat]

Steve, I tried obtaining the full path and nothing appears next to the MSVCR90D.DLL entry. All other DLL file names do contain their respective directory paths though. It looks as though MSVCR90D.DLL is not installed. I am using Visual Studio 9.0.2.21022.8 RTM.

The MSVCR90D.DLLfile does appear in the Directory C:Program Files (x86)Microsoft Visual Studio 9.0VCredistDebug_NonRedistamd64Microsoft.VC90.DegbugCRT but it does not seem to be picking it up.

[Steven_L_Intel1]

If you don't see a full path, then whatever part of your application references MSVCR90D.DLL was built with manifests disabled. If you don't want to track this down, you could try setting the library type to Multithreaded DLL instead of Multithreaded Debug DLL.

[dannycat]

Quoting - Steve Lionel (Intel)

If you don't see a full path, then whatever part of your application references MSVCR90D.DLL was built with manifests disabled. If you don't want to track this down, you could try setting the library type to Multithreaded DLL instead of Multithreaded Debug DLL.

Steve, I checked if the manifest was being created and it appeared to be there. However I tried your idea of changing the library type and this at least enables the program to run in the debugger.Can any of the manifest files be interrogated to see what's going on?

No doubt there'll be more hurdles to overcome but at least I feel I'm a step nearer.

Thanks

[Steven_L_Intel1]

The debug libraries have no effect on your ability to debug. For Fortran, there is no difference. The MSVC debug libraries do some additional consistency checking for memory allocations and deallocations.

I still think you've got a no-manifest build in there somewhere.