I'd guess your server is 32bit and is just affected by the 32bit crashing that we had pre-hotfix.
So your issue should be gone by now.

Fixed in the hotfix.

The last log in that file is from december, and back then your game still ran fine.
There is nothing usable in that log.

In order to figure out what actually causes the crash we need your crashlogs.
Please follow this guide and upload the report log https://feedback.bistudio.com/w/ft_a3_howto/gamecrash/

Load server on latest 64-bit performance binary (2.08.149057)

Why do your repro steps say to run 64bit, but your logs say you are running 32 bit stable.

Windows 10 has some issues with USB Headsets, and your crashes look exactly like that.
And

Selected Audio Output: Headset Earphone (2- Arctis 7 Chat) - Channels: 1, Freq: 48000

That looks like a USB Headset for me.
If you can somehow get your Audio output not through USB, that should fix your crashing.

I need the actual crash report. Your text doesn't have sufficient info to tell what actually happened.
Follow this guide and add the report log https://feedback.bistudio.com/w/ft_a3_howto/gamecrash/

marker types are not just a texture. They have other properties like shadow/color/size/name/icon.
And atleast one place in engine, and two mods I know expect it to actually be the name of a config class.

Added a error message that tells when too large for 2.10

Okey I just tested it, even with Valves "200 MiB" limit, I can still upload 800MiB large mission files if they compress very well.
And if I fill them with uncompressible data, the limit seems to be around 400MiB.

so the total weight is reduced to 250 MO

Reproducibility: Have Not Tried

It crashed (because it ran out of memory) trying to print this error message:

Shameless bump. I also remade and reworded the ticket entirely.

You are running 32bit Arma.
Please use 64bit Arma instead, in Arma Launcher under Parameters its the "Platform" option right at the top of the favorites.
Please switch it over.

Thank you.. looking forward to the next branch and will report back if it still crashes after that.

Actually, we have experimental fixes for this issue on profiling branch. They are experimental and thus not enabled on the main build, but that would probably cause this crash to not happen.

The report you sent doesn't show a hang (freeze) it is a crash.
It crashed because the unit was in a group that had no group leader. I fixed it.
But its a crash not a hang as you said, maybe there are more mdmp's? (Please create a new ticket if so)

Fixed next dev branch or 2.10 update

When you visit the link, first thing it does is a HTTPS redirect.
I don't see a security risk here (Unless someone knowing that you are using steam is a security risk to you), but it should still be changed.

Yeah, poorman's database basically, you can always encrypt data on the server and save on client if you want to make it harder to manually edit

This is really, trully, a godsend! Thank you KK!

I usually use the in-game publisher as my mission is simple/alone, and the A3 publisher from Arma Tools is apparently used for campaign and addons.
I have checked the logs but I haven't found any solutions related.

I keep trying, but without sucess

did you check logs from A3 publisher yet?

I can confirm this with attached scenario.
With any anti-tank weaponry (the Missile Specialist (AT) I am using does not use a PCML), the soldier refuses to engage any vehicle at 100m or 250m.
The AI is set to Open Fire (Engage at Will), and has a Destroy waypoint set on the vehicle in question.

This was supposed to be fixed already!

Would be quite useful considering scripting missions that deal with mines is currently a pain in the "rear". =)

rev 149085 should be able to create it again

If I remember correctly creating a rope from and to the same object was crashing the game before. Maybe that is why it was changed?

In T126030#2288662, @johnb43 wrote:

Testing some more today (with one self-hosted server (host), other client) revealed that if the locality of the AI is changed, it fixes this bug - but only for the PC it was set local to.
So in my case it made it possible to pick up items from a dead body local to my connected client, but from my host I couldn't pick anything up from that body anymore.
When I made the body local to the host again, I could pick stuff up on the host again, but not from the connected client.

With the previous discoveries, I'm guessing it's some sort of locality issue not being correctly synced across all connected PCs.

Testing some more today (with one self-hosted server (host), other client) revealed that if the locality of the AI is changed, it fixes this bug - but only for the PC it was set local to.
So in my case it made it possible to pick up items from a dead body local to my connected client, but from my host I couldn't pick anything up from that body anymore.
When I made the body local to the host again, I could pick stuff up on the host again, but not from the connected client.

https://community.bistudio.com/wiki/missionProfileNamespace
https://community.bistudio.com/wiki/saveMissionProfileNamespace
https://community.bistudio.com/wiki/isMissionProfileNamespaceLoaded
https://community.bistudio.com/wiki/Description.ext#missionGroup

This sounds very much like a fix Ondra did late in A2/OA - maybe it wasnt merged?

anyone?

Sure, this can work.

Perhaps mission config param to override mission name? (not real mission name but name used for the file)

Are new commands isMissionProfileNamespaceLoaded, missionProfileNamespace and saveMissionProfileNamespace result of this ticket? If so, how are they connected to the mission itself? Through the mission filename? If so, then it won't fit for our purposes because we use different mission filenames for different communities (to avoid mission re-download when switching servers) like:
KingOfTheHill_by_Sa-Matra_for_CODE4.Altis.pbo
KingOfTheHill_by_Sa-Matra_for_ARMASU.Altis.pbo
but we need a namespace accessible between these different mission files but within our mission's "universe".

Fixed in Hotfix 2.08!

Thank you for reporting the issue.
I was able to confirm it, and we will see what we can do.

_trig setTriggerActivation ["ANY", "PRESENT", true]; has issues sometimes

My English is not good so I use translation software
Added:

1. Must be two real human players, one player and one AI will not cause this bug
2. No matter how the bug happened, the pilot can always solve this problem by pressing "U" to create a new squad and become the leader

The Trigger Issue persists after Arma 3 Hotfix still

getObjectId rev.149074

It seems like it's fixed now. If it should appear again, I will let ya know.