reboot to play

maybe create a support ticket...

Link to forums for explanation:

https://forums.galciv3.com/452855/page/1/

Link to support tool:
http://sd.stardock.com/Support/supportToolTest/SDSupportTool.exe

Oh! Here is the location for dmp files!
"C:\ProgramData\Stardock\Galactic Civilizations III" 

I also have to do this with SotSII. It seems to be related to the Intel Rapid Storage or my SSDs Raided. I used to wonder if Internet or video was the fault but I have been able to run the game when playing a movie or being on the net. 97% of the time going on the net and looking at facebook with their auto play videos would not let it start. Since a reboot solves it by setting something back to default/reset I see it as something in my computer like some resource/service is not being released and reinitalized correctly.

I had the problem of the game not shutting down smoothly when I exited, so that Steam for example, would not close right away.   I used to reboot regularly.   However, since Beta 4 (and I might add, since 16 gB memory, though I don't know what that would have to do with it) I do not have this at all - the game shuts down fast and restarting doesn't seem to create any memory issues judging from a performance monitor I often run --- that is starting a new game results in the same memory use whether it follows  reboot or several game starts and exits.

To be sure, I don't have an SSD (though I have been watching prices and such for a long time).

 

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.

That sounds like an OS problem rather than one with the game. Try the System File Checker and see if it solves the problem.

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

No, it is a game issue.  Reported multiple times by multiple people.

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

This  may be related:  on an immense game I seem to hit a "freeze wall" around turn 200 or so.   I can't reproduce the freezes, but suddenly they are very frequent.   However, a reboot changes things, and I can then play on for some time  --- probably straightens out video memory, since I always have at least 6 gB physical memory free (our of 16 total) and tons of page file memory.   While playing my GPU memory (I have 1gb) seems to be nearly maxxed out most of the time.

With the memory optimization coming I am not sure more physical memory is the issue for larger maps...I am thinking more and more that it is the video card that is the bottleneck.   But just guessing.

 

 

OT, but what is SFC?

 

Ummm, ForesterSOF....  what was that???

 

sfc /scannow

After reboot all seems ok. went on the net and played a vid at cbs.com then tried to start the game and it did. have run sfc before so see if running it next time it locks solves the issue will tell.

so far so good

Need to run this in administrator mode.    In win 7, start, type cmd in window, right click on the cmd entry above, and choose run as administrator.  Then in the dos window the command as shown by ForesterSOF.

 

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

 

As long as the info got to whom ever it needed to.

 

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.

I have made my wireless connection as strong as possible by myself but after running the program speedconnect things seem to work fine now.

The settings it shows that it changed were already set to what it wanted but it must have done something behind the scenes.

For clarification this is a wirelessN to cable50/3. the biggest change was my wireless is 2x faster.

Not only does the game play after doing other thing on the net first; shutdowns do not have to be forced.

 

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.