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

How to debug a Fortran .exe called by a fortran .dll which is called by Access VBA

El_Noshokaty__Said
New Contributor I
1,807 Views

Hi all,

I have MS Access 2016 64bit and an integrated MS VS / Intel Parallel Studio XE 2020 working under Win 10 64bit. An Access application VBA code is calling a .dll Fortran program which in turn is calling an .exe Fortran program. I need to debug both the .dll and the .exe Fortran programs with or without the use of MS VS.

Said

0 Kudos
1 Solution
Steve_Lionel
Honored Contributor III
1,799 Views
  1. In your Fortran DLL project, Debug configuration, open the project properties for the x64 configuration, select Debugging.
  2. Under Action > Command, set the property to the path to the Excel executable. For example, C:\Program Files (x86)\Microsoft Office\root\Office16\EXCEL.EXE
  3. Under Action > Command Arguments, set the property to the full path to your XLS file. 
  4. Click OK.
  5. Set a breakpoint at the first executable statement in your DLL procedure.
  6. Make sure that the "library" you specify in the XLS is the exact path to the DLL resulting from a Debug build.
  7. Press F5 or Debug > Start debugging

Excel will start, and when your DLL routine is called, the debugger will stop at the breakpoint.

There is a worked example of this in the Parallel Studio XE Samples Bundle under compiler_f\MixedLanguage\Excel.

View solution in original post

13 Replies
Steve_Lionel
Honored Contributor III
1,800 Views
  1. In your Fortran DLL project, Debug configuration, open the project properties for the x64 configuration, select Debugging.
  2. Under Action > Command, set the property to the path to the Excel executable. For example, C:\Program Files (x86)\Microsoft Office\root\Office16\EXCEL.EXE
  3. Under Action > Command Arguments, set the property to the full path to your XLS file. 
  4. Click OK.
  5. Set a breakpoint at the first executable statement in your DLL procedure.
  6. Make sure that the "library" you specify in the XLS is the exact path to the DLL resulting from a Debug build.
  7. Press F5 or Debug > Start debugging

Excel will start, and when your DLL routine is called, the debugger will stop at the breakpoint.

There is a worked example of this in the Parallel Studio XE Samples Bundle under compiler_f\MixedLanguage\Excel.

El_Noshokaty__Said
New Contributor I
1,776 Views

Dear Steve,

I apologize for being late in responding to your message. The reason is that many programs were subject to testing and debugging and I wanted to report the result of these efforts to you. 

As usual, your answer to my question is a perfect one. Yet, there is one remaining problem. The "FSEEK" statement for the sequential binary files works fine when the program is compiled by MS VS and it doesn't when compiled by ifort  command line environment. To go around the problem, I replaced it by the "REWIND" statement since the purpose of the seek is to point at the beginning of the file. Do you have any idea why it doesn't work?  

Said 

 

0 Kudos
Steve_Lionel
Honored Contributor III
1,766 Views

I assume you are referring to the FSEEK portability library function.  Did you check its return value? Is your DLL the entirety of the Fortran code or do you have more than one Fortran DLL or library in the project? 

REWIND is a better choice here, anyway.

0 Kudos
El_Noshokaty__Said
New Contributor I
1,744 Views

Dear Steve,

Beginning-of-file-Fseek returns "0" and because the end of the file is the current position, any Read statement after it branches to the end-of-Read routine. The .Dll program is the only one in the project. When compiling the same program by an old Intel Visual Fortran, there were no problems. The current ifort command line:

ifort /O3 /nologo /assume:buffered_io /Qinit:zero /Qinit:arrays /Qparallel /integer_size:64 /real_size:64 /double_size:64 /fpconstant /fpscomp:filesfromcmd /fpscomp:ioformat /fpscomp:ldio_spacing /fpscomp:logicals /fpscomp:general /fpscomp:libs /module:"c:\sos\\" /object:"c:\sos\\" /libs:dll /threads /o "c:\sos\sosvoyagerprogllah.dll" "c:\sos\lib\kernel32.lib" "c:\sos\lib\imagehlp.lib" "c:\sos\lib\uuid.lib" "c:\sos\lib\ifmodintr.lib" "c:\sos\lib\ifwin.lib" "c:\sos\lib\ifconsol.lib" "c:\sos\lib\libifcoremd.lib" "c:\sos\lib\libifportmd.lib" "c:\sos\lib\libiomp5md.lib" "c:\sos\lib\libmmd.lib" "c:\sos\lib\libirc.lib" "c:\sos\lib\svml_dispmd.lib" "c:\sos\lib\libmatmul.lib" "c:\sos\lib\libcpmt.lib" "c:\sos\lib\libcmt.lib" "c:\sos\lib\msvcrt.lib" "c:\sos\sosvoyagerprogllah.f90" /DLL  

is using MS VS version of:

ifmodintr.lib, ifwin.lib, ifconsol.lib, libifcoremd.lib, libifportmd.lib, libiomp5md.lib, libmmd.lib, libirc.lib, svml_dispmd.lib, libmatmul.lib, and msvcrt.lib.

Said

0 Kudos
Steve_Lionel
Honored Contributor III
1,736 Views

That looks ok to me. I have no idea what the difference might be.

0 Kudos
jimdempseyatthecove
Honored Contributor III
1,730 Views

A good guess at the problem is the (implicit) folder used in the OPEN statement is .NOT. that which you expect it to be. IOW you may have created/used a file elsewhere from what you think it is (same name, different folder)

Jim Dempsey

0 Kudos
El_Noshokaty__Said
New Contributor I
1,718 Views

Hi Jim,

So long since our last messages.

No such case. The strange thing is that the same program when compiled by MS VS it runs without problems. Same thing when it was compiled with old Intel-Visual-Fortran command line. My guess is that VS is using consistent set of libraries while I'm not doing the same thing in the ifort command line. Do you have any idea what libraries have to do with Fseek? Do you think libraries such as libcmt.lib and libcpmt.lib are responsible?

Said

0 Kudos
Steve_Lionel
Honored Contributor III
1,714 Views

Do you have USE IFPORT in the procedure that calls FSEEK? If not, you may be getting the wrong one.

0 Kudos
El_Noshokaty__Said
New Contributor I
1,594 Views

Dear Steve,

Do you think MS VS has used IFPORT by itself when compiling the same program and runs it successfully?

Said

0 Kudos
Steve_Lionel
Honored Contributor III
1,586 Views

No. It would be interesting to see the build output when the linker option /verbose is specified. From the command line, add "/link /verbose" to the end of the ifort command that does the link. In VS, set project property Linker > General > Show progress to "Display all progress messages" and then do a build. Zip the buildlog.htm from the VS build and capture the command output (you may need to redirect the output - use " > log.txt" at the very end of the ifort line) and attach to a reply here.

0 Kudos
El_Noshokaty__Said
New Contributor I
1,567 Views

Dear Steve,

For command line, using " > log.txt" was not successful. Therefore there was no way but to capture 51 images. Some images are large and some are small !!. Attached herewith please try to view them plus the MS VS build log. For notification, the program compiled by VS does not contain "use IFPORT" while the one compiled by the ifort-command-line contains it.

Said

0 Kudos
Steve_Lionel
Honored Contributor III
1,562 Views

Thanks - both builds are using the same FSEEK. I am out of ideas for now.

0 Kudos
El_Noshokaty__Said
New Contributor I
1,546 Views

Dear Steve,

Thank you for your professional support. I'm lucky your are still there.

Said

0 Kudos
Reply