Problem Crash down with saved scenario (save current)

[Iberville]

Hi everyone,
I am getting a very strange crash down in a very specific situation.

- First, I load a scenario (I use almost only recommended addons from this forum) like a resupply mission to ISS with the DG IV with Ummu and UCGO. I complete my mission and I then I quick save my game. I then exit back to the orbiter start window and do a (save current) to save my game elswhere than the quick save folder. (all goes well for now)

-The problem comes when I load that game. All goes wellwhen I play. But If I quit, I end up with the usual quitting page of orbiter with the green box in the horiontal line, but at the end of the quitting process, it makes a crash down with the windows bugging window.

It is doing that only with saved games that are in no folder in the scenario page. It does not affect the simulation while I play tough... I have absolutely no clue about what's going on.

I have Orbiter 2010 with only recommended textures, DGIV, XR5, ummu, UCGO, UMMU ISS and ShuttleA and orbiter sound3.5

Thanks for the help!

 

[N_Molson]

I have quite the same problem...

Do you use the DGIV "MKSAT" in your scenario ? I suspect it to cause CTD on exit in some situations...

 

[Moach]

it appears some addon isn't unloading right.... perhaps a loose pointer or an unclosed file is being left behind....

the only way to tell is to disable your addons one by one untill the crashing stops....

 

[Izack]

I had a problem with hanging on shutdown after installing UMmu and UCGO, which may be related to this. I solved it by setting Orbiter to terminate itself and restart on exit: Extra > Debugging Options > Orbiter shutdown options > Respawn Orbiter process.

I'm not sure if that will help, though.

 

[Iberville]

I have quite the same problem...

Do you use the DGIV "MKSAT" in your scenario ? I suspect it to cause CTD on exit in some situations...

I am not sure what is MKSAT, but I do use DGIV.

The only addons I have are Dan Steph ones and textures one.

By the way, I can still reload the scenario easily and play and everything seems normal. The problem just occur on quitting the program.
I erased Luna-01 and mir whil starting my game unsing scenario editor. Could it cause that problem?

 

[orb]

Take a look at what already Izack posted. That should help.


The usual quitting page with "green box" in the progress bar is due to De-allocate memory option selected for simulation end, which is default for Orbiter 2010.

This is a gentle return to the Launchpad, because Orbiter frees its own resources allocated when simulation was starting, doesn't unload plug-in modules from memory, and displays the Launchpad window again. Orbiter only "knows" what memory or files it allocated itself, and not what was allocated by its loaded modules. You can observe with for example Windows task manager, that PID of orbiter.exe doesn't change between simulation sessions, which means that it's still the same Orbiter process running, as you executed at the very beginning.

The Respawn Orbiter process option is a brute force reinitialization of the Orbiter to display its Launchpad. Orbiter process is terminated and executed again to display its Launchpad. Orbiter doesn't deallocate its resources, and used modules (plug-ins, vessels, celbodies) don't need to deallocate their resources, because Windows process management makes it for them, though Orbiter unloads all plug-in modules before its termination. All resources (memory, opened files, and other handles) used by Orbiter and its loaded modules (all modules were loaded by Orbiter so they belong to it) are freed by Windows, because Windows "knows" all the memory and opened handles that belong to what process, what wasn't true when Orbiter deallocated memory for closing simulation. Orbiter Launchpad that appears after simulation end is a freshly executed orbiter.exe process. You can observe it with Windows task manager, by looking at changing PID every time the simulation had ended and the Launchpad reappeared.

This was the default behavior for Orbiter 2006, and some modules took advantage of this, that they didn't need to deallocate what they allocated, and plug-ins didn't need to reinitialize themselves after simulation end, because they were unloaded and loaded again by a new Orbiter process. That doesn't work with the default for Orbiter 2010 shutdown option to De-allocate memory after simulation close, and hence the crashes caused by modules of add-ons that were initially designed for Orbiter 2006.

The last Orbiter shutdown option to Terminate Orbiter process, simply doesn't relaunch the Launchpad after orbiter.exe process termination.

 

[Iberville]

Thanks Orb and Izack. The problem seems to have stop now. I really appreciate the help and your time!

 

[N_Molson]

I was asking myself about that.

So, there is no side-effect to use "Terminate Process" ? I was believing that some memory could be left unallocated. But yeah, if Windows monitors the whole process, it knows what's gets in and what's get out of the Orbiter process.

That solves the problem in my case too.

 

[orb]

So, there is no side-effect to use "Terminate Process" ? I was believing that some memory could be left unallocated. But yeah, if Windows monitors the whole process, it knows what's gets in and what's get out of the Orbiter process.

Otherwise for example killing any process that allocated memory from the task manager would left that memory allocated. Either when the process is terminated from inside of process, by ExitProcess or an exception, or is terminated from outside (e.g. Task manager), the resources it used are freed, though some dlls it used may be unloaded after a while if they are no longer used by any other process.