Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Beginner
11 Views

Application Error Compaq Visual Fortran Professional Edition 6.6.0

I am getting an Application Error with fortran console application on Windows 10 .  The error is a popup window that says "The application was unable to start correctly (0xc0000018). Click OK to close the application."  I receive no errors or warnings when i compile the code.

I used the same code one year ago on a different system with a similar operating system and it worked fine. but now it seems to show this error and the debug section shows following comments:

Loaded 'APP01.EXE', no matching symbolic information found.
Loaded 'wow64_image_section', no matching symbolic information found.
Loaded 'C:\Windows\SysWOW64\kernel32.dll', no matching symbolic information found.
The thread 0x4124 has exited with code -1073741800 (0xC0000018).
The program 'C:\wrokdir\codes\faqiemodifiedload\Debug\Dyneii.exe' has exited with code -1073741800 (0xC0000018).
 

The code is very large and written in FORTRAN 77. Other small codes apart from this one that I built are working fine so this doesnt seem to be an error with the CVF 6.6.0 installation.

A similar problem was also reported in a post several years ago, but no solution was posted.

https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/402538#comme...

Any help/suggestions would be much appreciated.

0 Kudos
24 Replies
Highlighted
Valued Contributor II
11 Views

I think that is  a DLL

I think that is  a DLL failing to load. Run dependency walker on your exe to find what runtime dll's are called maybe? 

 

0 Kudos
Highlighted
Beginner
11 Views

Thank you for prompt reply

Thank you for prompt reply Andrew_4619

I ran the dependency walker on the exe im trying to run and it has listed a number of dlls it is calling that it cannot find. also it lists following errors

Error: At least one required implicit or forwarded dependency was not found.
Error: Modules with different CPU types were found.
Warning: At least one delay-load dependency module was not found.

 

two main dlls it is calling are 

NTDLL.DLL

KERNELBASE.DLL

KERNEL32.DLL

0 Kudos
Highlighted
Beginner
11 Views

let me attach an image of the

let me attach an image of the dependency walker run as well. im not familiar a lot with it

0 Kudos
Highlighted
11 Views

Your build of DYNEII.EXE is a

Your build of DYNEII.EXE is a 32-bit build, whereas the KERNEL32.DLL (etc...) is x64.

On a 64-bit version of WIndows

x64 libraries are located in System32            *** note x64 in ...32
Win32 libraries are located in SysWOW64    *** note Win32 in ...64

Confusing to be sure.

Your project is not consistent with regards to bitness

Also, in the Solution Platform pull-down you may have 2 or 3 choices: Win32, x64, and optionally x86.
*** do not use x86 for Fortran builds as this is intended to generate a bit-mode agnostic application.
Use Win32 for 32-bit and x64 for 64 bit.

Jim Dempsey

0 Kudos
Highlighted
Beginner
11 Views

Thank you for your

Thank you for your suggestions Jim.

From your suggestions what i get is:

1) I should re-check the address of kernel32.dll  in my compiler and use the one available at /SysWOW64 instead of the one available at /System32?

2) I checked the Platform available  in CVF 6.6.0 (build/configurations/) it can only use Win32 choice which is being used. so this part does not needs correction i guess.

0 Kudos
Highlighted
Beginner
11 Views

I actually cross-checked by

I actually cross-checked by running dependency walker on my exe. it is using kernel32.dll from SysWOW64 already

0 Kudos
Highlighted
11 Views

>> it is using kernel32.dll

>> it is using kernel32.dll from SysWOW64 already

Your .jpg on #4 shows:

KERNEL32.DLL  ...  x64  ... 0x0000000180000000 ... (64-bit relocation)
...
DYNEII.EXE    ...  x86  ... 0x--------00400000 ... (32-bit relocation ('-' == not available))

My guess is you Link is including two versions of KERNEL32.DLL (etc...) one from System32 and one from SysWOW64.

Jim Dempsey

0 Kudos
Highlighted
Valued Contributor II
11 Views

I think that is a bug in

I think that is a bug in Dependency walker confusing paths for 32/64....

0 Kudos
Highlighted
Beginner
11 Views

thank you for pointing it out

thank you for pointing it out. i checked and tried to use C:\Windows\SysWOW64\kernel32.dll as the library at (project\settings\link\general) but it cant read this library file.

also im attaching another image of a better dependency walker. 

0 Kudos
Highlighted
Black Belt
11 Views

You also asked this in comp

You also asked this in comp.lang.fortran.

I am going to guess that your "very large" program declares some very 
large arrays, perhaps in COMMON, and that the total size of static code 
and data, plus stack, exceeds 2GB (or close to it). This can cause the 
symptom you report. There really isn't much you can do about this with 
CVF, unless you have set the stack reserve size much larger than needed.

If data size is the ultimate problem, the only real solution is to use a 
64-bit compiler (Intel Visual Fortran supports all your CVF code) and 
change the static arrays to ALLOCATABLE. (Even in 64-bit, the 2GB limit 
on static code and data remains.)

--
Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
Beginner
11 Views

dependencies image

dependencies image

0 Kudos
Highlighted
Beginner
11 Views

Thank you for your valuable

Thank you for your valuable suggestion Steve.

I agree with your comments, but what is confusing me is that I have been using the same code last year on windows 10 with 64bit version. that time i never faced this data size problem. after many months now i need to use the same code again but its not working

0 Kudos
Highlighted
Black Belt
11 Views

There could have been a

There could have been a slight change in Windows that pushed you over the edge. Please generate a link map (on the Linker property page or add "/link /map" at the end of the df command that does the linking), zip the .map file and attach it here. 

I will also note that the code and data used by dependent DLLs also are included in the size limit.

--
Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
Beginner
11 Views

thank you Steve.

thank you Steve.

I have not defined any specific size in the stack settings initially. but after your suggestion i tried several sizes ranging from 1GB - 2GB but it gives me the memory error for sizes large than 1GB. I hve zipped the .map file with this post. pls find the attachment.

0 Kudos
Highlighted
11 Views

Your .bss (uninitialized data

Your .bss (uninitialized data) segment has length of 0x75811674 (almost 2GB). While this does  not exceed the linker maximum segment length, the sum of this together with the sum of the other segments will exceed 2GB.

You likely have two options:

1) make the overly large arrays located in GLOBRE allocatable
2) Enable the /3GB switch in BOOT.INI (google "windows 3gb switch")

Option 1 is preferred as this may future-proof your program.

Jim Dempsey

0 Kudos
Highlighted
Valued Contributor III
11 Views

@Haider, Abbas:

@Haider, Abbas:

As pointed out by Steve and Jim, your issue has to do with the size of all the static plus other data in your program.  If you can refactor the code sufficiently to manage the data, either by using ALLOCATABLE facility introduced in Fortran starting with the 1990 revision along with system HEAP and/or the use of 64-bit target (x64), your program should work alright on Windows OS.  You can get a good handle on this by reviewing a simple reproducer - see attached zip - involving a silly example which uses the CVF pre-processor with compiler directives such as SIZE_256MB, DEC$, etc to control the size of the program data:

      !DEC$ IF DEFINED ( SIZE_256MB ) ! Data size slightly below 256 MB
      INTEGER, PARAMETER :: N = 67000000
      !DEC$ ELSE IF DEFINED ( SIZE_2GB ) ! Roughly 2 GB
      INTEGER, PARAMETER :: N = 492848541
      !DEC$ ELSE
      INTEGER, PARAMETER :: N = 2
      !DEC$ END IF
      REAL :: X(N)
      PRINT *, "N = ", N
      CALL RANDOM_NUMBER(X)
      PRINT *, "X(1) = ", X(1)
      PRINT *, "X(N) = ", X(N)
      END

You will notice if the size is 256 MB or less, the program runs fine.  However if the size is large, the issue you state in the original post is reproduced.

set.png

Upon execution in Microsoft Visual Studio 6.0 IDE with CVF integration with the larger data size, you will notice the same exit code in the thread:

vs6.png

Note the zip attachment also includes Microsoft Visual Studio solution (p.sln) and project (p.vfproj) files for the same example above and if the program is built with the x64 target, it executes as expected.

 

0 Kudos
Highlighted
Black Belt
11 Views

Abbas is using Compaq Visual

Abbas is using Compaq Visual Fortran from 2003, which is 32-bit only. Switching large arrays to ALLOCATABLE will allow the program to start, but it will likely then fail when the large array allocation is attempted. Without upgrading to a compiler with 64-bit support, the only thing I can think of is to rewrite the code to not require such large arrays (perhaps by storing some information in a file.) The /3GB Windows option would have to be combined with the "Large Address Aware" linker flag, and even then success is not guaranteed.

--
Steve (aka "Doctor Fortran") - https://stevelionel.com/drfortran
0 Kudos
Highlighted
Valued Contributor III
11 Views

Quote:Steve Lionel (Ret.)

Steve Lionel (Ret.) (Blackbelt) wrote:

Abbas is using Compaq Visual Fortran from 2003, which is 32-bit only. Switching large arrays to ALLOCATABLE will allow the program to start, but it will likely then fail when the large array allocation is attempted ..

Yes, OP was shown an example of the limitation with the ALLOCATABLE approach at OP's comp.lang.fortran post.  But something to keep in mind is that with statically declared arrays, codes often tend to have the 'maximum' anticipated by authors in terms of array dimensions.  Whereas the program executions rarely approach those limits e.g., number of 'whatever' items actually employed in a calculation might be on the order of 100 but the arrays are dimensioned to 1000.  With dynamic allocation, OP can attempt to make the data size at run-time more closely approach actual needs which might be lower than static dimensions, thereby allowing the program to function even as a 32-bit application on Windows.

This is not to say OP should not consider upgrading to a new compiler with x64 support; there are so many other advantages that OP should of course consider that if possible.

0 Kudos
Highlighted
Beginner
11 Views

thank you guys all of you. im

thank you guys all of you. im trying to fix my code as per your suggestions,it sure is a memory problem. ill update here once it is done or need further suggestions.

0 Kudos