RaiseException using sdbg64

We are using FTN95 in 32 bit and 64 bit mode.

• 64 bit advantage: Substantial better performance
• 32 bit advantage: Debugging possible

With each new FTN95 version we hope that the problems with sdbg64 will be resolved. Now, having installed version 9.00, we learned that our problem remains.

Root cause for problems seems presently to be a call to a dynymic link library, causing a 'RaiseException' and a program crash. Without sdbg64, operating the program simply as executable, works well. Also 32 bit code, with or without debugger, works well.

I could compress the source code to just 9 lines, easy to reproduce with the corresponding dll.

PROGRAM DLL_Test
Implicit None
Integer :: Stat
Character (len=100) :: sLesDB
C_EXTERNAL les_wkst_dbpath   'les_wkst_dbpath'   (ref, val) : Integer
sLesDB = 'C:\SE_DataBase\Dateien\LESDB.MDB'
Stat= les_wkst_dbpath(sLesDB,0)
write (*,*) 'Stat = ', stat
END PROGRAM

How can we proceed to get the problem resolved?

Thomas

Please supply code for the DLL function together with the command line options used to compile both the DLL and the executable.

Hi Paul, The relevant command line options for FTN95 are as follows: /64 /check /intl /save

The dll is a semi-commercial software, where we have unfortunately no access to the source code. We can however provide the following documents:

• interface description
• dll file
• data base used by the dll How can I submit or upload the corresponding files?

It may be the case that the exception happens somewhere inside the dll. With the 32 bit version we can however debug. And the 64 bit executable is performing well without sdbg64.

Thomas

1. I usually use DropBox to upload files to the internet and then send a link.

2. /INTL is the default so is not of interest.

3. /CHECK can be experimentally changed to /DEBUG to see if the problem relates to one of the checking mechanisms.

4. /SAVE is not recommended unless you know what it does but it is unlikely to make any difference.

5. If the exception is raised in the third party DLL then there may not be much that you can do about it other than report it to the owner.

Paul,

Since /check is our default option I tried with any combination of /-check and/or /-debug without success.

The orignal subroutine calling the dll-function needs actually not to be debugged. Compiling this single subroutine with /-check is therefore acceptable for us.

To download the relevant files try the following link:

https://cloud7.steinmueller.com/s/bjijadF8CdF6TMC

Thomas

I have tested using your make64.bat and it works for me giving

Stat =          -10

So I think that you need the latest updates for FTN95 and the Silverfrost DLLs.

I will send you a personal message on this Forum when I have built and uploaded new versions.

Thank you, Paul, for your continuous support in this matter.

The reason for stat = -10 is most probably that the access data base is not at the specified location. The statement

sLesDB = 'B:\LESdb\LESdb.mdb'

shall therefore be adjusted according to the correct file path. The desired result is stat = 0.

If I remove the data base from its location or specify an invalid file path, I also receive stat = -10 and sbg64 works perfectly. In case of a valid file file path I receive stat = 0 if the program is started as executable. Starting with sdbg64 lets the program crash when stepping over the dll call.

Find below a list of stat return values: 0 - no warnings, no errors -1 - Error: no results for the material -2 - Error: the material database ID is not exists -3 - Error: user data set filter error -4 - Error: the database is busy -5 - Error: no connection to the database -6 - Error: user data set is busy -7 - Error: system error -8 - Error: the material is not found in the user data set -9 - Error: strength values: the temperature is too high -10 - Error: the database file does not exist -11 - Error: p > 0.385 Sm (ASME VIII-1 scope) -12 - Error: no temperature factor found (ASME I scope) -13 - Error: design code number is invalid -14 - Error: wall thickness evaluation is not converged -15 - Error: weakening factor evaluation is not converged -16 - Error: invalid algorithm for ASME I PG-27 calculation -17 - Error: invalid temperature index -18 - Error: invalid property name -19 - Error: invalid geometrical parameter (e.g. Do = 0) -20 - Error: no solution of equation found -21 - Error: general calculation error -22 - Error: invalid out-of-roundness -23 - Error: the version limitations of input values are exceeded -24 - Error: the DLL is not activated

Thomas

Now that I have the correct path for LESdb.mdb I get an access violation.

It does not depend on the command line options (provided I use /64) and for me it is not related to SDBG64.

I can't step into the third party DLL so I have no way of knowing what is going wrong. At the moment I can only assume that there is a problem in the third party DLL or in the way in which the function is being called.

Paul,

At least you were able to reproduce the error. Did you also try to execute the code without sdbg64? The question remains, why it works as executable with the same binary code but not in debug mode.

My conclusion for the time being:

1. The outcome of your investigation is what I was worried about. Your view that it is not sdbg64 but the dll causing the trouble is comprehensible.
2. We need to proceed with both, 32 bit and 64 bit code simultaneously. 32 bit for debugging. 64 bit for good performance.

I will proceed with the owner of the dll not expecting a better outcome.

For me it does not work either way.

Can you try 32 bit mode with /-64 and sdbg instead of sdbg64?

All relevant files including 32 bit dll were already uploaded.

Which exception is being raised?

No exception with 32 bit, neither when executing the program as executable nor with sdbg.

No exception with 64 bit when executing the program as executable.

With sdbg64: [img]https://cloud7.steinmueller.com/s/gKHdNnX7iiXrnjY[/img]

Thomas

For 32 bits I get a runtime failure: LESdb.dll not found.

Which exception is it? Is there a 32-bit exception number shown in sdbg64?

Paul, Robert,

The make32.bat batch procedure, contained in

https://cloud7.steinmueller.com/s/bjijadF8CdF6TMC

and started in a DOS command box, shall involve LESdb32.dll, the 32 bit version of the dll, instead of LESdb.dll. Both dll versions, LESdb32.dll and LESdb64.dll can be found at the same web address.

The exception is shown at

https://cloud7.steinmueller.com/s/gKHdNnX7iiXrnjY

Can we possibly improve our communication by a web-based meeting with e.g. MS Teams?

Thomas

I am not able to test the 32 bit version because you have not provided LESdb.dll and I can't find a download for it on the Internet. I expect that it will just confirm your own experience and I don't see how that will help with your 64 bit development.

One detail that I would point out to you is that the PATH is to be passed as a null terminated string i.e. 'path'//char(0). However, this change is unlikely to solve your problem.

After that I don't see how I can help you further (either here or with Team viewer).

Have you tried asking sdbg64 to ignore that exception? To do this you should edit sdbg64.ini. On my machine the file is at %appdata%\sdbg64.ini (which resolves to C:\Users\Robert\AppData\Roaming\sdbg64.ini).

To ignore the exception add (anywhere):

IgnoreException-1=E06D7363

Hi Robert,

Great! I just added the recommended instruction and sdbg64 works perfectly.

Initially, when reading your message, I was sceptical.

Thank you and Paul for your support. It will make development much easier for us if we need not create both, 32 bit and 64 bit binary code.