That's great news.  I was concerned that something on my system was causing the problem. I tried turning off the anti-virus, running check-disk, scanning for adware, cleaning up the registry, etc., but none of it prevented the SF 2.39 issue.  I finally had to revert back to SF 2.37.

Now I'm double pleased; first that you found the problem and fixed it and second that it was not my computer causing the problem.

I look forward to using SF 2.40 and as always thanks for your continued support.

Frank

A fix for 2.40 is now being tested that basically removes the prepared statements entirely since the bottleneck is not the internal database.  Reliability should be significantly increased.

Thanks for sending the partially created makefile.  It'll provide a starting point for debugging. 

The crash information isn't as useful.  I'd guess it's just explaining that some part of the Windows API was called with an illegal argument or a bad memory address.  The Internet search information is a generic description of why a DLL might cause a crash.  Simply Fortran doesn't ship ntdll.dll as it is a core component of the Windows operating system.

I've experienced another error with fwin.exe.  The following is the error message related to an "APPCRASH" from module ntdll.dll.
I've not experienced any problems with Windows 7.0 or running any other applications.

Message: "SF fwin.exe has stopped working:

Problem signature:
  Problem Event Name:    APPCRASH
  Application Name:    fwin.exe
  Application Version:    0.0.0.0
  Application Timestamp:    59a03b42
  Fault Module Name:    ntdll.dll
  Fault Module Version:    6.1.7601.18247
  Fault Module Timestamp:    521ea8e7
  Exception Code:    c0000005
  Exception Offset:    0002e3be
  OS Version:    6.1.7601.2.1.0.768.3
  Locale ID:    1033
  Additional Information 1:    023c
  Additional Information 2:    023cde462b8019a6bb5ee8774be2c1ed
  Additional Information 3:    71a7
  Additional Information 4:    71a7e71adb058bb0569b8e144ee76ab0

Related information I took off the internet regarding ntdll.dll:
NTDLL.DLL, FILE DESCRIPTION: NT LAYER DLL
Errors related to ntdll.dll can arise for a few different different reasons.
For instance, a faulty application, ntdll.dll has been deleted or misplaced,
corrupted by malicious software present on your PC or a damaged Windows registry.
This file is required by Windows, and deleting the file would make Windows inoperable.

Frank

You wrote: "An SEH error is drastically more severe.  If you do see one occur, you cab email whatever makefile is present after the error (it probably won't be complete) so I can troubleshoot the problem."

I inadvertently caused a syntax error programmatically, but upon a Build an (SEH) error occurred.
I've reconstruction the message here:

      END IF
           1
Error: Expecting END SUBROUTINE statement at (1)
Error: Last command making (build=SHARC8.50_CGM8_Module.o) returned a bad status
Error: Make execution terminated

* Failed *
==============
Generation Makefile... Okay

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Make Construction Error

! A sever, internal error occurred while creating the Makefile.
  Please report this issue (SEH) to support@approximatrix.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The Make file resulting from the error is shown below:
--------------------------------------------------------------------------------
#
# Automagically generated by Approximatrix Simply Fortran 2.39
#
FC="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\gfortran.exe"
CC="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\gcc.exe"
AR="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\ar.exe"
WRC="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\windres.exe"
RM=rm -f
IDIR=-IC:/Users/Julianna/AppData/Local/sfpm/64/include
LDIR=-LC:/Users/Julianna/AppData/Local/sfpm/64/lib
OPTFLAGS= -O2
SPECIALFLAGS=$(IDIR)
RCFLAGS=-O coff
PRJ_FFLAGS=-O2 -ffrontend-optimize -Wl,-stack_size,0xFFFFFFFF,-stack_addr,0xC0000000,--heap=0x00100000
PRJ_CFLAGS=

# Auto-including AppGraphics libraries.
--------------------------------------------------------------------------------

Thanks for you continued effort in the development of SF; I couldn't do without it.
Great application!

Frank

Thank you for your detailed response.  You are correct, after the so-called crash and truncated re-Build,  when Build was executed once again, it compiled perfectly.

Regarding the Virus scanner, I do use Microsoft Security Essentials and for computer maintenance real-time scanning with IOLO System Mechanic.

Thanks for looking into this issue and I look forward to the next version of SF.

Frank

I'd like to follow up on the fwin.exe stopped working  crashes.  Several times using SF 2.39 I've experienced SF crash completely (exe aborts with a "fwin.exe stopped working" error). At times it occurs during a build and other times just while I'm editing a program file.

I think we do need to clear some terminology up.  If fwin.exe stops working, it constitutes a "crash" as you've described.  Version 2.38 and 2.39 might be using a new version of an internal database, which could be a culprit.  I'll look into that, although I haven't experienced similar crashes.  The multithreaded file scanner was introduced in 2.38, but, again, I haven't been able to reproduce crashing of the main development environment.

The "build error" that's problematic that you described earlier is the "SEH" error, which implies that the development environment's memory was corrupted at some point while creating a makefile.  Again, I'm not sure why that would occur nor can I reproduce it, but I suspect that the internal database is the cause.

The "Timeout" error can be caused by the dependency scanner, part of the indexing operation.  There is a timing issue in version 2.39 and all earlier versions that can cause builds to "Timeout" (which isn't a "crash," but, rather, a valid message) if file indexing operations haven't been complete.  It should already be fixed in the development version.

So the makefile appears to be successfully created.  I don't see anything wrong.  If fwin.exe "crashed" here, it is simply due to an internal bug caused by, most likely, the internal database.  It would have been interesting if an "SEH" error were displayed.  Otherwise, everything appeared to work prior to a crash.

The output in the Build Status tab looks completely normal here.  You are seeing "Permission Denied" errors during linking, which means either your program did not properly terminate prior to building (check the Task Manager) or a virus scanner is not releasing a handle to the executable to allow the linker to overwrite the original executable.  That issue is entirely unrelated to everything else you've described.  Are you running a virus scanner, and, if so, which?

You have to remember that you're using a program to generate and later replace executables (I'm pretty sure our linker is set up to first delete then create a new executable, but I need to confirm...), an action which almost every virus scanner considers highly suspect.  A normal user wouldn't have any need to replace an executable, let alone create and then launch one.  Many popular, third-party scanners take a very dim view of compilers.  I don't have these type of issues with Microsoft's own scanner, however.

I will look into the internal database further next week.  I would guess that recent crashes would be due to that issue.

Here's an example of the Make file where a SF 2.39 crash occurred during a program build.

#
# Automagically generated by Approximatrix Simply Fortran 2.39
#
FC="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\gfortran.exe"
CC="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\gcc.exe"
AR="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\ar.exe"
WRC="C:\Program Files (x86)\Simply Fortran 2\mingw-w64\bin\windres.exe"
RM=rm -f

IDIR=-IC:/Users/Julianna/AppData/Local/sfpm/64/include

LDIR=-LC:/Users/Julianna/AppData/Local/sfpm/64/lib

OPTFLAGS= -O2

SPECIALFLAGS=$(IDIR)

RCFLAGS=-O coff

PRJ_FFLAGS=-O2 -ffrontend-optimize -Wl,-stack_size,0xFFFFFFFF,-stack_addr,0xC0000000,--heap=0x00100000

PRJ_CFLAGS=

# Auto-including AppGraphics libraries.
PRJ_LFLAGS=-lappgraphics -lgdi32 -lcomdlg32 -lcomctl32 -luuid -loleaut32 -lole32 -mcmodel=medium

FFLAGS=$(SPECIALFLAGS) $(OPTFLAGS) $(PRJ_FFLAGS) -Jmodules

CFLAGS=$(SPECIALFLAGS) $(OPTFLAGS) $(PRJ_CFLAGS)

"build\EZCalc_Global.o": ".\EZCalc_Global.F90" "modules\nrtype.mod"
    @echo Compiling .\EZCalc_Global.F90
    @$(FC) -c -o "build\EZCalc_Global.o" $(FFLAGS) ".\EZCalc_Global.F90"
.
.
.
    @echo Deleting build\SHARC8.51_ScrollMenu_Module.o and related files
    @$(RM) "build\SHARC8.51_ScrollMenu_Module.o" "modules\mainmenu.mod"
    @echo Deleting default icon resource
    @$(RM) "build\sf_default_resource.res"
    @echo Deleting Ezy-CurvFit4.exe
    @$(RM) "Ezy-CurvFit4.exe"

"Ezy-CurvFit4.exe":  "build\EZCalc_Global.o" "build\EZCALC_Main2.o" "build\EZCalc_Module.o" "build\My_Function_Module.o" "build\SHARC8.50_AxisScale.o" "build\SHARC8.50_BIOS_Module.o" "build\SHARC8.50_CGM8_Module.o" "build\SHARC8.50_CheckData.o" "build\SHARC8.50_CheckParser_MDL.o" "build\SHARC8.50_EigenPCA_Mod.o" "build\SHARC8.50_Error_Handler.o" "build\SHARC8.50_Func_UDF_MDL.o" "build\SHARC8.50_FunctParser.o" "build\SHARC8.50_Globals.o" "build\SHARC8.50_LaunchExe.o" "build\SHARC8.50_LaunchExeWrapper.o" "build\SHARC8.50_LaunchPath.o" "build\SHARC8.50_LevelButtons.o" "build\SHARC8.50_MachPrecision.o" "build\SHARC8.50_Main_Sub_MDL.o" "build\SHARC8.50_Main_UDF.o" "build\SHARC8.50_MARQ21_Module.o" "build\SHARC8.50_Matrix_Inverse .o" "build\SHARC8.50_nrUtil.o" "build\SHARC8.50_Operators.o" "build\SHARC8.50_PercentProgressBar.o" "build\SHARC8.50_Plot.o" "build\SHARC8.50_PlotXYWindow2.o" "build\SHARC8.50_Pvalue.o" "build\SHARC8.50_ReadWrite.o" "build\SHARC8.50_Reinsch_Smooth_Module.o" "build\SHARC8.50_ResidualsWindow.o" "build\SHARC8.50_ResultsWindow.o" "build\SHARC8.50_RKF7n_Module.o" "build\SHARC8.50_ROBUSTWT_Module.o" "build\SHARC8.50_Scosine.o" "build\SHARC8.50_SemiLogWindow2.o" "build\SHARC8.50_StiffDiff3a.o" "build\SHARC8.50_StrLib.o" "build\SHARC8.50_TAU2_Outliers.o" "build\SHARC8.50_TextBox_Module.o" "build\SHARC8.50_XYDataWindow.o" "build\SHARC8.51_ScrollMenu_Module.o" "build\sf_default_resource.res" "build\EzyCurvFit900.prj.target"
    @echo Generating Ezy-CurvFit4.exe
    @$(FC) -o "Ezy-CurvFit4.exe" -static "build\EZCalc_Global.o" "build\EZCALC_Main2.o" "build\EZCalc_Module.o" "build\My_Function_Module.o" "build\SHARC8.50_AxisScale.o" "build\SHARC8.50_BIOS_Module.o" "build\SHARC8.50_CGM8_Module.o" "build\SHARC8.50_CheckData.o" "build\SHARC8.50_CheckParser_MDL.o" "build\SHARC8.50_EigenPCA_Mod.o" "build\SHARC8.50_Error_Handler.o" "build\SHARC8.50_Func_UDF_MDL.o" "build\SHARC8.50_FunctParser.o" "build\SHARC8.50_Globals.o" "build\SHARC8.50_LaunchExe.o" "build\SHARC8.50_LaunchExeWrapper.o" "build\SHARC8.50_LaunchPath.o" "build\SHARC8.50_LevelButtons.o" "build\SHARC8.50_MachPrecision.o" "build\SHARC8.50_Main_Sub_MDL.o" "build\SHARC8.50_Main_UDF.o" "build\SHARC8.50_MARQ21_Module.o" "build\SHARC8.50_Matrix_Inverse .o" "build\SHARC8.50_nrUtil.o" "build\SHARC8.50_Operators.o" "build\SHARC8.50_PercentProgressBar.o" "build\SHARC8.50_Plot.o" "build\SHARC8.50_PlotXYWindow2.o" "build\SHARC8.50_Pvalue.o" "build\SHARC8.50_ReadWrite.o" "build\SHARC8.50_Reinsch_Smooth_Module.o" "build\SHARC8.50_ResidualsWindow.o" "build\SHARC8.50_ResultsWindow.o" "build\SHARC8.50_RKF7n_Module.o" "build\SHARC8.50_ROBUSTWT_Module.o" "build\SHARC8.50_Scosine.o" "build\SHARC8.50_SemiLogWindow2.o" "build\SHARC8.50_StiffDiff3a.o" "build\SHARC8.50_StrLib.o" "build\SHARC8.50_TAU2_Outliers.o" "build\SHARC8.50_TextBox_Module.o" "build\SHARC8.50_XYDataWindow.o" "build\SHARC8.51_ScrollMenu_Module.o" "build\sf_default_resource.res" $(LDIR) $(PRJ_LFLAGS)

all: "Ezy-CurvFit4.exe" .SYMBOLIC
---------------SF crashed here-----------------------------------------

When I re-loaded SF 2.39 and tried to re-build the same program, I received the following...

==============================================================================
Generating Makefile... Okay
==============================================================================
Processing default resource
Generating Ezy-CurvFit4.exe

* Complete *
==============================================================================
Generating Makefile... Okay
==============================================================================
Processing default resource
Generating Ezy-CurvFit4.exe
c:/program files (x86)/simply fortran 2/mingw-w64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: reopening Ezy-CurvFit4.exe: Permission denied

c:/program files (x86)/simply fortran 2/mingw-w64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: final link failed: Permission denied
collect2.exe: error: ld returned 1 exit status
Error: Last command making (Ezy-CurvFit4.exe) returned a bad status
Error: Make execution terminated

* Failed *

I hope this is helpful,

Frank

I'd like to follow up on the fwin.exe stopped working  crashes.  Several times using SF 2.39 I've experienced SF crash completely (exe aborts with a "fwin.exe stopped working" error). At times it occurs during a build and other times just while I'm editing a program file.

Although there's always a possibility that it's due to the program I'm working on, especially during a build error.  But I've not experienced previous versions of SF crashing and totally shutting down while editing a program file.

Any thoughts?

Frank

The compiler options would not cause any of the issues you've described.

Thank you provide a panel build window fix.  I look forward to trying it.

Regarding, the size of the the program where I'm experience crashes, it's not huge, just about 45 files producing a executable of around 3000k.  By build crashes I mean that SF just aborts completely on occasion when building.  I do recall an earlier message that said something like 'Dependency timeout' or something like that.

Today I received a Make Construction Error, "A severe, internal error occurred while creating the Makefile. Please report this issue (SEH) to support@approximatrix.com".  But the SF panel displayed "*Complete* Generating Makefile... Okay".

In SF under code generation menu I've set the Optimization to "Common" but checked the [x] Agressive Loop Optimization.

Also under Compiler Flags/Fortran Compiler I inserted the following:
-O2 -ffrontend-optimize -Wl,-stack_size,0xFFFFFFFF,-stack_addr,0xC0000000,--heap=0x00100000

Might this be causing the problem?

Frank

Indexing cannot be disabled.  In fact, I might remove the status mention of it since most users seem to think its unnecessary.  How big is a "VERY large" project?  Simply Fortran is regularly tested against projects with 100s of files, and it seems responsive on my end. Just trying to understand the issue.

What do you mean exactly by "build crashes?"

The issue is related to the use and then removal 'X' of the horizontal open build panel at the lower part of the SF screen.  The problem does not arise when using vertical build panels selected in the 'Options/Tabs' menu.

One additional question is related to indexing, which causes SF screen to continue to refresh very slowly when the project is VERY large.  Is there an option to turn-off the indexing?

Even when shown to be 'Syntax Disabled', the indexing continues working every time the cursor is moved in the program.
For example, Syntax: "Disabled Indexing: 2 Files - Working..."

I've also had build crashes of SF 2.39 that I've not experienced with earlier versions.

Frank

. . ..the term 'bug' was coined by IBM when they found that a vacuum tube in one of their computers was short circuited by a bug... . .  .
Frank

That's as I also recall reading about.  Figuratively, of course, but IBM used the  word to mean a fault, or an error, in the code, and three cheers for IBM, as well as you, Jeff, for calling a spade a spade (as it were).  Clarity lives on, albeit only in isolated pockets nowadays, of technology and commerce!

I don't want to lose my pension so I'll not name the company which I believe first taught the world how to dissemble by putting perfectly good English words through the mangle and using them to avoid calling a spade a spade. 

When a machine, or a computer program, or a door handle doesn't work,
  - IT HAS: a fault. 
  - I DO NOT HAVE: "issues"!

When a well-known wordprocessor still sometimes wrecks the format of an entire document bar the current paragraph, if one uses 'copy format' to arrange that paragraph similarly to another, this is not an "issue".  It is a  B  U  G for Pete's sake!

Sorry about the off-topic rant, but I'm done.
And the art of the mixed metaphor lives on!

I've sent you an email, but, for now, there's no need to try 2.38.  It will behave the same as 2.39.