Application Error Compaq Visual Fortran Professional Edition 6.6.0

[Haider__Abbas]

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#comment-1746318

Any help/suggestions would be much appreciated.

[andrew_4619]

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

[Haider__Abbas]

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

[Haider__Abbas]

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

[jimdempseyatthecove]

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

[Haider__Abbas]

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.

[Haider__Abbas]

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

[jimdempseyatthecove]

>> 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

[andrew_4619]

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

[Haider__Abbas]

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. 

[Steve_Lionel]

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.)

[Haider__Abbas]

dependencies image

[Haider__Abbas]

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

[Steve_Lionel]

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.

[Haider__Abbas]

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.

[jimdempseyatthecove]

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

[FortranFan]

@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.

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:

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.

[Steve_Lionel]

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.

[FortranFan]

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.

[Haider__Abbas]

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.

[jimdempseyatthecove]

If you application is stuck with (requires) 32-bit 3rd party library .AND. if the library function could handle the array sizes you need to produce .BUT. for the fact the total memory requirements of the application exceeds that of a 32-bit application (and you are unable to obtain a 64-bit version of this library), then you might consider breaking the application into two parts that fit within the 32-bit application address space:

Part 1: Front-End that has the user interface and prepares the data and writes to file, messages or launches part 2
Part 2: Back-End that reads the file, calls the 3rd party library, writes results

That said, an additional alternative that may be available is if the data can be partitioned and worked on separately is to partition the data and then work on the pieces. This was what was typically done back in the days when programs had 640KB (or 64KB, or 32KW or less). IOW you used file storage for your data and the RAM for the program and temporary data workspace. Note, if partitioning is possible, then you may be able to use MPI (Message Passing Interface).

Jim Dempsey