Workaround or fix for this type of crashlog

[Obi1]

Hi, lately I have been encountering the same type of CTD error in my custom 4.33 campaign.

I know it’s 4.33 and custom stuff and all, but I would just like to ask why this error could be triggered.

I suspected lack off alternate landing fields and I tried adding extra airbases around the map to prevent this happening but it still comes back.
Also I suspect one of the new airplanes added to the map to perhaps triggering the error, but not sure why.

Here’s the crashlog that has always the same lines:

================================== CRASHLOG =====================================
Falcon BMS.exe caused an EXCEPTION_ACCESS_VIOLATION in:
0000000004A130D3 Falcon BMS.exe, AirTaskingManagerClass::FindBestFlight()+2723 byte(s), e:\wip\bms\svn\source\rel-4.33\campaign\camptask\atm.cpp, line 2594
Exception handler called in UnhandledExceptionHandler.
Write to location 0000000000000003 caused an access violation.
Bytes at CS:RIP: C7 04 25 03 00 00 00 03 00 00 00 44 0F BF 46 36

Registers:
RAX=0x0000000000000000 RBX=0x0000000000000000 RCX=0x0000000000000000 RDX=0x0000000004bef7f8
RSI=0x00000000427e138a RDI=0x000000004cf0ffc0 RBP=0x00000000285efbc0 RSP=0x00000000285efac0
RIP=0x0000000004a130d3 FLG=0x0000000000010202
R8=0x0000000000000010 R9=0x0000000000000041 R10=0x0000000000000000 R11=0x0000000000000004
R12=0x0000000000000005 R13=0x0000000000000000 R14=0x0000000000000001 R15=0x0000000000000010
CS=0x0033 DS=0x002B SS=0x002B ES=0x002B FS=0x0053 GS=0x002B

Call Stack:
0033:0000000004A130D3 Falcon BMS.exe, AirTaskingManagerClass::FindBestFlight()+2723 byte(s), e:\wip\bms\svn\source\rel-4.33\campaign\camptask\atm.cpp, line 2594, Parameters(0x00000000465D0000 0x00000000427E138A 0x0000000000000000 0x00000000449538B6)
0033:0000000004A0F2FA Falcon BMS.exe, AirTaskingManagerClass::BuildDivert()+410 byte(s), e:\wip\bms\svn\source\rel-4.33\campaign\camptask\atm.cpp, line 1175+27 byte(s), Parameters(0x000000002A42A930 0x00000000427E1340 0x00000000285EFD59 0x000000002A42A930)
0033:0000000004A0F9C1 Falcon BMS.exe, AirTaskingManagerClass::ProcessRequest()+65 byte(s), e:\wip\bms\svn\source\rel-4.33\campaign\camptask\atm.cpp, line 1324+5 byte(s), Parameters(0x000000002A42A930 0x0000000004AEF057 0x000000000001F400 0x0000000000000000)
0033:0000000004A2FD4B Falcon BMS.exe, FalconMissionRequestMessage::Process()+91 byte(s), e:\wip\bms\svn\source\rel-4.33\falclib\messages\missionrequestmsg.cpp, line 44, Parameters(0x0000000000000000 0x0000000000000000 0x00000000FFFE7960 0x00000000285EFE00)
0033:000000000498ABC1 Falcon BMS.exe, VuMessage::Dispatch()+113 byte(s), e:\wip\bms\svn\source\rel-4.33\vu2\src\vuevent.cpp, line 1118, Parameters(0x0000000010A0EE40 0x00000000427E1340 0x0000000000001FB7 0x0000000004AF1EDC)
0033:0000000004989E67 Falcon BMS.exe, VuMessageQueue::DispatchVuMessage_FromDrain()+199 byte(s), e:\wip\bms\svn\source\rel-4.33\vu2\src\vuevent.cpp, line 393, Parameters(0x0000000010A0EE40 0x0000000000000000 0x0000000000000000 0x0000000000000001)
0033:000000000497DACE Falcon BMS.exe, VuBaseThread::Update()+30 byte(s), e:\wip\bms\svn\source\rel-4.33\vu2\src\vu.cpp, line 140+24 byte(s), Parameters(0x0000000088152E49 0x0000000000000000 0x0000000000000000 0x000000000080007B)
0033:00000000044C10D0 Falcon BMS.exe, HandleCampaignThread()+112 byte(s), e:\wip\bms\svn\source\rel-4.33\campaign\campupd\campaign.cpp, line 2398, Parameters(0x0000000000000000 0x00000000044C1060 0x0000000000000000 0x0000000000000000)
0033:00000000044DA71D Falcon BMS.exe, ThreadUnhandledExceptionWrapper()+109 byte(s), e:\wip\bms\svn\source\rel-4.33\falclib\ehandler.cpp, line 1572+5 byte(s), Parameters(0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000)
0033:0000000004AF6677 Falcon BMS.exe, _callthreadstartex()+23 byte(s), f:\dd\vctools\crt\crtw32\startup\threadex.c, line 376+13 byte(s), Parameters(0x0000000010A048C0 0x0000000000000000 0x0000000000000000 0x0000000000000000)
0033:0000000004AF681E Falcon BMS.exe, _threadstartex()+258 byte(s), f:\dd\vctools\crt\crtw32\startup\threadex.c, line 354+5 byte(s), Parameters(0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000)
0033:0000000076CF59BD kernel32.dll, BaseThreadInitThunk()+13 byte(s), Parameters(0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000)
0033:0000000076E2A2E1 ntdll.dll, RtlUserThreadStart()+33 byte(s), Parameters(0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000)

Hopefully someone can point me in a direction where I need to change something to prevent the error from happening.

Cheers Obi1

[Mav-jp]

TheRe is indeed a very good fix for it -> 4.34

[Obi1]

@Mav-jp:

TheRe is indeed a very good fix for it -> 4.34

So this was a bug in 4.33 ? Is there a workaround to prevent it from happening?
If I know why I can prevent it perhaps.

Btw I use 4.33 and 4.34, so it’s not that I have anything against it.

Cheers Obi1

[Mav-jp]

@Obi1:

So this was a bug in 4.33 ? Is there a workaround to prevent it from happening?
If I know why I can prevent it perhaps.

Btw I use 4.33 and 4.34, so it’s not that I have anything against it.

Cheers Obi1

Yeah the workaround is to click on your 4.34 launcher instead of the 4.33

Joke aside : we will not support 4.33 so don’t expect we will look at your CTD anyway

[Obi1]

I did not ask it to be fixed, just what can trigger this CTD.
What I can change in my .cam file. But I have some ideas already myself so I will experiment with that.
It was a question in general also to fellow modders who perhaps encountered something similar.

[Cloud 9]

Reading what you you have posted is just to ambiguous to even know what you may had done/altered in your campaign file to even make a guess at what the problem is.

You need to remember, crash logs aren’t straight forward to the layman. Sometimes what they say is the result of something else.

Posting a crashlog and then asking how you avoid said CTD is a rabbit hole. Mav-jp or I-Hawk may know but that’s about as far as it goes, no other 3rd party modders will have any clue!

So unless you take the time to completely explain what you have created, I doubt you’ll receive much help. I’ve helped on a ton of issues/CTD’s, reading crash logs(and knowing how they came about) and things of that nature over the years, and I can’t make heads nor tails out of your issue, given the information you’ve provided.

Cheers,

C9

[Obi1]

Thanks C9,

Well this CTD is the only one I am getting and if I remember started seeing them after my latest added squadron. It’s created after around a day into the campaign and can be reproduced always in 2d map. Not sure if it will do so in 3d too, but did not get this CTD in 3d up until now.
It’s a probably a new Su-57 squadron that is causing it as it is quite far away from the frontline and the latest add. Reading the crashlog I was tempted to think it has anything to do with creating flights and calculating possible divert fields.
So I added some extra airbase around the area, but the issue remains.
I deleted this squadron and did not seem to get this CTD anymore, so I will do some more and longer testing to be sure it was this unit and some of it’s characteristics. (long combat range, cap mission)
I might be just guessing but after it’s airbase was at 0% after strike there were no CTD’s anymore. Then there was again 1 around the time the airbase was slowly getting repaired and up and running again (so creating flights for this aircraft again)

I understand that without all the info it’s hard to be able to help, but I just hoped someone already struggled with this type of crash or some developer who knows how this process of creating flights and finding diverts work. So I could indirectly prevent it from happening.

Anyway thanks for at least trying to bear with me.
It’s not a big thing, but would be nice if i could tackle it.

Cheers Obi1

[Cloud 9]

What theater?

C9

[I-Hawk]

@Obi1:

Btw I use 4.33 and 4.34, so it’s not that I have anything against it.

Serious question: What’s the advantage of keep using 4.33? I don’t think 4.34 has anything missed of the 4.33 features.
In a perfect world possibly we could support older versions, but given the amount of active people in BMS team, this isn’t possible I’m afraid.
Hence I strongly suggest to upgrade either the theater/campaign or whatever else it may be that keeps you on 4.33.

[Obi1]

@I-Hawk:

Serious question: What’s the advantage of keep using 4.33? I don’t think 4.34 has anything missed of the 4.33 features.
In a perfect world possibly we could support older versions, but given the amount of active people in BMS team, this isn’t possible I’m afraid.
Hence I strongly suggest to upgrade either the theater/campaign or whatever else it may be that keeps you on 4.33.

-First of all, in 4.33 I still have all the theaters
-Second, I was building a new theater (Libya) that has many mods that won’t be there in 4.34 (cockpits, flyable planes)
-Third, I wanted to finished building this theater in 4.33 before porting it to 4.34
-Fourth, 4.33 has less issues at the moment, so I rather wait until most are ironed out
-Fifth, 4.33 is less taxing on my system, I get higher fps overall.
-Sixth, before 4.34 came out everybody was made to believe that it was the most realistic thing ever, why would it now be obsolete or not allowed to be used by someone.
-Seventh, I just feel more comfortable with all the editing skills needed in 4.33 in contrast to 4.34
-Eight, I encountered these type of things because I liked to learn and create making an own theater on all aspects from scratch, to learn but also to help in finding perhaps new issues to serve others.

I-hawk i really appreciate you and all the devs work and I am already on 4.34 too!

Now just forget about my question, because instead of receiving any helpful tips, i only got the expected answer to just upgrade.
I more feel like doing something wrong then getting support to keep trying.
And instead of wasting more energy in explaining all sorts of other non related things I would like to continue and forget about trying to find help here for awhile.

Cheers Obi1

[I-Hawk]

Well, I can understand your pain, working on a theater and staying on 4.33 for the sake of none-4.34 theaters are indeed valid reasons that I can resemble with. Unfortunately, not much that we can help with, as I understand this is probably a combination of code and data problem, and that may be where comes the point that we can’t help with.

Let’s look at things from BMS Development process POV (Note this is an imaginary scenario just for the example):

Let’s assume that at some point between 4.33 and 4.34, a data Dev in BMS create a new campaign and place a new squadron as you did

The game CTD as in your case and he report the CTD and ask what can be done

A coder come and investigate that CTD, and find a way to fix the code and even improve a few more things at the same area/topic (As it may happen sometimes)

A coder report the issue fixed and commit that code to the 4.34 branch

The data Dev is happy and can continue with his campaign work using the newer EXE with the code fix

Case closed.

So, what just happened? There was an issue (Like zillion others that can happen during development or exploring new things/options that aren’t included or aren’t part of the KTO theater/DB/Campaings), it was reported and fixed internally, a new version was released. From BMS Dev POV, there just isn’t much that can be done, so the first thing you hear as a natural answer is: Upgrade to 4.34 and there will be no such CTD.
For you this answer may sound annoying, but from the other side there is unfortunately no option to keep supporting older versions, a dedicated small team is probably required for that and we don’t have that kind of manpower.

No need to get upset, unfortunately, the only “cure” you can use for now is to try and place that squadron in some different way or different place etc (Sorry but I’m technically pretty far away from that kind of problems and code).

Cheers!

[Cloud 9]

From what I see or can gather, this may have to do with the aircraft, SU-57, that he’s dealing with, it’s the only unusual thing he has mentioned. I could be wrong, but I don’t see any other logical reason for his CTD??

C9

[Obi1]

@I-Hawk:

Well, I can understand your pain, working on a theater and staying on 4.33 for the sake of none-4.34 theaters are indeed valid reasons that I can resemble with. Unfortunately, not much that we can help with, as I understand this is probably a combination of code and data problem, and that may be where comes the point that we can’t help with.

Let’s look at things from BMS Development process POV (Note this is an imaginary scenario just for the example):

Let’s assume that at some point between 4.33 and 4.34, a data Dev in BMS create a new campaign and place a new squadron as you did

The game CTD as in your case and he report the CTD and ask what can be done

A coder come and investigate that CTD, and find a way to fix the code and even improve a few more things at the same area/topic (As it may happen sometimes)

A coder report the issue fixed and commit that code to the 4.34 branch

The data Dev is happy and can continue with his campaign work using the newer EXE with the code fix

Case closed.

So, what just happened? There was an issue (Like zillion others that can happen during development or exploring new things/options that aren’t included or aren’t part of the KTO theater/DB/Campaings), it was reported and fixed internally, a new version was released. From BMS Dev POV, there just isn’t much that can be done, so the first thing you hear as a natural answer is: Upgrade to 4.34 and there will be no such CTD.
For you this answer may sound annoying, but from the other side there is unfortunately no option to keep supporting older versions, a dedicated small team is probably required for that and we don’t have that kind of manpower.

No need to get upset, unfortunately, the only “cure” you can use for now is to try and place that squadron in some different way or different place etc (Sorry but I’m technically pretty far away from that kind of problems and code).

Cheers!

Thanks I-hawk, I fully agree with your answer on this matter. As developer for profession I understand exactly that you want customers to be on the latest version first, because sometimes the current version does things differently so the issue never appears or even the issue was solved already in the meantime.
I guess i got a bit frustrated because nobody seem to pick up that I did not ask or wanted the devs to solve my issue with a codefix, but only find some info or insides what possibly could trigger this CTD.
Looking at the crashlog I immediately figured perhaps picking the right flight or picking the right alternate fields triggers it. But then again why? Perhaps because the airbase is quite far away from the frontline and the plane on this airbase has far reach and long missions or because there need to be free alternate airbases to land.
Those kind of possible things to change something. I understand it was hard given the lack of proper background info from my side. For that I am sorry.

Also like C9 said, I too suspect this SU-57 to act different from other planes, having stats that perhaps ask something impossible when planning missions.
Other possible cause could be the location of the airbase, very remote so longer flights are required.

I will experiment with changing the airplane to another ‘stock’ plane and see if the results are better. Otherwise just remove the squadron or place it on another airbase.

What is positive is that I have 3 different campaigns and the other 2 don’t seem to have this issue so I could check for differences.

Anyway I am happy that things look brighter now and getting the feeling that people are willing to help.

Cheers Obi1

[Cloud 9]

Obi1,

Is this the 128 segment Libya??

C9

[Obi1]

Yes, big size theater why?

[Cloud 9]

@Obi1:

Yes, big size theater why?

Where did you get it?

Because, there is a version out there, which I also have, that claims to NOT be the PMC version, yet it’s identical in it’s original make up and form to that of the PMC Libya.

I know you like messing around with odd ball theaters out there on your own. Just letting you know.

Cheers,

C9