legacy app vb6 calling fortran trying to debug into fortran

[paige386]

I have a legacy vb6 app that is calling a fortran DLL. I have recently upgraded to Windows 7 and VS 2010 with the Intel Fortran compiler v12.0.3470.2010. The dll keeps crashing on me and I am trying to set it up to trace into the fortran. I have compiled for debug and placed the dll into the directory but it doesn't seem to want to stop at my breakpoint.

Any suggestions?

Thanks

[Steven_L_Intel1]

I assume you have not rebuilt the VB app in VB.NET - right?

Here is the general way to debug an "external" app that calls your DLL. In the DLL project, go to the Debugging property page and for the Command property, give the full path to the executable that is to run. You also need to ensure that the DLL that is loaded is exactly the same one that the project builds, not a copy. So if you need to, change the Output File property in the Linker > General page to be the path the VB app is going to load.

Then set your breakpoint and start under the debugger. The executable will run and your breakpoint should hit.

I will note for others reading this that this advice doesn't apply if you are building the VB (or other) application in the same VS solution, and that for managed code applications you need to set the "Enable unmanaged code debugging" property in the other language (VB, etc.).

[paige386]

yes the project is in native VB6, there is a project pending to upgrade it to .net but no funding at the moment.

I changed the DLL call to point to the output(debug) directory from the compile. I am also debugging the VB app so I wasn't sure what the command line would be. I compiled the app and enteredthe exe as the command line and ran, the breakpoint still wasn't hit. I verified it was the right DLL by deleting it first and then doing the recompile.

[Steven_L_Intel1]

If you are also debugging the VB app then it would be the msdev.exe for Visual Studio 6 that you would run. I am not sure how well this would work, though, if also trying to debug the Fortran. I wonder if inserting a call to the Windows API routine DebugBreak in the Fortran code would do anything useful. Perhaps the biggest problem is that VS6 probably doesn't understand the debug information from the newer VS/Fortran.

[paige386]

after playing with a smaller program set I was able to get it to trace. Had to do the following.

1. in the VS 2010 fortran I had to set the debug command line to C:\Program Files (x86)\Microsoft Visual Studio\VB98\VB6.EXE
2. open the VB Project and start the run
3. start the fortran application
4. trace through the VB app until getting to the fortran where control was tranfered to VS 2010.

On the orignial project I have the same setup now but when I try to set the breakpoints in the fortran code its telling me the breakpoint won't be hit because no symbols have been loaded for this document.

The original developer of the Fortran had used includes but moving the code out of the includes into the main program didn't help.

any suggestions there?

[lklawrie]

This may seem like an end-around, but what I've done to debug my fortran DLL with VB6 app is to make a small fortran main program and simulates the conditions and then calls the fortran routine like the VB6 app would.

It's all in Fortran, so the debugging trace part is easy.

[paige386]

Thanks for the suggestion Linda, I think the issue is the actual interface between VB6 and the Fortran. There is a string array being passed in modified and sent back. String arrays are always a challenge. This was working fine previously with the Powerstation Fortran but with the upgrades to Win 7 and new compiler things seem to have changed a bit.

[Steven_L_Intel1]

Microsoft Fortran PowerStation (pre-1997) and Intel Visual Fortran pass strings differently, by default. Can you show us how you declare the Fortran routine in VB and what the Fortran routine looks like? (Header and declarations of arguments.) In particular, the string length is passed in a different place in the argument list. But this should prevent a breakpoint from being hit.

[paige386]

here is the basic info

(VB)

Private Declare Sub testlite Lib "c:\msdev\projects\test\test\debug\testlite.DLL" Alias "_routine@44" _

(ByVal iCall As Integer, sPath As mySpath,iVar1 As Integer, _

cVar1 As cVar1ByteArr, dVar1 As Double, dVar2 As Double, _

dVar3 As Double, ByVal iErrorReturn As Integer)

I will have to do some work to post a fortran example.

I did add the intent statment for the string array in Fortran

CHARACTER*612,INTENT(INOUT)::cVar1(MAXSER * 15)

I do remember seeing something a while back where you had to add a variable to pass the size of the array as well as the array itself i will look at adding that in.

[Steven_L_Intel1]

INTENT will have no effect here. Try adding the line:

!DEC$ ATTRIBUTES REFERENCE :: cVar

to the Fortran code.

I assume you have a:

!DEC$ ATTRIBUTES STDCALL, REFERENCE :: routine

in there somewhere.

[paige386]

thanks for the suggestion it appears the

!DEC$ ATTRIBUTES REFERENCE :: cVar

references were missing from the code which has resolved the crashing issue.

One additional item when the application closes I receive this message

"R6031 - Attempt to initialize the CRT more than once. This indicates a bug in your application."

I'm not sure how to turn off managed code in this compiler.

Thanks

[Steven_L_Intel1]

What is the setting for your Fortran project under Fortran > Libraries > Use run-time library ?

[paige386]

Sorry for the delay I only get to this office twice a week.

runtime library = Multithread DLL (/libs:dll /threads)

use common windows libraries = no
use Port library = no
use Intel Math Kernel Library = no
Disable Default Library Search Rules = no
Disable OBJCOMMENT Library Names in Object = No


I made this change and it seems to have resolved the issue, let me know if there are any adverse effects to using the setting below, Thanks.

runtime library = Multithread

[Steven_L_Intel1]

Hmm. Try changing the "Runtime Library" option to "Multithread" and see what happens.

[paige386]

the change to MULTITHREADED resolved the issue, are there any adverse effects to that?

[Steven_L_Intel1]

Not when the DLL is called from other than Fortran.

[paige386]

thanks for your help Steve!

[Ed_F_]

I have a similar situation, just upgraded my Fortran DLL projects from Compaq Visual Fortran to Intel Parallel Studio XE 2013 with Visual Studio 2010, but the calling program is VB6.  It calls a Fortran DLL, which subsequently calls two other Fortran DLL's.

With some effort, I was able to get everything to work together as an installed application.  It also works fine when I run the main program in the VB6 debug environment, calling all the Fortran dll's.  However, when I try to run from the debug environment in the Fortran project, the main program launches, but then gives an error that it can't find the dll. (I have the .exe in the same "solution", and defined as the startup project.)

I know from experience that VB issues the same "file not found" error whether it is missing the actual dll that it is trying to call, or something that the dll is dependant upon, so I don't really know what it is not finding.  The Fortran project is for the main dll, and includes the .lib files for the dll's which it calls.  The .exe and all the dll files are in the same directory, which is set as the working directory for the project.

The program starts fine, but as soon as it tries to call the dll, it issues error #53, file not found.  Any ideas?

------------------------------------------------------------------------------------------------------------------------------------------------------------

Update:  I found the problem.  In my main Fortran DLL I pointed to the "Release" version .LIB for one of the other DLL's, but the DLL in the working folder was from the "Debug" version.