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.
Here's an example of the Make file where a SF 2.39 crash occurred during a program build.
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.
When I re-loaded SF 2.39 and tried to re-build the same program, I received the following...
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.