STOP inside a DLL?

STOP inside a DLL?

We write a piece of software that is structured as a Delphi executable that calls a Fortran dll. We're working on a new error handling method in which we would like to execute a STOP command within the Fortran, many layers deep inside a subroutine. Early testing suggests that this works well - both the dll and the exe shut down and don't appear to leave any processes behind. However, we have had problems in the past with the STOP command leaving the exe hanging. Can anyone offer any advice on what exactly the STOP command inside the dll does with regards to the calling exectuable and with regards to open files? Are there any issues with Windows 98 as opposed to 2000 or XP that we should be aware of?
Thanks in advance,
David Bradley

7 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

STOP causes the EXE to exit. I'm not aware of any issues using it from a DLL, nor of any OS-dependent issues.


Retired 12/31/2016

But if the statment is STOP 5 or STOP 'zz' then lots of errors before quitting with the calling vb or Excel also failing.

I also have the problem of a large Fortran code called from VB with hundreds of stop statements several call layers deep with no way to return to the top level and then to the VB.

So what to do. Well by chance with Lahey 90 I discovered that executing an integer division by 0 does it. It jumps from the div by 0 straight to the vb statement after the call with the vb error code set to 11 which is division by 0.

Now my reason for searching here is to find if there is any other way in Visual Fortran. From the dialog here I guess not.

But I have already confirmed that div by 0 does it in Visual Fortran from both vb and Excel VBA.

My test vf code is

subroutine sub1(iopt,ipath)
if (iopt.le.-1) then
elseif (iopt.eq.0) then
!integer div by 0
elseif (iopt.eq.1) then
stop 7
elseif (iopt.eq.2) then
stop 'test'
elseif (iopt.eq.3) then
elseif (iopt.eq.4) then
call exit
elseif (iopt.eq.5) then
!float div by 0
iopt = a
elseif (iopt.eq.6) then
!non existant file
elseif (iopt.eq.7) then
print *,'hello'
SUBROUTINE FortranCall (iopt,ipath)
call sub1(iopt,ipath)

my test vb and VBA code is

Option Explicit
Declare Sub FortranCall Lib "Fcall.dll" (num As Long, i As Long)

Sub main()
Static num As Long
Dim ipath As Long
On Error Resume Next
Dim S$
S$ = InputBox("Option")
If S$ = "" Then End
num = Val(S$)
Err = 0
Call FortranCall(num, ipath)
If Err > 0 Then
S$ = "Error" & Str$(Err) & " from FortranCall which is " & Error(Err)
S$ = ""
End If
MsgBox S$ & " Result =" & Str$(num) & ". Got to point " & Str$(ipath)
End Sub

With option 0, the return is with ipath=3 showing that the rest of sub1 and FortranCall are not executed.

So what do you think?

Full Windows apps don't need consoles, the PAUSE statement, or the STOP statement.
Try putting a PAUSE/STOP in a CVF DLL which hasn't allocated a console. On WinNT 4 the OS will repeatedly try to supply a console and eventually crashes. In Win2K it does likewise with PAUSE but won't crash if you persevere in getting Task Manager to eventually kill the process. STOP on Win2K kills the process. Not the kind of behavior one expects from a Windows app. PAUSE is depreciated in f95. Even in legacy code I avoid STOP in CVF DLL's by using the API to raise an exception a la

write(6,*) 'Aborted with: iX = ', iX
STOP !Never reached

and return control to the VC++, VB, or Delphi client.

Gerry T.

My experience has shown me that STOP will raise an exception to the calling .EXE. ie, if you run a vb app, it will crash. there is no way to avoid it. if you are getting it to hang, I am not sure how that can happen unless you have some sort of error handling that is keeping it from crashing.

what i do in my .dll's is write a series of "RETURN". so if a "bad condition" occurs, then i do a return (set a global flag), and i continue to return until it exits. there is no other way to quit the dll immediately and return to the calling .exe without causing a crash or immediate exit of the app.

hope this helps a bit.

I guess I did not make myself clear.

Use of divide by zero eg
does exactly what trnsys wants.
Even if the fortran is in a subroutine 20 calls below the call from vb, return to vb occurs immediately with the vb error code set to 11 and no other errors. The vb can then call the dll again.

Use of STOP as suggested by Nashua does not do this as the vb calling task also quits.

I did not suggest using STOP - I simply explained what happened if you used it. STOP is certainly not appropriate here.


Retired 12/31/2016

Leave a Comment

Please sign in to add a comment. Not a member? Join today