Community
cancel
Showing results for 
Search instead for 
Did you mean: 
El_Noshokaty__Said
New Contributor I
485 Views

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

Jump to solution

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

Accepted Solutions
Steve_Lionel
Black Belt Retired Employee
477 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
Black Belt Retired Employee
478 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

El_Noshokaty__Said
New Contributor I
454 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 

 

Steve_Lionel
Black Belt Retired Employee
444 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.

El_Noshokaty__Said
New Contributor I
422 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

Steve_Lionel
Black Belt Retired Employee
414 Views

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

jimdempseyatthecove
Black Belt
408 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

El_Noshokaty__Said
New Contributor I
396 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

Steve_Lionel
Black Belt Retired Employee
392 Views

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

El_Noshokaty__Said
New Contributor I
272 Views

Dear Steve,

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

Said

Steve_Lionel
Black Belt Retired Employee
264 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.

El_Noshokaty__Said
New Contributor I
245 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

Steve_Lionel
Black Belt Retired Employee
240 Views

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

El_Noshokaty__Said
New Contributor I
224 Views

Dear Steve,

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

Said