Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
28955 Discussions

Library options for using IFORT dlls in VB.net

avinashs
New Contributor I
500 Views

I have a release version of a DLL for use in VB.net created using IFORT 2024.2 (2021.12.0 64-bit) with the default calling convention and default libraries option (Multithreaded). However, this DLL fails in VB.net with a crash. If the libraries option is changed to Debug Multithreaded (/libs:static /threads /dbglibs), it seems to work. Is this a standard requirement with VB.net now? Incidentally, I also noted that IFX dlls fail in VB.net with any option.

The dll source file had the correct directive !DEC$ ATTRIBUTES DLLEXPORT, ALIAS : 'mydll' :: mydll. The VB.net also has the correct interface to call the DLL. The project has worked for several years with other versions of MSVSC and IFORT.

0 Kudos
9 Replies
Steve_Lionel
Honored Contributor III
421 Views

For a DLL called by a non-Fortran language, with no other Fortran involved, Multithreaded (not Multithread DLL) is the best choice. If your code fails, it isn't due to the library choice, but rather some other error in your code. Do not select Debug libraries unless you are actively debugging. That the debug libraries appear to "fix" the problem most likely indicates you are accessing uninitialized data, as the debug libraries change how heap allocations are done, changing memory contents.

0 Kudos
avinashs
New Contributor I
393 Views

@Steve_Lionel Thanks for the invaluable insight - it is indeed a memory corruption issue that seems to occur only in the release version without /dbglibs and apparently disappears after /dbglibs is added. Upon further investigation, I found that the global array in the module on the VB side is "corrupted" after the first call to the Fortran dll - even the exception handling cannot catch the error. The solution was to allocate/deallocate the array in VB before/after the call to the dll.

As a matter of note, this code has been thoroughly tested for some 10 years on the Fortran side - it still runs without memory corruption in Fortran. Until 2024, the 64-bit Fortran dll was created for VB.net using the /iface:cvf calling convention with STDCALL, REFERENCE attributes. VB.net could handle the Fortran calls without error. Starting with 2024.2, /iface:cvf has stopped working with VB.net and the standard convention results in memory corruption.

0 Kudos
Steve_Lionel
Honored Contributor III
379 Views

Okay.... First of all, /iface:cvf doesn't do much for x64 other than change where character arguments appear in the argument list. STDCALL, REFERENCE has no effect on x64 other than downcasing external names. I updated my VS to version 17.12.4, and am using Intel Fortran 2025.0.4 (for ifx), 2024.2.1 for ifort. I built and ran the VB-Calls-Fortran sample, and it worked, using ifort in 32 and 64-bit, and ifx in 64-bit. 

I'm not seeing any behavior change. I think you have some more debugging to do - in particular, find out exactly where and when that VB table gets corrupted.  Try setting a data watchpoint on it, if you can. My guess, based on what you've said before, is that you are accessing an array out-of-bounds in the Fortran code.

0 Kudos
avinashs
New Contributor I
280 Views

@Steve_Lionel Thanks for your invaluable insight on this issue. Upon further debugging of the overall project, I could trace the point of the memory corruption to the dll call within VB.net with the following diagnostic error messages from the .dmp file:

Inner Exception 1:
AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt.

Besides the dll file, the following files are listed in the tree of files at the point of exception:

C:\Program Files (x86)\Common Files\Intel\Shared Libraries\bin\libifcoremd.dll
C:\Program Files (x86)\Common Files\Intel\Shared Libraries\bin\libifcoremdd.dll

The dll was built with the default External Procedures and Multithreaded libraries option using IFORT 2024.2. Changing to IFX with the same options also leads to the same error.

When the dll is built with the options Debug Multithread DLL (/libs:dll /threads /dbglibs) for Libraries/Runtime Library in the Release version and the same default External Procedures, the above crash does not occur.

I will also note that the Fortran code was independently tested as a console application for all ranges of inputs and has no memory issues and completes all calculations normally as a standalone application - there is no array out-of-bounds possibility, or it would have been caught in the standalone debugging.

0 Kudos
Steve_Lionel
Honored Contributor III
274 Views

You should not have both libifcoremd.dll and libifcoremdd.dll loaded. How did that happen? There's something you have not told us. One or the other of these is OK, not both. (libifcoremdd.dll only if you are actively debugging.) Do you have a second Fortran DLL being used?

0 Kudos
avinashs
New Contributor I
249 Views

Apologies - I inadvertently typed the wrong name since the .dmp debugger does not allow copying from the interface. The second file is C:\Program Files (x86)\Common Files\Intel\Shared Libraries\bin\libmmd.dll. Attaching the screenshot of the files for reference.

0 Kudos
Steve_Lionel
Honored Contributor III
210 Views

OK - that's the math library.

What I would do next is build a debug version of the program but select the non-debug libraries - this won't affect your debugging. Assuming you have the VB and Fortran parts in the same solution, enable native code debugging in the Debug property page of the VB project. Set a breakpoint at the entry to your Fortran routine, then run. When the Fortran routine is entered, it should hit the breakpoint and stop. At this point, look to see if the VB table is still correct. You can probably set a data breakpoint on that location so that the debugger will alert you when it changes. Step through the Fortran code until the table changes incorrectly. This will help you focus on the cause.

If this doesn't work, I'd make a copy of the project and then selectively remove (or comment out) sections of the Fortran code from the end of the routine back towards the front, and see which change causes the behavior to disappear.

0 Kudos
avinashs
New Contributor I
182 Views

Thanks, greatly appreciated. I tested 3 cases below.

Method 1. I built the debug version of the Fortran dll as advised with the following options. When called from VB.net there were no errors or crash dumps.

/nologo /debug:full /Od /warn:interfaces /real-size:64 /module:"x64\Debug\\" /object:"x64\Debug\\" /Fd"x64\Debug\vc170.pdb" /assume:norealloc_lhs /real-size:64 /fpconstant /fp:consistent /traceback /check:bounds /check:stack /libs:static /threads /Qdiag-disable:10448 /c

2. Next I built the release version of the Fortran dll with the following options. When called from VB.net there was a crash and the dump file indicated the same dlls as before. The actual location of the crash was after freeing the memory allocated to an array created initially in VB, passed to the Fortran dll, and then on return from the dll deallocated using Erase. The memory corruption took place probably at the call itself.

/nologo /Od /warn:shape /warn:interfaces /module:"x64\Release\\" /object:"x64\Release\\" /Fd"x64\Release\vc170.pdb" /assume:norealloc_lhs /real-size:64 /fpconstant /fp:consistent /libs:static /threads /Qdiag-disable:10448 /c

3. Finally rebuilt the release version again with Debug Multithreaded as below and once again there was no crash.

/nologo /Od /warn:shape /warn:interfaces /module:"x64\Release\\" /object:"x64\Release\\" /Fd"x64\Release\vc170.pdb" /assume:norealloc_lhs /real-size:64 /fpconstant /fp:consistent /libs:static /threads /dbglibs /c

4. This type of crash is even occuring with other Fortran dlls (not just the one I thought was a problem). So it appears to be related to the build options for any Fortran dll called by VB.net. There are no issues with Fortran itself or the individual codes.

5. I also observe that the .dmp file indicates Module Version libifcoremd.dll and libmmd.dll as 2024.1.0.0 but my compiler is C:\Program Files (x86)\Intel\oneAPI\compiler\2024.2\bin. There is a libifcoremd.dll and libmmd.dll in this directory as well in addition to one in the Common Files.

0 Kudos
Steve_Lionel
Honored Contributor III
107 Views

Again, I doubt the library configuration is responsible for the error. Anything that changes layout in memory can reveal or hide data corruption issues. You have not yet, from what you wrote, identified the place in the Fortran code, if any, that triggers the error. I suggested above how to do that.

Perhaps you can reduce to a minimal but reproducible example that you can attach here? (ZIP of solution with VB and Fortran parts.) It is also not out of the question that the error is on the VB side.

0 Kudos
Reply