A Runtime Error R6034 in Fortran 9.0 library libmmd.dll

[hmeng]

In our codes Intel Fortran 9.0 library namelibmmd.dll is used. We observe a Runtime Error R6034 in some situations. I profile it with DependecyWalk and found:

libmmd.dll searches and loads the Microsoft Visual C++ runtime library at runtime. The search list is MSVCR80.dll, MSVCR71.dll and MSVCR70.dll.

The found runtime library depends on the Windows envrionment. The found one could be located in the same directory as our codes or system32 directory or in the directory specified in the env(PATH) variable.

If MSVCR80.dll of some specific versions is found there will be the runtime error when the codes in MSVCR80.dll tries to call a function named "IsProcessorFeaturePresent" in KERNEL32.DLL.

If no MSVCR80.dll is found in Windows it tries to find MSVCR71.dll.If MSVCR71.dll is found no such runtime error occurs.

My question is which version of MSVCR80.dll matches Intel Fortran 9.0 library?

Another question is whether Fortran library 9.0 can be integrated into the application built with Visual Stusion 2008?

The followings are part of the profile result:

LoadLibraryA("MSVCR80.DLL") called from "LIBMMD.DLL" at address 0x00CB7A8E.

Loaded "MSVCR80.DLL" at address 0x074D0000. Successfully hooked module.

DllMain(0x074D0000, DLL_PROCESS_ATTACH, 0x00000000) in "MSVCR80.DLL" called.

GetProcAddress(0x7C800000 [KERNEL32.DLL], "IsProcessorFeaturePresent") called from "MSVCR80.DLL" at address 0x074EA9AE and returned 0x7C80AE3A.

GetProcAddress(0x77C10000 [MSVCRT.DLL], "_set_error_mode") called from "MSVCR80.DLL" at address 0x074D4447 and returned 0x77C35348.

GetProcAddress(0x77C10000 [MSVCRT.DLL], "?set_terminate@@YAP6AXXZP6AXXZ@Z") called from "MSVCR80.DLL" at address 0x074D4463 and returned 0x77C22567.

GetProcAddress(0x77C10000 [MSVCRT.DLL], "_get_terminate") called from "MSVCR80.DLL" at address 0x074D447F and returned NULL. Error: The specified procedure could not be found (127).

GetProcAddress(0x7C800000 [KERNEL32.DLL], "FindActCtxSectionStringW") called from "MSVCR80.DLL" at address 0x074D1DBE and returned 0x7C82FD68.

LoadLibraryA("USER32.DLL") called from "MSVCR80.DLL" at address 0x074D96ED.

LoadLibraryA("USER32.DLL") returned 0x7E410000.

GetProcAddress(0x7E410000 [USER32.DLL], "MessageBoxA") called from "MSVCR80.DLL" at address 0x074D9705 and returned 0x7E45058A.

GetProcAddress(0x7E410000 [USER32.DLL], "GetActiveWindow") called from "MSVCR80.DLL" at address 0x074D9722 and returned 0x7E41D658.

[lhli]

The key problem for us is that,
* it is not an easy time issue for us to migrate to Fortran 11.1 soon. This will cost us several months before our next delivery to customers.
* what we need to find is a solutin how to proceeed with Fortran 11.0 vs. 2008,or Fortran 9.0 vs. 2003.

how about that if RIGHT libmmd.dll file is got without improper references? as stated by Steve that the file we have sounds differnt.


Thanks
Longhui

[Wendy_Doerner__Intel]

Longhui,

What exact version of 9.0 are you using? I can get you libmmd.dll file from that version to see if it resolves your problems. To find out the version:

Start -> All Programs => Intel Software Development Tools => Intel Fortran Compiler X.X.XXX => Intel Visual Fortran Documentation

Where X.X.XXX is the version number of the compiler.

------

Wendy

Attaching or including files in a post

[lhli]

the two versions we used as below.

* Fortran 9.0.024 - VS2003
libmmd.dll searches for msvcr80.dll first where problems occur
conclusions have been made that msvcr80.dll is from vs2005 and can't be supported in Fortran 9.0
if msvcr71.dll is found by libmmd.dll, the problem disappears
* Fortran 11.1.054 - VS2008
libmmd.dll searches for msvcr100.dll first where potential risk exists
conclusions have been made that msvcr100.dll is from vs2010 and can't be supported in Fortran11.1
currentlymsvcr90.dll is found and no problem is reported yet.


thanks
Longhui

[lhli]

It is double checked that Fortran 11.1.054 is currently used in our tool, not the stated Fortrann11.0. Sorry for confusions - but the problems are completely the same listed above