DServer unstable/crashing frequently in 3.005

August 1, 2018

Note in particular:

Quote

We're also working on some changes to the Netcode at a fundamental level to hopefully address some crashes and server load issues. However, these changes need to be thoroughly checked in a Beta version first. Hopefully we'll be able to include them in the next major release assuming they make a positive impact.

Might be a bit of a rough ride at the moment, but hopefully it will get better. I welcome development efforts on DServer, even if it causes crashes during the transition. I only wish they would keep a development track separate from the stable track, but that's too much work for the team to manage two parallel releases, apparently.

August 2, 2018

10 hours ago, -IRRE-Therion said:

Yes, and thinking of it - you provide those servers for public purpose with no fee of charge for the community. This flight sim

also depends on the positive feedback of the hardcore multi players who don't really care about single player mode nor the

campaign system. Not very grateful form them...

While I appreciate the sentiment I don't want this thread to turn into a mud slinging match. Remember the il2 team is small and not all of them speak english, we know at least that they have acknowledged that there was an issue, being that they released a hotfix that lists a possible fix for the dserver crashes and also noted that they are looking into improving the netcode.

@Jason_Williams Can we get an acknowledgement that this issue is on the list of things that need to be looked into? Just a simple yes would be perfect, I know its likely not a simple fix easy to trace down, we would just appreciate the acknowledgement. I have sunk a considerable amount of money into this game both for myself and as gifts for other people so I would think it would be appreciated that our issue has been acknowledged.

August 2, 2018

Absolutely agree, no need for a mudfest, it's just the lack of feedback that wears out on the affected users, in this case server operators.

Can't think of a good reason why there's never been any word on the dreaded "SIM thread message" thing from official side either.

Nevertheless... where have we been?

Ah, next crash:

Aug 01 9:31 PM - uptime 24:17 hours

One more observation:

I have just checked the logs to see how many times which specific mission crashed.

During the past weeks, we are running the very same mission on the Stalingrad map, on all three available seasons (Summer, Autumn, Winter) in random rotation.

From the logs I could check 9 recent crashes.

Crash 1-7 happened on the Autumn map, crash 8 and 9 on the summer map.

No crash on the winter map.

Coincidence or a reference to the underlying issue?

God knows, and maybe - hopefully - devs do.

Mike

Edited August 2, 2018 by SAS_Storebror
Added Seasonal Information

August 2, 2018

Ive seen crashes on all missions, I can't find a pattern to it myself, and if A developer responded I would even give them direct access to my server to investigate if needed... I just want this fixed so I don't have to worry about starting it up again all the time.

August 2, 2018

Also In agreement with DeadMeat0383. As far as I am concerned the IL2 Team has earned the "benefit of the doubt" feature along time ago

Now back to narrowing down the problems I have to report that I have not had any crashes since the last "c" patch. I am running the same sequence of missions as in the "b" patch that used to have those random crashes. The Server has been up since the release with short periods of shutdown to test the stuff below.

On the "SIM thread message": I have managed to narrow down the source (or at least one of the sources). It is coming out of a ground module that contain a ground target area with random air support. Four lines of that message is coming out of that when the mission starts. I am still trying to figure the specific source. It would be more helpful if I know that the error message is coming from one item that is checked by the engine four times before it stops or four different items that get checked once. I am suspecting the later. I anyone want to help I can post the mission with and without the module and the module itself. In the mean time I will keep trying.

Edited August 2, 2018 by II./JG1_Kadin

August 2, 2018

Jul 22 4:09 PM - uptime 3:32 
Jul 22 4:52 PM - uptime 0:43 
Jul 22 5:08 PM - uptime 0:16 
Jul 22 5:25 PM - uptime 0:17 
Jul 24 8:48 AM - uptime 39:23 
Jul 24 9:06 PM - uptime 10:18 
Jul 25 10:01 AM - uptime 12:55 
Jul 25 6:40 PM - uptime 0:36 
Jul 25 6:48 PM - uptime 0:08 
Jul 25 7:59 PM - uptime 1:11
Jul 26 10:05 PM - uptime 26:06 
Jul 26 10:07 PM - uptime 0:02 (!!!) 
Jul 26 10:11 PM - uptime 0:04 (!!!) 
Jul 28 4:45 PM - uptime 42:34
Jul 31 9:14 PM - uptime 76:29 hours
Aug 01 9:31 PM - uptime 24:17 hours

I'd say a typical crash happens somewhen between 6:30 PM and 10:15 PM UTC on weekdays, while on weekends they may occur earlier.

This is the 'after eight to midnight' period in Europe, and I guess these are the peak hours on the FAC server, aren't they?

Maybe user activity triggers something which leads to the crash, and if Kadin doesn't have crashes, it may indicate that his missions lack something that FAC and Unprofessionals missions do have.

Edited August 2, 2018 by sniperton

August 3, 2018

Next crash on our server was at

Aug 03 12:55 AM - uptime 27:24 hours

on the "Autumn" mission again (remember last two times it was "Summer", we yet have to see the "Winter" mission crash).

What's been different this time is that the Windows Error Reporting wasn't triggered, instead DServer.exe just died "silently" without throwing any exception.

No sorry sniperton, the crashes are completely unrelated to server activity or peak hours.

We see both crashes when many people are online and crashes when no one is online at all.

It doesn't even have any influence on the uptime whether or not the activity inbetween was high or low.

Not at all.

If crashes group up around a certain time of a day, IMHO this rather means that the "other end of the rope" (Master Server?) has peak time issues at that time.

Concerning the "SIM thread message" thing, I can see several different incarnations of this message in the logs.

The most reproduceable one is right when mission rotation is in progress, and it usually comes six times in a row:

18:46:49	
=====	Rotation is in progress (2 seconds to wait before loading)	=====
18:46:49	Unhandled SIM thread message: 60
18:46:49	Unhandled SIM thread message: 60
18:46:49	Unhandled SIM thread message: 60
18:46:49	Unhandled SIM thread message: 60
18:46:49	Unhandled SIM thread message: 60
18:46:49	Unhandled SIM thread message: 60
18:46:51	... Server name 'The Flying Ass Clowns'
18:46:51		Loading mission (...)

Usually means that it can also appear more than six times...

01:13:27	
=====	Rotation is in progress (2 seconds to wait before loading)	=====
01:13:27	Unhandled SIM thread message: 60
01:13:27	Unhandled SIM thread message: 60
01:13:27	Unhandled SIM thread message: 60
01:13:27	Unhandled SIM thread message: 60
01:13:27	Unhandled SIM thread message: 60
01:13:27	Unhandled SIM thread message: 60
01:13:27	Unhandled SIM thread message: 60
01:13:27	Unhandled SIM thread message: 60
01:13:27	Unhandled SIM thread message: 60
01:13:27	... chat log reopened
01:13:29	... Server name 'The Flying Ass Clowns'
01:13:29		Loading mission (...)

...or even not at all...

02:24:03	
=====	Rotation is in progress (2 seconds to wait before loading)	=====
02:24:06	... Server name 'The Flying Ass Clowns'
02:24:06		Loading mission (...)

We have missions with no "SIM thread message" log line ever plotted at all, then we have singles...

01:04:11	... chat log reopened
01:04:25	Unhandled SIM thread message: 60
01:04:26	... chat log reopened

...doubles...

00:46:55	... chat log reopened
00:47:05	Unhandled SIM thread message: 60
00:47:05	Unhandled SIM thread message: 60
00:47:10	... chat log reopened

...and quadruples.

01:07:41	... chat log reopened
01:07:46	Unhandled SIM thread message: 60
01:07:46	Unhandled SIM thread message: 60
01:07:46	Unhandled SIM thread message: 60
01:07:46	Unhandled SIM thread message: 60
01:07:56	... chat log reopened

Quadruples seem to be the "biggest" form of the phenomenon. Sometimes in the log there seem to be quintuples, but looking closer, you see that it's just a single that huddled up to a quadruple:

00:12:23	... chat log reopened
00:12:24	Unhandled SIM thread message: 60
00:12:28	Unhandled SIM thread message: 60
00:12:28	Unhandled SIM thread message: 60
00:12:28	Unhandled SIM thread message: 60
00:12:28	Unhandled SIM thread message: 60
00:12:38	... chat log reopened

Even quadruples sometimes snuggle up:

23:02:33	... chat log reopened
23:02:36	Unhandled SIM thread message: 60
23:02:36	Unhandled SIM thread message: 60
23:02:36	Unhandled SIM thread message: 60
23:02:36	Unhandled SIM thread message: 60
23:02:40	Unhandled SIM thread message: 60
23:02:40	Unhandled SIM thread message: 60
23:02:40	Unhandled SIM thread message: 60
23:02:40	Unhandled SIM thread message: 60
23:02:48	... chat log reopened

Interestingly, triples don't seem to exist. If we spot them, they are singles huddled up with doubles:

18:07:44	... chat log reopened
18:07:44	Unhandled SIM thread message: 60
18:07:45	Unhandled SIM thread message: 60
18:07:45	Unhandled SIM thread message: 60
18:07:59	... chat log reopened

To sum things up, we see all kind of combinations of chained up occurrances:

21:49:29	... chat log reopened
21:49:43	Unhandled SIM thread message: 60
21:49:43	Unhandled SIM thread message: 60
21:49:43	Unhandled SIM thread message: 60
21:49:43	Unhandled SIM thread message: 60
21:49:44	... chat log reopened
21:49:54	Unhandled SIM thread message: 60
21:49:54	Unhandled SIM thread message: 60
21:49:59	... chat log reopened
21:50:04	Unhandled SIM thread message: 60
21:50:14	... chat log reopened

I must admit I fail to see any pattern in here.

Mike

Edited August 3, 2018 by SAS_Storebror
information about triples corrected

August 3, 2018

Now the question remains why Kadin doesn't have crashes while he is still having the SIM error message, which might be either related or unrelated. Would also be intriguing to learn if others can see any master server peak hours pattern in their crash logs. And perhaps you could stop map rotation until it also crashes on the Winter map, just to prove that the issue has nothing to do with the map.

August 3, 2018

I think that we already know that the SIM thread message thing is unrelated to the Server crash.

At least I know, since I have had multiple crashes now where there was no single time when the SIM thread message log line appeared.

Stopping the map rotation would surely clarify the Winter map thing, however I'm just not about to kill our server just to prove something that probably doesn't move the whole matter forward a single micrometer.

If a dev would step down off his pedestal to let us know which check on our side would help them to further tackle down the issue, I'll try to make that happen immediately, but without any hint from official side, all I'm ready to do is to keep the ball rolling.

Mike

Edited August 3, 2018 by SAS_Storebror

August 3, 2018

Still no crashes.

As Storebror mentions, all the error messages are on the loading of the missions that contain multiples versions of the module I mention above. Depending on the number of modules times 4. That is how I managed to narrow it down to a single module. So far it does not seem to related to objects activated or not, map type or season. I am investigating MCUs.

It has recently been mentioned that certain external files (e.g mp3) cannot contain spaces or apostrophes. I had 3 music files like that which were corrected once the c patch was released.

August 3, 2018

@SAS_Storebrorif you are using SturmovikServerControp, make sure you disable the feature that forces updates of the chat log. I noticed that can cause crashes. I’ll let you know what setting that is when I get home after work.

August 3, 2018

I know what setting it is (ChatLogUpdateEnabled IIRC), however I didn't notice this causing any crashes as the crash frequency was the very same before I used SturmovikServerControl.

Nevertheless, I'll disable that feature.

Mike

Edited August 3, 2018 by SAS_Storebror

August 3, 2018

2 hours ago, SAS_Storebror said:

all I'm ready to do is to keep the ball rolling.

Clear, and I'm fine with it, after all, that needle in the haystack is just a minor annoyance every 2nd or 3rd day. Shit happens, that's all

August 4, 2018

Finally, I got something!! The "Unhandled SIM thread message: 60" error is coming from any AI multicrew planes. The planes do NOT have to be "enabled" and two error lines are coming from each multicrew plane irregardless of the number of crew members. So the Bf110, He111, Pe or A20, they all send TWO error lines.

Edited August 4, 2018 by II./JG1_Kadin

August 4, 2018

Great work @II./JG1_Kadin ill pass this onto my mission builder, although it won't make much difference i don't think

August 4, 2018

Unsure if my user-only (and tank-user focussed) perspective will contribute anything useful, but I'll try.

Just from observing which actions people running servers appear to have taken as a result of the crashes:

Action Dogfight and Tanks has been down for some days, and when it comes back up, runs for a while and then crashes.

EU off. 1CGS Planes and Tanks now runs "wo_tanks" missions only.

Servers which generally don't run tank-containing missions, don't appear to have been affected so much.

WoL rarely had tank-containing missions, but now seems to have none.

Coconut's servers sometimes feature tank battles, but rarely are there many player-controlled tanks. Also there are none of the new tanks.

Some tank-containing (with new tanks) servers, such as Battle Fieldscom UK1 seem to stay up, but hardly have many tank players, so this may not be a contradiction.

Based on all that, I had believed most server admins had fingered tanks, or the new tanks, to be associated with the crashes, yet in this thread, the focus of the search for the cause doesn't seem to go in that direction. Was I on the wrong track?

Edited August 4, 2018 by stupor-mundi

August 4, 2018

"Action Dogfight and Tanks has been down for some days, and when it comes back up, runs for a while and then crashes."

Like me they probably dont have an automated way of restarting the dserver software but they may have less ability to jump on and restart it.

"EU off. 1CGS Planes and Tanks now runs "wo_tanks" missions only."

I have a couple of no tanks missions on my server and they had crashed just as often, not to say there isnt a link but I havent been able to replicate this particular theory.

Servers which generally don't run tank-containing missions, don't appear to have been affected so much.

As mentioned above, ive not seen a correlation between missions with and without tanks and the crashing, and a lot of servers likely have more automated ways of starting dserver back up when it crashes (im sure I could implement it too but I just don't have the time to put into making it happen).

"WoL rarely had tank-containing missions, but now seems to have none."

WoL im 90% sure has an automated mission restart implemented, but also WoL doesnt exactly have the best track record of making new features and vehicles available in their missions in a timely manner so im not sure this is a good example.

"Coconut's servers sometimes feature tank battles, but rarely are there many player-controlled tanks. Also there are none of the new tanks."

@coconut is probably a better person to respond to this and might have insight on the theory of the tanks being the cause.

"Some tank-containing (with new tanks) servers, such as Battle Fieldscom UK1 seem to stay up, but hardly have many tank players, so this may not be a contradiction."

Yep thats exactly the point, at this stage we have been completely unable to nail down a trigger or cause for the random crashes. Nor have we been able to reliably replicate the crashes, and without replication its hard to narrow down the cause.

On that note, my server has been running for over a day without a crash now ?

Edited August 4, 2018 by DeadMeat0383

August 5, 2018

17 hours ago, II./JG1_Kadin said:

The "Unhandled SIM thread message: 60" error is coming from any AI multicrew planes. The planes do NOT have to be "enabled" and two error lines are coming from each multicrew plane irregardless of the number of crew members. So the Bf110, He111, Pe or A20, they all send TWO error lines.

Thanks a lot Kadin, so that's the reason - or at least one of - for the doubles. Now we still have the singles and quadruples

Crashes related to tanks... interesting theory.

Let's see what we have at The Flying Ass Clowns.

First off, we've had two crashes last night:

Aug 04 7:33 PM - uptime 42:48 hours

Aug 04 10:06 PM - uptime 2:33 hours

...lo and behold, the 7:33 PM crash was the first Winter map crash (the other one was Autumn again) - hooray, celebrate!

Let's look at the end of the logs of our missions, latest first, to see where there's something tank related in there:

Aug 04 10:06 PM crash:
T:575033 AType:12 ID:475136 TYPE:SPAD 13.C1 COUNTRY:101 NAME:Spad XIII PID:-1 POS(105215.391,111.877,87116.656)
T:575033 AType:12 ID:774144 TYPE:BotPilot_Spad13 COUNTRY:101 NAME:BotPilot_Spad13 PID:475136 POS(105215.227,111.699,87116.500)
T:575033 AType:4 PLID:475136 PID:774144 BUL:400 SH:0 BOMB:0 RCT:0 (105215.391,111.877,87116.656)
T:575041 AType:13 AID:594944 COUNTRY:101 ENABLED:1 BC(0,3,2)
Tank related: NO

Aug 04 7:33 PM crash:
T:454561 AType:13 AID:592896 COUNTRY:201 ENABLED:1 BC(0,0,0)
T:454590 AType:12 ID:775184 TYPE:KV-1s ChTZ(1943) COUNTRY:101 NAME:KV1 PID:-1 POS(96445.977,91.896,82386.672)
T:454590 AType:12 ID:515088 TYPE:BotDriver_KV1 COUNTRY:101 NAME:BotDriver_KV1 PID:775184 POS(96443.938,92.696,82386.453)
T:454590 AType:10 PLID:775184 PID:515088 BUL:0 SH:0 BOMB:0 RCT:0 (96445.977,91.921,82386.672) IDS:a4a28a30-5b9e-409a-9d95-2a492ea685b9 LOGIN:1fbb56cd-3fb7-4e6e-809a-7a1cd292a1ba NAME:ST_Malesan TYPE:KV-1s ChTZ(1943) COUNTRY:101 FORM:0 FIELD:0 INAIR:1 PARENT:-1 ISPL:1 ISTSTART:1 PAYLOAD:0 FUEL:0.000 SKIN: WM:0 
Tank related: YES (last lines refer to KV-1)

Aug 03 12:55 AM crash:
T:576955 AType:4 PLID:819200 PID:442368 BUL:2800 SH:0 BOMB:0 RCT:0 (95433.320,1528.296,76588.047)
T:576955 AType:12 ID:763904 TYPE:Spitfire Mk.IXe COUNTRY:101 NAME:Spitfire IXe PID:-1 POS(104654.344,112.283,86329.820)
T:576955 AType:12 ID:909312 TYPE:BotPilot_Spit9 COUNTRY:101 NAME:BotPilot_Spit9 PID:763904 POS(104653.039,111.927,86329.813)
T:576955 AType:4 PLID:763904 PID:909312 BUL:740 SH:0 BOMB:0 RCT:0 (104654.344,112.283,86329.820)
Tank related: NO

Aug 01 9:31 PM crash:
T:576921 AType:16 BOTID:750616 POS(105357.570,111.196,86546.289)
T:576923 AType:16 BOTID:842775 POS(94459.359,160.379,75066.406)
T:576924 AType:4 PLID:654361 PID:800793 BUL:0 SH:0 BOMB:0 RCT:0 (0.000,0.000,0.000)
T:576929 AType:16 BOTID:800793 POS(94436.992,164.530,75254.672)
Tank related: YES (BOTID:800793 is T-34)

Jul 31 9:14 PM crash:
T:587609 AType:4 PLID:1056768 PID:696320 BUL:600 SH:0 BOMB:10 RCT:0 (82298.898,4988.423,81607.750)
T:587609 AType:12 ID:539648 TYPE:Yak-1B ser.127 COUNTRY:101 NAME:Yak-1b Ser.127 PID:-1 POS(105171.023,111.900,87089.148)
T:587609 AType:12 ID:781312 TYPE:BotPilot_LaGG3 COUNTRY:101 NAME:BotPilot_LaGG3 PID:539648 POS(105170.344,111.928,87088.672)
T:587609 AType:4 PLID:539648 PID:781312 BUL:360 SH:0 BOMB:0 RCT:0 (105171.023,111.900,87089.148)
Tank related: NO

Jul 28 4:45 PM crash:
T:354077 AType:16 BOTID:332825 POS(96022.430,100.515,81314.594)
T:354079 AType:16 BOTID:599055 POS(94149.211,159.294,73999.406)
T:354083 AType:2 DMG:1.000 AID:-1 TID:841743 POS(94147.914,158.732,73999.281)
T:354085 AType:3 AID:-1 TID:841743 POS(94147.914,158.732,73999.281)
Tank related: YES (BOTID:599055 is PzIII)

Jul 26 10:11 PM crash:
T:574334 AType:4 PLID:437248 PID:899072 BUL:1620 SH:0 BOMB:0 RCT:0 (104657.000,111.883,86435.031)
T:574334 AType:12 ID:302080 TYPE:Il-2 mod.1942 COUNTRY:101 NAME:Rake PID:-1 POS(120636.000,250.088,131345.797)
T:574334 AType:12 ID:701440 TYPE:BotPilot_Il2 COUNTRY:101 NAME:BotPilot_Il2 PID:302080 POS(120636.422,250.381,131346.438)
T:574334 AType:4 PLID:302080 PID:701440 BUL:1580 SH:0 BOMB:4 RCT:0 (120636.000,250.088,131345.797)
Tank related: NO

Jul 26 10:07 PM crash:
T:3673 AType:12 ID:194563 TYPE:T-34/76 STZ(1942) COUNTRY:101 NAME:T34 PID:-1 POS(96445.781,92.211,82386.648)
T:3673 AType:12 ID:195587 TYPE:BotDriver_T34 COUNTRY:101 NAME:BotDriver_T34 PID:194563 POS(96444.406,92.811,82386.750)
T:3673 AType:10 PLID:194563 PID:195587 BUL:0 SH:0 BOMB:0 RCT:0 (96445.781,92.266,82386.648) IDS:a2c53c09-f320-4f9e-a4d3-3e0d4a054f15 LOGIN:54010b30-950a-46b7-999d-f4b1d856f75b NAME:AeroAce TYPE:T-34/76 STZ(1942) COUNTRY:101 FORM:0 FIELD:0 INAIR:1 PARENT:-1 ISPL:1 ISTSTART:1 PAYLOAD:29 FUEL:0.000 SKIN: WM:0 
T:0 AType:15 VER:17
T:4730 AType:22 PID:194563 POS(96441.094, 91.936, 82386.109)
Tank related: YES (last lines refer to T-34)

Jul 26 10:05 PM crash:
T:645 AType:20 USERID:a54efbbc-c70c-424d-966d-6cb52fe5a1aa USERNICKID:ce80d746-efb6-4a5e-8d7a-6db98b20d45f
T:1447 AType:12 ID:194562 TYPE:T-34/76 STZ(1942) COUNTRY:101 NAME:T34 PID:-1 POS(96445.781,92.206,82386.648)
T:1447 AType:12 ID:195586 TYPE:BotDriver_T34 COUNTRY:101 NAME:BotDriver_T34 PID:194562 POS(96444.406,92.806,82386.750)
T:1447 AType:10 PLID:194562 PID:195586 BUL:0 SH:0 BOMB:0 RCT:0 (96445.781,92.266,82386.648) IDS:a2c53c09-f320-4f9e-a4d3-3e0d4a054f15 LOGIN:54010b30-950a-46b7-999d-f4b1d856f75b NAME:AeroAce TYPE:T-34/76 STZ(1942) COUNTRY:101 FORM:0 FIELD:0 INAIR:1 PARENT:-1 ISPL:1 ISTSTART:1 PAYLOAD:0 FUEL:0.000 SKIN: WM:0 
Tank related: YES (last lines refer to T-34)

Jul 25 7:59 PM crash:
T:574307 AType:4 PLID:408650 PID:439370 BUL:1308 SH:0 BOMB:0 RCT:0 (105492.813,194.553,85441.859)
T:574307 AType:4 PLID:485451 PID:341067 BUL:0 SH:0 BOMB:0 RCT:0 (105013.508,112.059,86937.563)
T:574311 AType:16 BOTID:341067 POS(105010.516,111.955,86935.781)
T:574314 AType:16 BOTID:439370 POS(105509.016,199.294,85426.109)
Tank related: NO

Jul 25 6:48 PM crash:
T:210317 AType:1 AMMO:explosion AID:1368084 TID:1393664
T:210318 AType:1 AMMO:SHELL_GER_20x82_HE AID:1368084 TID:1393664
T:210320 AType:1 AMMO:explosion AID:1368084 TID:1393664
T:210338 AType:13 AID:688128 COUNTRY:101 ENABLED:1 BC(0,11,4)
Tank related: NO

Jul 25 6:40 PM crash:
T:15270 AType:12 ID:401417 TYPE:BotGunner_Bf110G2 COUNTRY:201 NAME:BotGunner_Bf110G2 PID:400393 POS(99066.422,92.305,51926.016)
T:15270 AType:3 AID:-1 TID:401417 POS(99062.859,100.203,51919.992)
T:15278 AType:16 BOTID:394249 POS(99068.742,98.440,51931.566)
T:15290 AType:6 PID:393225 POS(99066.594, 99.266, 51926.984)
Tank related: NO

12 crashes within 11 days since 3.005c came out, 5 of them have tank related things at the end of the logs, 7 don't.

No clear picture if you ask me.

Mike

August 5, 2018

Note that logs are incomplete when DServer crashes. They are updated once (twice?) per minute. If the server crashes quickly enough after the spawn, that might not be visible from the logs.

I believe tanks were a cause for crashes before 3.005c, not sure after that.

August 5, 2018

If tanks were a known issue before 3.005c (I never saw any dev statement telling so) I'd be wondering why they let us struggle with such issues for so long now.

Removing all tanks from any mission definitely is no feasible workaround.

It breaks mission logic and for certain servers it would completely kill the objectives.

I could deal with temporarily removing player driveable tanks, but that seems unrelated.

Mike

August 5, 2018

It was known by certain players/server owners, devs never went into details about the source of crashes. And by tanks, I meant player-controlled tanks, not the regular tanks.

August 5, 2018

[re: tanks responsible?]

I wonder what DED's point of view is on the issue, since they did remove tanks from their eu official 1 cgs planes and tanks.

I've spent a fair amount of time on there flying, and haven't experienced a crash since they removed the tanks, but that may not be statistically relevant.

OTOH, action dogfight and tanks came back on yesterday for some hours, and I sucked up the maximum time tanking I possibly could, during which occurred 2 or 3 crashes.

If the player controlled tanks are considered off-the-hook as a likely cause, please bring back the tanks. PLEEEEZ.

Must... Drive.... Tank.... Bang! Boom!

Edited August 5, 2018 by stupor-mundi

August 8, 2018

Funny thing is that even though nothing changed, our server is running for about 90 hours without crashes now.

I'll keep my fingers crossed.

Mike

August 8, 2018

Either pure luck, or an indication that the Master Server may have had its role in the crashes. Anyway, fingers crossed

Edit: Crash again shortly before 9 PM UTC at FAC. ~~I was alone flying LW against 5 enemies, and I'm almost sure nobody was selecting anything when the crash occurred~~. (The crash occurred a few minutes after mission rotation whenI was returning from my first sortie. Sortie results were kept in the stats.)

Edited August 9, 2018 by sniperton
Crash again

August 9, 2018

Crossing the fingers didn't help much, we have the next two crashes:

Aug 08 08:52 PM - uptime 94:46 hours

Aug 08 11:16 PM - uptime 2:24 hours

Now the interesting part of these two crashes is that we've monitored the system status in parallel, and at the time of the crashes there were 3 (first crash) / 2 (second crash) DServer.exe processes running. At the moment I have no clue what might cause multiple DServer.exe processes to spawn.

Mike

August 9, 2018

Sounds like positive bug tracking progress in finding a common link, if nothing else ?

Cheers, Dakpilot

August 11, 2018

No recent crashes of the Dserver.exe thankfully, however ive had issues with one of the missions on the server causing the server to show up but to kick players back to the menu as soon as they try join, so ive been restarting the server a lot recently anyway which kind of ruins any data that I could gather anyway.

August 11, 2018

Yesterday for the first time in my IL-2 life, I've suddenly lost connection to our server as a client side issue.

We've been playing together with two players, I've been the only one to get booted.

My Internet connection was fine (been using Teamspeak in parallel, no interruption, checked the router, no interruption) as was the server's connection.

My connection to the server was fine as well all the time (remote desktop open in parallel), it's just been the IL-2 Client <-> Server connection that dropped all of a sudden.

This reminded me of one very nasty feature of IL-2 Great Battles: Tons of logfiles, but not a single useful one.

That's odd. We could track so many issues if we just had logs like we do e.g. in IL-2 1946. But we don't.

On the same note, am I the only one who has to clear the editor in the forum's "reply" field each and every time?

Any time I enter the "reply" field, I get some random content thrown in with a bottom line saying "your previous content has been restored" - very annoying.

Mike

August 11, 2018

On 8/9/2018 at 1:08 PM, SAS_Storebror said:

Now the interesting part of these two crashes is that we've monitored the system status in parallel, and at the time of the crashes there were 3 (first crash) / 2 (second crash) DServer.exe processes running. At the moment I have no clue what might cause multiple DServer.exe processes to spawn.

Just in case this might be related, it's really a wild guess:

On one of the recent tank missions I was on (one that eventually crashed), I was shot at, and a kill message came up.

However my tank still seemed to be working. I looked out the hatch, and saw some tank parts, like the gun and the hatch, in the broken, charred state, but also in the unbroken state, i.e. duplicate parts. I was able to continue on.

On this mission and others, I observed tanks shooting at me, the shots fractions of a second apart, much faster than you could reload, and on very slightly different trajectories. Could these be symptoms of multiple DServer processes running?

August 11, 2018

Is it (theoretically or practically) possible that (1) a duplicate process can spawn duplicate objects (2) eventually leading to a crash?

As to the disconnection issue, I've already had some, but in my case it couldn't be ruled out that all the fuss was due to my ISP. Now that Mike also had one, we know it was not necessarily due to loss of physical connection. Still it seems to be an independent issue, having nothing to do with crashes.

Anyway, crashes do not bother me a lot, Il-2 at FAC is still fun.

August 12, 2018

7 hours ago, sniperton said:

Is it (theoretically or practically) possible that (1) a duplicate process can spawn duplicate objects (2) eventually leading to a crash?

As to the disconnection issue, I've already had some, but in my case it couldn't be ruled out that all the fuss was due to my ISP. Now that Mike also had one, we know it was not necessarily due to loss of physical connection. Still it seems to be an independent issue, having nothing to do with crashes.

Anyway, crashes do not bother me a lot, Il-2 at FAC is still fun.

Performance monitoring doesnt give any indication of a system overload, nor are there any indicators for the client (server overloaded messages) so I doubt its a case of dupilate objects, the crashes seem to have stopped being frequent now, I havent seen a crash yet since I removed the missions causing the connection issues (unrelated to the crashes).

24 Hours so far with no crash

August 12, 2018

Need a favor, Gentlemen. As I stated a few days back no crash has happened on my Dedicated Server so far. However as of today, I cannot check on the server status. I am no physically present at location of the server and cannot check on the PC status through "Teamviewer". Not sure if "TeamViewer" crashed or the whole PC.

Is it possible for anyone to check if "Kadin Dedicated" is posted in the list of IL2 servers? If yes, could post the IP?

Much appreciate any info.

August 12, 2018

Server is not listed at the moment

August 12, 2018

And I jinxed it, it crashed today.

Looks like it crashed an hour ago

=====	Rotation is in progress (2 seconds to wait before loading)	=====
11:03:02	Unhandled SIM thread message: 60
11:03:02	Unhandled SIM thread message: 60
11:03:04	... Server name 'The Unprofessionals'
11:03:04		Loading mission 'Multiplayer/UP_Serv_Mis_10\Winter\dawn\UP_Serv_Mis_10_Summer_Dawn.msnbin' (Multiplayer/UP_Serv_Mis_10\Winter\dawn\UP_Serv_Mis_10_Summer_Dawn)...
11:03:04		Server listener IP = '192.168.1.14'
11:03:10	... Mission loaded successfully

August 12, 2018

Thanks Therion, It was a power outage. I got it shorted out for now. The Server should be up again.

August 18, 2018

I almost thought that crashing time was over, but yesterday we got it again, two times, and this time in another "special" way:

Aug 17 6:59 PM - uptime 211:43 hours

Aug 17 7:00 PM - uptime basically none - the DServer never managed to get up completely

Both a new positive (211 hours 43 minutes) and a negative (ZERO) record for DServer stability

1st crash happened on Winter map, 2nd crash on Autumn map (well sort of, as it never really played in that instance).

Mike

August 19, 2018

I have been averaging around 1-2 days before it crashes.

Still not able to keep it stable.

August 20, 2018

I understand your frustration, but from the user's point of view a single crash after 48 hours is nothing. I don't say it's nothing, I only say it feels nothing. Statistically a server crash is as frequent as a disco. Both are annoying, true, but I could name a few bugs which are even more annoying.

August 20, 2018

23 minutes ago, sniperton said:

I understand your frustration, but from the user's point of view a single crash after 48 hours is nothing. I don't say it's nothing, I only say it feels nothing. Statistically a server crash is as frequent as a disco. Both are annoying, true, but I could name a few bugs which are even more annoying.

Except its not always a single crash in 48 hours, and when a server crashes it affects all the players that were playing on that server at the time and any users who wanted to play on that server. There are players (such as myself for example) that only play multiplayer, and this issue was not present prior to 3.005.

I don't think you understand our frustration fully, we run these servers at our own cost so we can support the multiplayer community, when the server is crashing we are not able to give the level of service we would expect to be able to give. When the server crashes that can be up to 84 players effected by one crash that is outside our control and I at least feel responsible for the server not being stable just as I take responsibility for issues, bugs and poor design of missions that run on my server.

August 20, 2018

Most frustrating for server providers. This should be considered a serious problem facing IL2 multiplay. ?

Perhaps this is why the developers don't run an official server themselves.

DServer unstable/crashing frequently in 3.005

Recommended Posts

coconut

DeadMeat0383

SAS_Storebror

DeadMeat0383

II./JG1_Kadin

sniperton

SAS_Storebror

sniperton

SAS_Storebror

II./JG1_Kadin

coconut

SAS_Storebror

sniperton

II./JG1_Kadin

DeadMeat0383

stupor-mundi

DeadMeat0383

SAS_Storebror

coconut

SAS_Storebror

coconut

stupor-mundi

SAS_Storebror

sniperton

SAS_Storebror

Dakpilot

DeadMeat0383

SAS_Storebror

stupor-mundi

sniperton

DeadMeat0383

II./JG1_Kadin

THERION

DeadMeat0383

II./JG1_Kadin

SAS_Storebror

DeadMeat0383

sniperton

DeadMeat0383

Thad

Please sign in to comment

Browse All

Activity