We have built a 64 bit GUI application named p0918w_64.exe by means of ftn95, Version 8.10 which runs on
several PCs. However, there is 1 PC (running Windows 7, 64 Bit) where the application does not work and results in the Silverfrost exception report

Attempt to execute illegal instruction c000001d at address 7fede0a87f0
Within file CLEARWIN64.DLL
In DANINT$$ at address 0
Within file p0918w_64.exe
in INWAND at address 27b
...

p0918w_64.exe, clearwin64.dll and salflibc64.dll are located in a directory, say start_dir, located on a shared drive.
p0918w_64.exe is started from start_dir for each of the PCs in question.

The ressource monitor shows that dlls clearwin64.dll and salflibc64.dll are loaded from start_dir in all cases tested.

The Fortran call of INWAND which causes the exception is

II=INTL(DNINT(RR))

where RR is of type REAL*8 and II is of type INTEGER*4.

The corresponding 32 bit application runs successfully on the PC for which the error occurs for the 64 bit version.

Does anyone have an idea why this could happen?
I have no idea how to break this down to a small application which I could send to you.

I compiled this code (named intl_dnint.for) by command
ftn95 intl_dnint.for /undef /cfpp /64 /link
and copied it to a shared drive. On 1 PC the executable intl_dnint.exe crashed with the exception mentioned above. No write statement is executed in this case.
On several other PCs this code works and produces the write statements expected.

In this context I have some questions.

1. If I had not defined intrinsic function dnint to REAL*8 in the code, what would have been the type of dnint?
2. What is the type returned by function INTL, INTEGER*4 or INTEGER*8?
3. Is there any functionality to list the dlls loaded by a fortran application from within the application's code?

ANINT is the Fortran standard form of the function. When it has one argument its return value has the same type and kind as the argument. When using ANINT you don't need to declare its return type and kind.

INTL is not needed in this program. It converts the argument to a 32 bit integer and this happens anyway. INT is the Fortran standard form of this function and (for a single argument) the return type is a integer with default integer kind.

Listing the DLLs used from the Fortran code
---------------------------------------------------

I have had a brief look at this and I don't have a satisfactory answer at the moment. Here is some code that works up to a point but I can't see how to read the results into a file for processing. Normally I would add ">output.txt" to the command line but this does not work from a background command.

I tried out the code you gave me for listing the dlls (second version). It works and lists the dlls, thanks for your info again.

Unfortunately it does not list the path of the dlls (especially of dll clearwin64.dll which I intended to print out from within an executable, e.g. intl_dnint.exe). And I did not find a way to get the dll paths by viewing the online help of the tasklist command.

Does it fail on the first call into ClearWin84.dll? If it is the first call then maybe the DLL is not accessible in some way (however, you should get a clear message to this effect). DANINT$$ is a simple (one line) function in ClearWin64.dll. Its argument is passed by value and if there is a coding error then it should show up when used locally.

The executable compiled prints out the library information in both the successful and the unsuccessful case (and this information is the same in both cases):
VERSION: 19.5.4.13
PATH : <start_dir of executable>\CLEARWIN64.DLL
DATE : 7:17:50 - 5:5:2017
. In the unsuccessful case (creating the exception) the write statements printing MYDNINT or II are not executed.

The sample I referred to in my previous post failed on the first call into CLEARWIN64.dll.

I will take a look at it when I can but if it is a problem with msvcrt.dll then the solution will be for you to download and install a later version of msvcrt or alternatively for Silverfrost to release a version of ClearWin64.dll that has msvcrt embedded in the DLL.