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?

Thanks.

29 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

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

Steve - Intel Developer Support

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

Attachments: 

AttachmentSize
Download screenshoot.jpg21.02 KB
Download vs8.jpg48.76 KB

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

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 - Intel Developer Support

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!

[quote=Johannes]

Hi John,

as Steve said, some more information would be helpful.

Quote:

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?

Quote:

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....!

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

Steve - Intel Developer Support

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

[quote=Johannes wrote

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?

Kind regards,
Johannes

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.

Quote:

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

Attachments: 

AttachmentSize
Download dependencywalker.jpg259.65 KB

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 - Intel Developer Support

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: 

AttachmentSize
Download user-force.zip776.97 KB

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?

Steve - Intel Developer Support

Quote:

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.

Attachments: 

AttachmentSize
Download user-force.zip776.73 KB

Quote:

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.

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?

Try installing http://www.microsoft.com/en-us/download/details.aspx?id=18471 on the target system.

Steve - Intel Developer Support

Quote:

Steve Lionel (Intel) wrote:

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?

Try installing http://www.microsoft.com/en-us/download/details.aspx?id=18471 on the target system.

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

Hi all!

Sorry, that I'm asking all these newbie question, but I'm trying to learn for future task, where I will use Ansys custom builds also. Sorry John for using your thread for it.

Why stick to MSVC++ 2005 redistributable (X64)? Ansys programmers manual explicitly says: Use VS2008 or .NET 3.5 SP1 SDK as alternative.

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: 

AttachmentSize
Download cmd-shell-path.txt4.56 KB

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.

Steve - Intel Developer Support

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: 

AttachmentSize
Download drive-d.zip893.13 KB

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:

c:\windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.6195_none_d09154e044272b9a\MSVCR80.DLL

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: 

AttachmentSize
Download drive-d.zip893.13 KB

Hi John,

 

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.

 

Thanks in advance.

Leave a Comment

Please sign in to add a comment. Not a member? Join today