I was trying to play Closing the Kurile gap, I am on build 573. Not far into it (during the opening strike on the convoy) I start getting system.OutOfMemory errors. My hardware has 16GB of RAM and the usage shows 11.66GB in use. In Task Manager, the Command.exe is showing as *32 with a memory (private working set) at just over > 1,010,000 k when this happens before recovering back to 835,000k once the message pops up. This is under Windows 7, 64 bit (obviously, with 16GB of physical RAM). Did I miss some sort of commandline switch / setup item? While I realize this scenario is a "large one" -- I find it hard to believe that it cannot be played if you actually take any human actions.
To give an idea of what's "in play" at the time:
Other than the default missions (CAP), I setup 3 ASW patrols which put 7 P-3s up and 2 Support missions which are putting an EP3 and E3 into the air (so +9 aircraft above the default). I also put a total of 11 Tomahawks into the air. That's it.
Using this same opening, I will always get an error with an System.OutOfMemoryException, the only difference is the occasional "inner stack trace." Oh, and if I close the error, and cancel the "close the app" popup, the sim will continue up to a point. Later on it will just generate these messages constantly.
Thanks for the help! (I attempted to attach the error dialog into this message.)
I loaded it raw and it locked up after 11 minutes of game time. I went into the scenario editor, checked the db. Its 10 versions out of date. Did a quick rebuild and now it works. I see this out of memory issue now and then if the scenario designer doesn't keep up with db updates or you get an old version of the scenario.
btw, that is the largest scenario I have ever opened in Command. There were 3500 units flying around by the time I quit. If anything breaks Command, it will be this one.
btw, I run a mid-level laptop and my pulse times were anywhere from 2 full seconds to 3 full seconds by the time I quit. It is a killer scenario.
Thanks for the reply. I have only had this sim for about a month and haven't played with the scenario editor -- so I didn't even realize there was a need to rebuild the scenario to match the database revision. I will give that a try and see if my problems go away.
Well, now I get further (the initial strike on the convoy completes) but I get a "Command has stopped working, windows is searching for a solution" thing. I'm checking to see if I can make it easily reproduceable since there isn't an application error message that I can send a screenshot of. All I have is what is in the Windows application event log, pasted below.
Faulting application name: Command.exe, version: 1.0.0.0, time stamp: 0x542efc90
Faulting module name: KERNELBASE.dll, version: 6.1.7601.18409, time stamp: 0x53159a86
Exception code: 0xe0434352
Fault offset: 0x0000c42d
Faulting process id: 0x18c0
Faulting application start time: 0x01cfea1c84b3ca00
Faulting application path: C:\Matrix Games\Command Modern Air Naval Operations\Command.exe
Faulting module path: C:\Windows\syswow64\KERNELBASE.dll
Report Id: 32a2bc7f-5611-11e4-9b53-8c89a59cdf40
FYI -- it isn't something obviously systemic since I was able to run Operation Brass Drum (a much smaller scenario).
I tried several runs of this scenario and it appears to be tied either to the aircraft launches or tomahawks. If I do my normal launch of some P3s, E3s, EP3s, and E2Cs with tomahawk strikes it will fault, but if I just let it run (at least so far) without doing anything it's ok. I am going to launch things one at a time and see if I can figure out which weaponsystem is the problem (if that is what causes the fault).
Ok, right before that "Command has stopped working" there is a momentary in-game popup with the out of memory line, but the rest of that dialog is trashed and then the dialog disappears to be replaced by the Dr. Watson message. It occurred at 11:30 in. I will try again in a different order, focusing on that E-3B sentry out of Yokota. Nothing was in the message log beyond 2:09:35. The only other thing occuring around crash time was the load of the UGM-109Cs on SSN 692 into the tubes for launch.
I kept a log of activities I performed:
Start, no mods, 1 second no pulse (left convoy radar/sonar off)
SSN 647 Pogy, 2x UGM-109Cs against point radar to the north east (from magazine, allocate all)
5 sec time comp, moving VERY fast.slows at 2:02:17 Zulu, when vampire warnings come in at the convoy. Pogy hasn't launched yet.
2:02:42, aircraft launch sounds
2:03:35 SSV Yug attack begins, sunk 2:04:00
2:04:07, strikes hit convoy, popup as merchant sinks.
2:05:01, Pogy launches
CTF 77.4 Targets around Kyluchi
RGM-109C, first time is allocation, last time is completion of launch
2:05:55-2:06:18, target CG 52 x 4 at each of the runway access points
2:06:26-2:06:40, taret CGN 9 x 2 at radar
2:06:48-2:07:02, target DD975 x 2 at radar
2:07:04-2:07:38, target CG53 x8 at each SA-3c Bn
2:07:44-, SSN 692 mission, 2x UGM-109C at radar to the southwest
2:08:15 setup patrol zone N of CTF 77.3, with 3x E-3B, first went airborne w/ radar on at 2:11:02
2:11:05 setup ASW patrol out near convoy using 2 P3s from each group.
2:11:30 -- out of memory, crash P3s not airborne, E-3B still low altitude based upon surface search radar ring.
Ok, I just got to the 29th minute before the same popup as posted in the beginning. The tomahawks were about 20 miles from their first targets =)
Since I am new to this, here are the steps I took:
1. Start menu, load existing scenario, chose the Closing the Kurile Gap, and then side US when that popup showed, apply changes and start.
2. Editor menu, Upgrade scenario to latest.
3. Checked Force Deep-Rebuild, hit the Rebuild Current Scenario button.
I then did a save as under a different name, which is what I had been running to retest. The old .scen file was 1,262KB, the new is 1,685KB. When I load the new one in the editor and go to Editor, Upgrade, it says it is on the latest version.
When I was playing in the editor, I noticed that the USSR side has a large convoy (25 units) near Dolinsk-Sokol AB that moves towards where the Japan side has SS 575. I'm wondering if the sudden spike in memory usage is that sub suddenly detecting that big convoy at the same time US SSN 652 is detecting the flyover of the Badgers/Backfires returning home? Just prior to the fault, those bombers were overflying that sub with radars on so the ESM was picking them up.
Now that I've cheated a bit in looking where everything is, i'm going to try again only this time not launching the tomahawks and sending that E-3B up to where it spots all of that. Other than routine intercept behavior for CAP, that's the only "big change" I can see where a list of sensors/targets would have to be processed.
FYI -- I had been running in "game" mode, and not editor mode.
Running in editor mode, didn't touch anything other than clicking start and changing time compression to 5 seconds, a different stack trace. Occurred at 4mins, 43 seconds in while the opening strike was hitting the convoy.
I suspect there is some massive loops going on pathfinding. This is a massive scenario with a lot of zones and missions. This is one of the scenarios I can't believe some actually put over 3000 units in a game and expect it to work on every machine.
This is a monster scen. It will stress your machine!!
Back when I played it it would lock-up quite often. Especially when a lot of missiles, jamming, etc. was going on. I would just resume from auto save and keep going. I also found that shutting down as many process's and services on my computer increasing virtual memory cashe, and the addition of a SSD plus a water cooler for my CPU helped quite a bit also. (The water cooler and SSD were purchased for other programs that I use...but boy did it help Command run a lot smoother!)
The tomahawks were about 20 miles from their first targets =)
I mentioned it earlier in another thread, but I suspect there is some heavy (too heavy?) number crunching when tomahawks are flying. I've seen it in few other large scenarios. I think it could be either pathfinding combined with range or 2-way datalink and updating done by tomahawk sensors.
Thanks for all of the responses. I have been playing a ton of other scenarios and "mostly" successful (from the community pack). This one is massive, but the concept was also interesting -- it was intended as a two-fold test, one for my machine (my 3 year old machine can still handle it around 2 game-sec/sec on 5 sec time comp) as well as my ability to organize what is going on.
Mikmyk, thanks and i'll shelve this one for a bit.
DeSade, I saw your post about that in another thread so I suspected that as well; however, it still faults without putting tomahawks in the air -- only later, so perhaps a partial explanation?
Dannyp19, my old machine already has the SSD =) It's a machine that I perform number crunching on (GPGPU) for work, so it's not a temp problem. Now, granted command is a 32 bit program so it cannot use all of the memory at the disposal of the processor. I occasionally see a pause where one second takes two when, as you point out, a lot of things are launching or being detected (like the bomber stream returning home). I see the same when one my massive tomahawk strike in Brass Drum hits. I worked out the timing so that my sub and all 3 task groups fire off tomahawks at all free-game Iraqi bases targeting all runway access points and known radars with the missiles arriving within about 30 seconds of each other at all targets (I tried to emulate real life, maximize surprise). When they all hit detection range there is a long pause and what feels like 10,000 detection messages after which I send in my second wave of missiles at the detected SAMs at the same time my airborne SEAD starts firing off the AR missiles. After about 2 minutes of non-stop explosion sounds, it's all over. I just wait about 15-20 game-minutes and I have air superiority because nothing is up except the northern-base aircraft which are at extreme range. It's a lot cheaper in terms of AMRAAM inventory that way and I don't end up with the knife fights where I lose my AAW range advantage.
Just tried this using B581. I was unable to cause a memory exhaustion error. So there is a fair chance that one of our recent RAM-optimizations did the trick. Please give this another try when the next public release is available.
