Access Violation When Running with Windows 8.1 Operating Sys

A trajectory optimization program I've been developing/enhancing over an 7-year period is now having some run-time access violations when running with Windows 8.1. The program is being developed on a Windows 7 Machine and has no issues on that machine or on a Windows XP machine (at least not yet observed). Previous versions of the program also had no issues running with Windows 8.1.

The program has a comprehensive GUI, generated with the various winio@ commands. It appears that the access violations may be related to the use of the %eb command (to generate various edit boxes), but this is really just a guess.

Version 5.5.0.0 of FTN95 is being used along with Version 12.2.27.20. of Salflibc.dll.

Any help are suggestions are welcome.

Have you tried compiling using /DEBUG and running the program from the debugger SDBG?

After that you could try downloading the latest personal edition of FTN95 to see if it is an issue that has been resolved. If you can do this on a different machine then it avoids any problems that might arise through having two versions on one machine.

Thanks Paul. Although I've developed many Fortran computer programs since 1963, I've never used a debugger. In the early years, we had to be really careful (slow turnaround), and I didn't make enough mistakes to require learning how to use the debugger. I normally track down bugs using print statements and trial-and-error. That usually works well. In a case like this though, when there is a run-time system error, all I can do is look at the code and see if anything may go out of bounds. I don't really know how to interpret the access violation data that is displayed.

Incidentally, the Checkmate compile option has never worked for me. I can't even get the compiled program executing when I compile with that option, even though the program, compiled with the Release option, has run flawlessly in many upgraded program versions on several Windows operating systems. When running on windows XP, I do have to use an older version of salflibc.dll than I do when running on Windows 7 and Windows 8.1.

Thanks again for your suggestion. I really appreciate it. This old dog may have to learn a new trick to find the problem this time. I will download the personal FTN95 version and try to keep it separated from what I have now, just to see if it solves the problem.

In general it is not safe to use versions of FTN95.exe and salflibc.dll that were not released together. We try to make them interchangeable but it can cause problems.

It is a good idea to try some simple programs, stepping into the debugger. You will find it quite easy and a very powerful tool.

David,

Even if you do not use SDBG, I'd recommend you try compiling with /check or /debug.

/debug does put the routine name information into the .exe, so if the program does crash, you get a stack dump with the call list and line numbers of where the crash occurred. This does not have a big affect on performance.

/check is more extensive. It will give you a subroutine argument check for the routines you have written, but not necessarily for the library routines you call. It also checks for array subscript bounds, than can cause problems. There is a performance penalty, but still runs much faster that the optimised code you compiled 20 years ago.

If you place all your code into 1 .f95 file, /check will check the subroutine call lists at compile time, plus also check the consistency of library calls. You never know what it might show, although Fortran of 60's and 70's did encourage mixed mode arguments for memory management. There are other new Fortran changes, such as static > dynamic storage and initialisation of variables. I have seen a big improvement in robustness by adopting ALLOCATE for arrays, rather than the old memory management. FTN95 is also severe on temporary arrays and stack overflows. Moving large arrays to COMMON or modules helps, as does using ALLOCATE for temporary arrays that would otherwise go on the stack. You probably know about these, as they were a bigger problem in 60's and 70's.

Do you generate a load map from slink ? Could you be using a lot of memory. This can also start to generate some unusual errors with changes to O/S.

I hope these comments might help, although the problem may be as simple as incompatible salflibs.dll for the .exe you generated.

John

Dfwlms, Checkmate (which is the same as /undef) is one of the largest achievement of this compiler starting from the era of FTN77. Copycating it, others also slowly started introducing this ultimate deep cleaning option into their gear decades later. If your code is larger then 20K lines i'll bet $20 that you have so many small and possibly large bugs Checkmate will discover that you will be amazed and ashamed. I can claim that any large program which never compiled with Checkmate is a holly mess and bugotron. And 200K lines programs without Checkmate are just plain wrong. Such codes die naturally under the weight of own hidden bugs. I'd cut programmer's salary 5% for not using it at least ones in a while.

Following this thread, John, you suggest using large / many arrays could produce unusual errors.

My many, some large arrays, are now all static in COMMON. When running in Windows Vista I experience no problems. Running now in W8.1 I am able to generate a crash quite readily.

I have never used SDBG - writing my own tracing within the code has more than proved adequate - however, I am now baffled. Compiling all my source with either /CHECK or /UNDEF I can still crash the app but once I invoke SDBG I cannot force a crash.

What can SDBG be possibly shielding ? surely I must not be left to run my app via SDBG from now on ?

This app is currently compiled with the Personal Edition and SDBG from the same installation.

Steve,

I don't have any explanation for your problem. I don't use Win 8.1 very often, as it is on my notebook and I find my Win 7 desktop more useable. My approach would probably be similar to yours. I would check the load map and see how much memory you are using. Are you near the limit? I would definitely compile with /debug as this gives the line number where the crash occurs. If you transfer some arrays from COMMON to being allocatable in a MODULE, you possibly could reduce the memory usage if they are not all used at the same time. If the problem is not memory related, assuming you have slightly less memory available with Win 8.1 then I don't have many ideas. See other posts, as Get_filtered_file@ can cause this problem. It could be a long standing bug that has never caused a problem before, such as an un-initialised array subscript that was previously zero and is now something else. ( /undef could show this ) If you are already using /check or /undef, doesn't it show where the problem is being recognised? I don't know your program to know how reproducible the problem is, but there is going to be a reason for the crash.

Good luck,

John

Steve, it does not follow that when you use /debug to compile and link you must run the program under SDBG. Using /debug does two things:

1. Puts debug symbols into the OBJ and EXE files
2. Adds code to print out a traceback after a fault, so that you know the line number and the routine name within which the fault occurred, and the chain of calls that resulted in control reaching that line.

The unpredictability of the occurrence of the error is an indication of a memory access error of some sort -- array bounds exceeded, uninitialized array index being used, etc.

David Williams wrote:

Incidentally, the Checkmate compile option has never worked for me. Does your program used precompiled static libraries? If so, you cannot use the /checkmate option without doing some more preparation. If you convert the static libraries into an equivalent DLL (or set of DLLs), /checkmate can be used in the code that calls routines in those DLLs.

Thanks John - I need to search further.

Thanks mecej4 - I've not used /debug before, I'll give it a go.

Paul, I have tried all compiler options as far as I know, and still my code crashes in W8.1 - and with no traceback - but not in Vista. Placing a single WRITE(,) statement or even to an external file, however, does not crash. If there is a memory allocation problem, what clues should I be looking for in the .map, please ? If there are indeed problems with allocation, are there SLINK options I can apply to overcome them ? Thanks, as ever

Some crashes are very hard to fix. I have one for last couple years in large multitab %ps. All suggestions failed. Worst of all the crash disappears when the code is under SDBG. Spent few days, localized the place, but to make small demo have no more spare time to spend for Paul to fix that, may be later, thing is not that critical. Not sure it is 8.1 OS thing. This could also be my own mistake.

As one more suggestion, if all is simple, no mixed language programming and libraries etc, and you do not worry to put the whole code in open access, you can post it together with instructions how to run it into crash and people who have spare hour or two may fix it. I'd personally pay 50 bucks if someone fix my damn annoying @#$$% but unfortunately i can not post it 😦

Mecej4 wrote:

Does your program used precompiled static libraries? If so, you cannot use the /checkmate option without doing some more preparation.

I am not sure that this is the case. If you use libraries that were not compiled with /debug or /check ( ie as default or /opt) I would expect that the routines in these would not be visable to SDBG and treated as a black box. I would still expect SDBG to skip through them, although I can't recall actually testing this.

John

Thanks to all who have helped with suggestions. I will try to make use of as many as is practicable.

The changes made to the program,since the latest-released version (7.3) appeared to work OK on a Windows 8.1 tablet, have included no new kinds of functions as far as I can tell. The in-work program executable is about one-sixth the size of earlier versions and requires about 1/20 as much CPU to run. One reason for this is that contextual-help windows used to display image files (resources), and now they display plain text files (from a folder). Also, some arrays had excessively large dimensions, and these dimensions have now been greatly reduced.

The %eb command is used more in the in-work version because that is how the contextual-help text files are now displayed, but %eb is also used in earlier versions to display other text files (also in folders) containing aerodynamic model data.

The program executable files that are produced from compilations using Checkmate get the same kind of result as those produced from compilations using the 'Release' option. As I've said before, the '... has stopped working' problem appears to occur at a random time/situation when some GUI button is clicked. There may be some specific command or sequence of commands that cause the problem, but I've not yet been able to identify it/them.

At this point, it appears that the in-work version is just not completely compatible with Windows 8.1 somehow. It is a 32-bit program, but that shouldn't be a problem. And, typically, one can get a lot of work done with the program on Windows 8.1 before the program stops working. Sometimes though the program stops working before much can get done.

Is it likely that some background process is interfering with the program?

There have been many upgrades of the program over several years, and it has always worked flawlessly on Windows 7 and Windows XP (SP3) machines. The in-work version, being developed on the Windows 7 machine with older PLATO and salflibc.dll files, works flawlessly on the Windows 7 machine, and I think also on the XP machine (not tested it extensively on XP yet). Also, the in-work version developed on a Windows 8.1 machine with the latest PLATO and salflibc.dll programs appears to work flawlessly on the Windows 7 machine, but it too fails on the Windows 8.1 machine in the same way.

The 'crashes' on the Windows 8.1 machine do not produce a systems-error type window. What appears is the nice little '.... program has stopped working' window, with no details about the problem. And Windows 8.1 does not close the program automatically, even though the program is dead.

Anyone who's interested can download a free copy of the most-recent released version of the program (ZOOM) from the webpage: http://trajectorysolution.com/ZOOM%20Program.html

Thanks again for all of your suggestions.

David Williams

Paul,

For my problem I list a brief description of the map :

Linker Map of named.exe  Wed Mar 25 07:33:12 2015



Image base = 400000   Image align = 1000     File align = 200     

Stack = 3200000  Heap = 100000  


Entry point _SALFStartup at 00605bc0


00400000  header                                  Linker defined


Address   Name                                     File in which defined
 
Code

00401000    SRSMAIN                                  .......
 
00401000    main                                     .......
 
00401000    __clearwin                               .......
.
.
.
. 
00606d70    WritePrivateProfileStringA               C:\Windows\system32\kernel32.dll

Uninitialised Data

00607000    __ctype_ptr                              C:\PROGRA~2\SILVER~1\FTN95\salflibc.lib (/0             )
                                                        (\cpplib\nt_dll\salfstar.obj)
.
.
.
03e2a000  end                                     Linker defined


Executable section map:

Section   Base      Length    Flags   

.text     00401000  00205d80  60000020
.bss      00607000  03359dac  c0000080
.comment  03961000  00001d7a  00000a00
.data     03963000  00324b50  c0000040
.rdata    03c88000  00000038  40000040
.idata    03c89000  00001283  c0000040
.rsrc     03c8b000  000aa378  40000040
.CRT      03d36000  0000000c  c0000040
.salfmap  03d37000  0000301f  40000040
.salfdbg  03d3b000  000ecbc0  42000040
.salfsys  03e28000  00000018  c0000040
.salfvc   03e29000  0000002c  c0000040
.reloc    03e2a000  00000000  42000040

Hoping there may be something to trigger a response.

As I say, a specific sequence of events - 4 clicks - will guarantee a crash, with the Windows message as DW describes. Once in SDBG, the code runs fine,

Thanks, Steve

Steve

If you are able to send me all of your code then I will aim to investigate the problem as time allows.

Steve,

Your load map shows end as hex:03e2a000, which is decimal 65,183,744. This is about 62 megabytes, which is nowhere near the limit of memory use. My thought of running out of memory does not apply.

My next approach would be to compile with /check and see what might happen. If the graphics does not work, you could try /debug and see if the stack dump identifies the problem.

Access violation suggests you are addressing outside you allowed memory. This can be either:

• you are addressing an array out of bounds, or
• the stack has been overwritten in some way; typically due to inconsistency between the subroutine call list and the subroutine expected arguments

An approach I have tried is to collect all the source code into a single file and compile with /check. It may show the argument list inconsistency.

There is a lot of scope for where this error could be !

John

During the past week or so, I've struggled to get ZOOM working on Windows 8.1, making a few structural changes, increasing ZOOM's run priority, running in the safe mode, and using the debugger. Executables (Checkmate and Release) built on the Windows 7 machine run flawlessly on that machine and on a Windows XP machine. Executables built on a Windows 8.1 machine run flawlessly on a Windows 7 machine (probably on the XP machine too).

The error found by the debugger, after I'd operated the program for quite a while (clicking buttons), was almost surely a secondary result of the unknown primary error. The debugger thought that there were too many %bg commands. The code belies this, and if there was such a coding error, it would provoke a standard run-time system error (which never occurs). The failure is always manifested by the pop-up 'ZOOM.exe has stopped working...' window, with no details provided.

The Windows 8.1 machine is the problem (new DELL with fourth-generation I3 single core processor). I've exhausted all approaches I can think of and am about willing to just reluctantly forget Windows 8.1.

The following download contains a synopsis of what I've tried, a listing of a routine that created the last window before one of the failures, and a screen shot of the failure. Any suggestions from those more capable than I (they are legion) will be appreciated.

The link is: http://trajectorysolution.com/Windows8-Problem.zip

David,

I too have experienced the problems you describe on my new Dell notebook which has Win 8.1 OS. I would guess that the 'ZOOM.exe has stopped working...' response you are seeing is because the program is waiting for something to happen. I get a similar message! It can be that the program is actually running and has not completed the calculation that is required to perform, but more likely it is waiting on some system response. The frustrating think about these problems, is you start to blame all sorts of things you don't understand, such as incompatible 'drivers' that need updating. All we know is that something is not working the same as before and it is associated with moving to Win 8.1. The problem with using get_filtered_file@ (which started with Win 7!) is similar to this, but the solution is still elusive.

The problem can actually be a bug in our software, that has not been identified until now, although assuming a bug in Win 8.1 is more palatable. Until we can identify where the program is waiting, we'll never know, so keep looking.

John

John, Thanks for your advice about compiling into a single file. I'll give it a go, but I do suspect an array out of bounds problem. A real misery, sorry, mystery !

Paul, Thanks for the offer, but there is a rather lot of code !