Sometimes when I quit the game the game;s process is still running.  I have to end process and then can relaunch the game in Steam.  Otherwise Steam says the game is still running.  When this happens, the process is using something like 2.6GB of memory even though the game is closed.

I had my current game (gigantic) stall on "Wait". Everything worked fine, but no new turn. I saved and restarted the game and had the same problem. I saved, rebooted, and reloaded the game and it worked fine. Had to be a memory problem.

I have 8g ram. I may need to up that for the bigger maps coming

I see this happen a lot with other games and apps, along with tasks failing to quit during shut down. Every time I see this I run SFC and the problem is fixed for me.

Any time a program signals to the OS that it is quitting, the OS has the ultimate responsibility of seeing to it that all of the resources the program had assigned to it are released back to the OS, even if the program failed to do so correctly. This is one of the biggest problems Windows has had since its origination (yes, all the way back to 95 and beyond).

OT, but what is SFC?

I had to remove that long post. It was causing an issue on the forum.

Your first point: I cannot imagine that telling windows to rum sfc scan, which scans for corrupt windows files, or more specifically "scan all protected system files, and replace corrupted files with a cached copy that is located in a compressed folder at %WinDir% \System32\dllcache. The %WinDir% placeholder represents the Windows operating system folder. For example, C:\Windows.".  the game should not have files under that umbrella

The second one: No it does not.  That is only the case for programs that properly close any open child processes/handles.  If those are left open, for some reason...  such as a bug causing them to remain open or close more slowly than expected, the os will assume them to remain open potentially forever in the case of an infinite loop or a thread waiting for a signal/event that will never come due to a bug.  

I've seen steam complain about the game being running even after taskkill /t /f /im "galciv*" (or whatever the exe is).  exit & restart steam fixes the trouble for me when that happens.

There was a big contention between Windows and OS2 in the mid 1990's over this very point. If, for some reason, an application was closed, whether the user  initiated the closure through the app or someone forced the closure through a system function (like ALT-F4 or via the task manager), somehow, the entire app had to be closed and cleaned up. The best case is if the app was able to take care of all of it, but there are circumstances where the app has lost control of pieces of it and can't complete the process. Windows has historically been very poor at managing such situations, and has typically put the blame on the app, even in cases where Windows has removed the connections needed for the app to complete the closure. An example of this is where a user has to use the Task Manager to close a task. OS2 did a much better job of ensuring the complete closure of the app. Windows has made some improvements in this area, but it is still nowhere near where OS2 was in the 1990's.

I am beginning to suspect that there is some interaction between GC3 and the rest of the system where some of these hangs and system file corruptions are occurring. Certainly, it doesn't make sense that GC3 could directly corrupt a system file, but some interaction between GC3 and the rest of the system could be leading to it. When you consider that there are a number of layers,, starting with GC3 (or any app) and continuing through support levels down to the hardware, like DirectX, the GPU drivers, the OS support, etc. there are lots of places where something can go wrong.  This can cause some real headaches for the debugging support team of the app (like GC3), especially when a support product owner or the OS team refuse to acknowledge the problem.

So the question is: What can we do to help the GC3 devs track down the problem and get it assigned to where the problem truly belongs. Here is my suggestion: Report each and every instance to SD providing all of the data and descriptions they ask for. Use of the SDSupportTool gathers a lot of that information when run, but sometimes it is necessary to use the results from OS tools as a supplement. For instance, use of the Task Manager to force a dump gives SDSupportTool a dump from which it can gather some of that data, and SFC provides a log file that the devs can use to get to which files might have been corrupted, which can provide hints about what action by GC3 may have lead to the file corruption, which can lead to the discovery of where the corruption was really done. This information should also be provided to the devs for this kind of problem.   --   Another piece of information gathered by SDSupportTool is your system configuration, which allows the devs to collate occurrences to differing hardware support, like graphics cards and drivers, sound cards and drivers, CPU chips and drivers (especially when the CPU chip has an  integrated GPU chip), etc. Once the GC3 devs get the problem isolated to some communication down the support chain they can get in touch with the development team responsible for that part of the support (like MS for DirectX, NVidia for GeForce GPU display drivers, the owners of the AMD GPU drivers, MS for Windows functions, Intel for the drivers for integrated Intel CPU/GPUs, etc. etc.) and they can work together to track the ultimate location of the problem.