Building custom DLL for Ansys in win7 x64 with 0cx0000007b error

Building custom DLL for Ansys in win7 x64 with 0cx0000007b error

I need to build a custom external funciton .DLL in fortran 90 format for Anysis:

It worked for xp 32 with compaq visual fortran. Now with the system migrated to 64bit, the Ansys is all new 64 system too.

Firt is that IT can not make the Visual Studio 2005 work for win7. So i tried to use intel visual fortran 10.0 intel(R) 64 command line ifort to build the dll file: it completes compilation without errors.

However when i start the main program there is a 0cx0000007b error. I understand it is a /32/64 bit issue. Can you provide a way to debug this?

Steve,
see attached:
first i tried to use VS2005, which does not seem to start properly as in one of the screen shot, however it does build the .dll file for me; when using the .dll it gives 0cx000007b error....wait, now I have the following errors when i build a release instead of debug:

next i tried to build the dll in intel(64) command line with: ifort /dll user_define.f90. The build is again compeleted w/o errors but gives the same 07b error when starts the main program. used dumpbin command to check the dll file gives the following results:
Dump of file user_force.dll

Attachments:

I use Ansys v14.0 and it seems they have used ifort 11.1 to build this ansys version. In the help it says: "Microsoft Visual Studio 2008 SP1 or .NET Framework 3.5 SP1 SDK and Intel Fortran 11.1" are required for a windows custom build (cp. Programmers's Manual, chapter II, 1.10 ff.). I'm not sure whether ifort 10.0 is compatible to build a custom ansys executable/ DLL, but this depends on your ansys version?? So, you should know which versions are on your machine.

What do you mean "when i start the main program"? Your custom ansys.exe?
edit: OK I've seem you start AQWA and not ansys itself. But there must also be some more info in the aqwa docu.

Ansys v14 needs: "All ANSYS, Inc. products are built and tested using the Visual Studio 2008 SP1 (including the MS C++ compiler) and Intel FORTRAN 11.1 compilers. Compilers are required only if you will be using User Programmable Features or other customization options."

In your second post in this thread, there is mention of "DllMainCRTStartup@12". That is a telltale sign that you are (perhaps unknowingly) mixing up 32-bit and 64-bit objects and DLLs. With few exceptions, a 64 bit application will load 64-bit DLLs, and similarly for the 32 bit world.

JOhannes,
Yes i am using Ansys AQWA software version14 64bit.
In terms of the compiler version, I used compaq visual fortran 6.6? (rather old) to build the same DLL file that worked for AQWA v12 on a x86 win xp machine. So i guess an older version compiler should work to build a DLL for softwares built with later compiler versions.
Thank for your the input!

In your second post in this thread, there is mention of "DllMainCRTStartup@12". That is a telltale sign that you are (perhaps unknowingly) mixing up 32-bit and 64-bit objects and DLLs. With few exceptions, a 64 bit application will load 64-bit DLLs, and similarly for the 32 bit world.

This is what i think i am getting into. The question is how I can debug this?

Object 32/64-bit mismatch, can this happen, if there is only one file (user_define.f90)?

[/quote]

Certainly, since the .OBJ file that results from compiling that single file has almost always to be linked with the Fortran and C runtime libraries to produce an EXE or DLL. All the objects being linked must be of the same bit-ness.

In order to run VS2005 under Windows 7, 2 patch updates from Microsoft are required: SP1 and the Vista/Win7 update, which must be applied in order. This will work with all the ifort versions discussed here, up through 12.1. VS2005 support was dropped when VS2012 support was added, for ifort 13.0. As you found out, VS2005 on Win7 is a bit tricky to install correctly.
As others mentioned, Ansys instructions will tell you which ifort version has been tested with the Ansys version you have. Chances are the next major ifort version will still work (e.g. 12.1 when 11.1 is specified) but earlier ones will not.

@ mecej4: Thanks for the info. So, the mismatch maybe happens, when the user_define.o is linked against the (false) runtime libraries...

@TimP: Matching ifort version: If this would be the case, then John could not have worked successfully with Ansys v12 and old Compaq Fortran. If I remember correctly, they have used ifort (version?) for Ansys v12 before. But, maybe it was pure luck that it was working with Compaq (6.6)?

Is it possible to install the intel redestributables (in John's case for ifort 11.1) and link against this runtime libraries?

I used the walker to put all the Library on the search route, however there is still one warning message:
Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.
The libs involved are:
c:\windows\system32\IEFRAME.DLL
c:\windows\system32\SHLWAPI.DLL

Attachments:

Ignore those - they are harmless. But I do see an interesting thing - it is picking up MSVCR80.DLL from a mingw64 directory. That may be a problem. In DependencyWalker, do a FIle > Save. Attach a ZIP of the .dwi file it creates.

Steve,
the mingw64 folder was in the search directory when i tried to used gfortran but w/o success either.
now I moved all those DLL files otherwise not found according the depWalker to the Ansys folder as attached error message.
the same runtime error though.
Thanks for looking.

Attachments:

Interesting. According to the DWI, the copies of LIBIFCOREMD.DLL and LIBMMD.DLL in the c:\program files\ansys inc\v140\aqwa\bin\winx64\ folder are in fact x86 DLLs, where your DLL is x64. That could cause a problem. Did you copy those DLLs there?

Interesting. According to the DWI, the copies of LIBIFCOREMD.DLL and LIBMMD.DLL in the c:\program files\ansys inc\v140\aqwa\bin\winx64\ folder are in fact x86 DLLs, where your DLL is x64. That could cause a problem. Did you copy those DLLs there?

I don't remember i copied these (looks like have been there together with tens of other dlls). I now located the x64 version from other Ansys folders and replaced: the errors are gone as attached.
or: Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

Are you doing the DependencyWalker on the system that has the problem? All of the web references I can find on this issue say that it is a missing or wrong version of the Microsoft VC DLLs. I am concerned that you have private copies of these DLLs (such as MSVCR80.DLL.) What happens if you temporarily rename that to something else?

Are you doing the DependencyWalker on the system that has the problem? All of the web references I can find on this issue say that it is a missing or wrong version of the Microsoft VC DLLs. I am concerned that you have private copies of these DLLs (such as MSVCR80.DLL.) What happens if you temporarily rename that to something else?

Yes all on the same computer. the DLLs indeed can be seen in a lot of locations on my machine!
Looks like the machine has MSVC++ 2005 redistributable (X64) versions 8.0.56336 , 8.0.59192 and 8.0.61000 installed already

cited from programmers manual v14:
"Visual Studio 2008 is required for linking user programmable features on Windows platforms. However, if you do not have Visual Studio 2008, you can still link user programmable features into ANSYS by downloading Microsoft's .NET Framework 3.5 SP1 SDK from the following location:http://www.microsoft.com/downloads/details.aspx?familyid=C17BA869-9671-4...

After installing this SDK, you should be able to use any of the linking procedure described above. Before starting any of the linking procedures, make sure you open the Windows SDK CMD shell by picking Start > All Programs >Microsoft Windows SDK v7.0 > CMD Shell."

If you link from this .net 3.5 sdk CMD shell, aren't the environmental variables are set to the correct DLLs? But if I use the .net CMD shell and not the ifort CMD shell, how can I be sure that the correct intel fortran runtime DLLs are used. Can't you use ifort from a normal CMD shell?

In the attachment I put a comparision of the path environment from different shell types. The Visual studio x64 CMD shell contains also the intel redist x64 path, but mpirt e.g. in the VS CMD shell points to 32bit version??

Kind regards,
Johannes

Attachments:

Steve,
Another problem with my VS2005 is that when i try to open the previous Compaq Visual Fortran project xxxx.dsw. The ms VS says:
"The project file 'xxxx.dsp' has been corrupted and cannot be opened. "

does this error message somewhat correlate with the above DLL build problem?

I can't think of any possible correlation. I have seen occasional reports from customers of this error, but when they send me the CVF project it always converts fine for me, so I don't know what the issue is there. The only exception is that if you don't have Visual C++ (as you would not if you are using the VS Shell), then CVF project conversion is not available.

I finally got the relevant personal in Ansys to help me: They told me the user defined .DLL needs to be in 32bit format.
The error is still there though when i use ia-32 compiler:
check the DLLs with dwalker for the Dll file I built: user_force.dll VS. dll file comes with the system that works: user_force_v12.dll:
The lib msvcr80.dll for the working user function is from the folder c:\windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.6195_none_d09154e044272b9a\MSVCR80.DLL. I have to copy this file to the project folder without being able to include this into the visual fortran search path...

Attachments:

updates: it's working!
First the user defined DLL needs to be 32bit%*(%^((. Then use vs2005 work with IVF to generate a release version of userFile.DLL which automatically pick the MSVCR80.DLL in the following directory:

For some must be simple reason i could not make the vs2005 to build anything in the /release or /debug folder except the log file BuildLog.htm (any one?); I thought using command line compiler would be neat for this small code apparently I was wrong!@

Thanks for all your helps!

Attachments:

I having exactly same problem as you did. Could you kindly explain me how to buid the .dll file . I have tried to follow your last post but could not get it work. I have visual sutdio 2012 and intel visual fortran composer , the latest versions.

the dlls I checked through 'dependency walker' shows that the file that I generate is not linking to MSVCRT90.dll.