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

[John_S_12]

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?

Thanks.

[Steven_L_Intel1]

Can you be more specific about the error you're getting? Screenshot?

[John_S_12]

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: Error 3 error LNK2001: unresolved external symbol __DllMainCRTStartup@12 LINK Error 4 fatal error LNK1120: 1 unresolved externals x64\Release\user_force.dll 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 File Type: DLL Image has the following dependencies: libifcoremd.dll libmmd.dll MSVCR80.dll KERNEL32.dll ..... File Type: DLL FILE HEADER VALUES 8664 machine (x64) 5 number of sections 507EC918 time date stamp Wed Oct 17 10:04:56 2012 0 file pointer to symbol table 0 number of symbols F0 size of optional header 2022 characteristics Executable Application can handle large (>2GB) addresses DLL OPTIONAL HEADER VALUES 20B magic # (PE32+) 8.00 linker version 1C00 size of code E00 size of initial thanks

[Johannes_Rieke]

Hi John, as Steve said, some more information would be helpful. 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. edit2: // Installation and Licensing Documentation // Windows Installation Guide // 2. Platform Details :: 0 If you copy this into your path of ansys help , you should find "Compiler Requirements for Windows System". 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." Kind regards, Johannes

[Steven_L_Intel1]

Ok. The link error is because something is requiring or defining a STDCALL name for the DLL entry point, but x64 doesn't use that. You may be linking to the wrong libraries. The 007b error is probably from a DLL mismatch - you may not have the proper MSVC shared assemblies installed. You might find that analyzing your DLL with DependencyWalker is helpful. The message you get about VS2005 on Windows 7 is correct. It will work if you follow the instructions.

[mecej4]

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.

[John_S_12]

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!

Johannes wrote:

Hi John,

as Steve said, some more information would be helpful.

[John_S_12]

mecej4 wrote:

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?

[John_S_12]

Steve Lionel (Intel) wrote:

Ok. The link error is because something is requiring or defining a STDCALL name for the DLL entry point, but x64 doesn't use that. You may be linking to the wrong libraries.

The 007b error is probably from a DLL mismatch - you may not have the proper MSVC shared assemblies installed. You might find that analyzing your DLL with DependencyWalker is helpful.

The message you get about VS2005 on Windows 7 is correct. It will work if you follow the instructions.

Steve, A quick check on installed programs by IT: Microsoft visual C++ 2005 redistributable Microsoft visual C++ 2005 redistributable(X64) Microsoft visual C++ 2008 redistributable X64 Microsoft visual C++ 2008 redistributable X86 Microsoft visual C++ 2010 redistributable X86....!

[Steven_L_Intel1]

You need to run Dependency Walker (http://dependencywalker.com/) on the DLL to see what it needs.

[Johannes_Rieke]

Hi John, just a guess: Have you checked, whether the "ansysdef.inc" and/or other includes have changed between v12 and v14 and have you referenced these v14 includes? Object 32/64-bit mismatch, can this happen, if there is only one file (user_define.f90)? Kind regards, Johannes

[mecej4]

Johannes wrote

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

[/quote wrote:
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.

[TimP]

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.

[Johannes_Rieke]

@ 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? Kind regards, Johannes

[TimP]

I don't see how any recent Ansys could have worked with CVF. If Ansys is linked in the usual way with /MT, conflicts would arise in attempting to link against the redistributable .dlls.

[John_S_12]

Steve Lionel (Intel) wrote:

You need to run Dependency Walker (http://dependencywalker.com/) on the DLL to see what it needs.

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

[Steven_L_Intel1]

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.

[John_S_12]

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.

[Steven_L_Intel1]

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?

[John_S_12]

Steve Lionel (Intel) wrote:

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. I still have 07b error though.

[John_S_12]

TimP (Intel) wrote:

I don't see how any recent Ansys could have worked with CVF.
If Ansys is linked in the usual way with /MT, conflicts would arise in attempting to link against the redistributable .dlls.

absolutely possible, I 'll get touch with Ansys, the turnaround time is expected Loooooong.