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

FORTRAN DLL won't load in VS2019


I have used IVF and VS to make VB code that calls a FORTRAN DLL, for decades, all the way up to Win8.1.  I just got a new computer (with Win10) and installed IVF and VS2019 and now none of my solutions work anymore.  The VS2019 install is new as I used VS 2017 previously.  I assume that IVF hasn't changed much since then.  I load the solutions (VB and FORTRAN) clean, rebuild, and run.

In each and every case I get error "An attempt was made to load a program with an incorrect format. (Exception from HRESULT: 0x8007000B)"

I have changed nothing (to my knowledge) and I have tried so many things that I can't enumerate them all.

A web app (no FORTRAN) done on my old computer works fine, loads and runs and publishes just fine.  So it is clearly something to do with the FORTRAN DLLs.

Does anyone have some suggestions on how to resolve this?

0 Kudos
1 Solution
Black Belt Retired Employee

Going back to what I wrote earlier, you probably have a 32-bit VB calling a 64-bit DLL (or vice-versa.) I suggest, in the VB project, setting the CPU type to either 32 or 64 bit, matching that of the DLL.

The typical way of dealing with the path issue is to copy the DLL into the same folder as the VB executable.

View solution in original post

35 Replies
Black Belt Retired Employee

The usual cause of that error is trying to load a 64-bit DLL from a 32-bit VB. I assume you are seeing this error when the VB app runs. I just tried a mixed VB-Fortran project with VS2019 and the new oneAPI compiler, and it worked fine. Make sure you aren't building a "x64" configuration.


Thanks Steve

First let me say how much I appreciate your support of FORTRAN (my first programming language.)  I believe that your career goes all the way back to DEC.  Congratulations on a remarkable career.

I think that I worked through many of the problems that popped up when I moved computers and OS (8.1 to 10).  Most were due to defaults that caused problems, and most I was able to resolve.  But now I get one that I have never seen before and don't understand. 

I get no compile or link errors, but when I try to run within the debugger I get:

"Unable to start program XXX.exe.  Interop debugging is not supported."

Any ideas here?

And thanks again.




I am back to a similar problem.  When set to X64, the linker fails with "Error fatal error LNK1561: entry point must be defined LINK"


This is not a requirement in Win32!?


Can I just use an empty "Main" subroutine as an entry point?


So I either get a DLL than windows does not recognize or a link error that is entirely a new requirement.

Black Belt Retired Employee

A couple of things here. 

First, to debug a DLL project, where the executable isn't in the solution (Excel, for example), you need to put the path to the EXE in the DLL project's Debugging > Command property.

Second, when you have a managed code project (VB for example), you have to enable "native code debugging" in the managed code project. In a VB project, this is on the Debug property page.

I haven't seen the "interop debugging" message, but some web searches provide some interesting links: Mixed mode debugging for x64 processes is only supported when using Microsoft.NET Framework 4 or gre... , Debug in Mixed Mode - Visual Studio | Microsoft Docs

Does this help?


Thanks Steve,

I am not really a "beginner as the listing says.  I was forced to reapply, I guess my original account must have expired.

I gave up on trying to get a win32 app and switched to all x64.  But I still cannot compile and run the DLL.  The VB project and the FORTRAN DLL are both in the same solution and I know about "Native Debugging".

The problem that I get now is that the Linker says that I need an entry point for the DLL.  This was never the case in Win32 and I don't understand why it is in X64.

I tried creating a Main sub in the DLL, and claim it in the "Entry Point" of the compiler options, but no luck.  I tried to declare it with a Declare statement in VB as I do with all the other subs in the DLL.  But the linker errors with "Error fatal error LNK1221: a subsystem can't be inferred and must be defined."

These are all errors that I have never seen before.  No matter what "subsystem" I select I get errors.


Any help would be appreciated.


Honored Contributor II

Show the command line for the link. Is /DLL missing? You would need  /SUBSYSTEM:WINDOWS also. I would expect this is a settings error but I am guessing. 

Black Belt Retired Employee

It sounds to me as if your project is not a DLL project. Please attach a ZIP with the complete solution folder.

If you want a worked example, see the attached:

New Contributor III

Attached is a vs2017 which I hope would be useful.

Black Belt Retired Employee

Your solution/projects work perfectly for me (all I did was change the destination of the post-build COPY command and rebuild.)

To be honest, I didn't expect it to work because the VB project targeted "Any CPU", and my experience was that this caused problems for native code DLLs, but it did work.

All I can suggest is to make sure that the COPY command is going to the right place.


Hi Steve

I will Zip the project, but maybe not today as I will need to clean it up a bit.

One thing that I did notice is that the Link command line does not show a "/DLL" and under "General/Configuration Type" it shows "Dynamic-link Library", but it is all grayed out and can't be changed (which seems odd.)

I am also now getting an error: "Error LNK2019: unresolved external symbol WinMain referenced in function "int __cdecl __scrt_common_main_seh(void)" (?__scrt_common_main_seh@@YAHXZ) libcmt.lib(exe_winmain.obj) "

And none of that is my code.  I don't know where this is coming from.

Valued Contributor II


is a standard Fortran/C/Windows  library that you need.

If I had your errors and the code had worked on previous versions then I would first assume I did not install VS and the compilers correctly.  This happens sometimes. 

I would take a quick route - remove all of the VS and the compilers.  

Update Windows and make sure you have the latest SDK 


removing one of these can break your programs,  trust me I learnt that the hard way

Reinstall everything and make sure you get all the batch files run for path etc. 

At this stage I would start a whole new project and read the files one at a time to look for errors 

of course this is drastic, but it faster than trying to fix project files and other corrupt stuff. 

Good hunting


Valued Contributor II

Other idea:

1. Buy an NIC i3 

2. make sure it has a 500 GB drive

3. Join Windows Preview 

4. Install VS 2019 Preview and then all your compilers

5. Get your program running - 

6. keep the NUC upto date with all programs you have and that will tell you when things break, when they break on the NUC that problem will come to your main windows computer at some time later.  

7. Enjoy the fun of running computers all over the world in multiple time zones





You example runs fine - once I changed it to X64.  Same DLL error if not.  I will look to see what the differences between out settings are.


Steve, your code contains the "/DLL" in the link command line and mine does not.  But I do not see how this can be resolved since the option is grayed in both our codes.

Honored Contributor II

1] Make a new project

2] add /dll is the extra options manually maybe.....


I think that when I get back to this (holidays and all) I will do just that.  Start from scratch and rebuild the Solution.

Black Belt Retired Employee

I see I got confused as to who was asking the question!

If your link line doesn't include /DLL, then you do not have a DLL project. Easy way to tell is to open the .vfproj file in Notepad and look at the second line. It should be similar to:

<VisualStudioProject ProjectType="typeDynamicLibrary" ProjectCreator="Intel Fortran" Keyword="Dll" Version="11.0" ProjectIdGuid="{F0B8BF9C-D8BC-4B85-A93C-47A0AEBAED59}">

Note the ProjectType. If yours says something different, it isn't a DLL project. Recreate the project as the proper type.


Hi Steve - thanks for the reply.  But, the vfproj file does say exactly what your line says, so it should be a DLL. But the Linker does not have the "/DLL".  I don't know how that is possible.

I think that what I need to do is to recreate the solution from scratch and see if that fixes things.  I'll let you know.


Me again

Created a new VB project and copied the files from the old project to the new.  When I did that, the "main" form, which has all the controls on it, is blank.  A user control that I created is also blank.  How do I correct this without having to recreate the entire (complex) form?

Black Belt Retired Employee

That I don't know. I would think you could copy all the VB project files to the new solution.

Would you please ZIP the old solution and attach the zip to a reply here? I'd like to understand what went wrong.