Page MenuHomeFeedback Tracker

Server crashing since 1.40
Closed, ResolvedPublic


I have been getting intermittent server crashes on my life server and I haven't been able to see naything in the scripting that could be causing this.

Memory usage, cpu usage, and network usage all seem normal.


Legacy ID
Unable To Duplicate
Steps To Reproduce

None that have been identified except have my life server having people on it. Sometimes it survives the restarts (which are in 5 hour windows) and sometimes it doesn't. This likely means that it's indirectly related to something in the mission but

1.) I have no means to debug this issue myself since the files produces are not able to be utilized (at least by any means I am aware)
2.) There are no other ways that it is showing the issue. Nothing is thrown to the event viewer. No dumps are created (I have user dumps enabled for the arma3server.exe process).

Additional Information

It does create bidmp files, but I have no way to work with them, if there IS a way to work with them (even for advanced users that can use WinDBG to debug operating system issues and can debug applications), please point me to that information and I can debug this to save you guys some time.

I have created 4 zip files, each containing a bidump and it's corresponding RPT file (I have enabled rpt output since this started happening). You can get them from the following links:

If you need anything else from me, please let me know. Thanks!

Event Timeline

Paronity edited Steps To Reproduce. (Show Details)Apr 12 2015, 9:15 PM
Paronity edited Additional Information. (Show Details)
Paronity set Category to Server.
Paronity set Reproducibility to Sometimes.
Paronity set Severity to None.
Paronity set Resolution to Unable To Duplicate.
Paronity set Legacy ID to 786575473.May 8 2016, 11:55 AM
Paronity edited a custom field.
Adam added a comment.Apr 13 2015, 11:15 AM


We need the .mdmp files located in the same folder as .bidmp and .rpt files.

Thank you.

mdmp files are never created.

I have yet to see an mdmp file produced by any of these crashes, either in the profile folder, nor have any OS dumps been created by my user-mode dumps being enabled.

Adam added a comment.Apr 13 2015, 2:40 PM

It seems you have custom memory allocator running. This can cause stability issues with your game. Please try disabling it and see if the issue persists.

Ok - turned on default (and inferior :P) allocator, here is the latest RPT and bidmp file. Again, no mdmp file is being created. Also, no user-mode dump.

Got a crash totay that actually seems to have been caught "correctly". There was an mdmp file in it this time and the RPT reports an access violation.

Here is the zip with RPT, BIDMP, and MDMP:

I have no idea what your MDMP file contains, so just in case it's helpful, the user-mode dump ALSO threw and I have a full dump should it be necessary. Also, just in case, here is the WinDBG anaylyze output for starters.I know details are scarce without symbols, but I figured I'd throw it in just in case. :)

  • *
  • Exception Analysis *
  • *
  • ERROR: Symbol file could not be found. Defaulted to export symbols for tbb4malloc_bi.dll -
  • ERROR: Symbol file could not be found. Defaulted to export symbols for PhysX3Common_x86.dll -
  • ERROR: Symbol file could not be found. Defaulted to export symbols for tier0_s.dll -
  • ERROR: Symbol file could not be found. Defaulted to export symbols for steamclient.dll -
  • WARNING: Unable to verify checksum for extdb.dll
  • ERROR: Symbol file could not be found. Defaulted to export symbols for extdb.dll -

00ee603a f3a4 rep movs byte ptr es:[edi],byte ptr [esi]

EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff)
ExceptionAddress: 00ee603a (arma3server+0x00db603a)

 ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000

NumberParameters: 2

Parameter[0]: 00000000
Parameter[1]: 00000000

Attempt to read from address 00000000

CONTEXT: 00000000 -- (.cxr 0x0;r)
eax=00000000 ebx=00000000 ecx=00000000 edx=00000000 esi=00000003 edi=00000003
eip=7744d2ec esp=01bea95c ebp=01beaadc iopl=0 nv up ei pl nz na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00200206
7744d2ec c21400 ret 14h


PROCESS_NAME: arma3server.exe

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.



READ_ADDRESS: 00000000

00ee603a f3a4 rep movs byte ptr es:[edi],byte ptr [esi]



APP: arma3server.exe

ANALYSIS_VERSION: 6.3.9600.17298 (debuggers(dbg).141024-1500) x86fre




LAST_CONTROL_TRANSFER: from 00e96585 to 00ee603a


WARNING: Stack unwind information not available. Following frames may be wrong. 01beb5fc 00e96585 01beb648 00000000 00000004 arma3server+0xdb603a 00000000 00000000 00000000 00000000 00000000 arma3server+0xd66585

STACK_COMMAND: ~0s; .ecxr ; kb


SYMBOL_NAME: arma3server+db603a


MODULE_NAME: arma3server

IMAGE_NAME: arma3server.exe


FAILURE_BUCKET_ID: NULL_POINTER_READ_c0000005_arma3server.exe!Unknown



FAILURE_ID_HASH_STRING: um:null_pointer_read_c0000005_arma3server.exe!unknown

FAILURE_ID_HASH: {785b27d8-09bd-7a57-4840-60685f9f0af0}

Followup: MachineOwner

If you need the full dump uploaded, just let me know.

Another one. No MDMP or user-dump on this one:

How long should I expect before I get some sort of movement on this? Should I keep uploading these files? Are they helpful at all? Any tips on what I can do to expedite the process would be great. Thanks!

Adam added a comment.Apr 23 2015, 1:00 PM

Hello, if the server crashes again with .rpt .mdmp .bidmp files all being created please upload them.

Thank you.

It has crashed several times, and the frequency seems to be more after the last push this week. It's never throwing an mdmp file.

We did finally get one today that had all three. It's attached and here as well: (RPT, MDMP, and BIDMP)

Is there anything else we need to make some progress on this one? Is there anything to note about it only giving MDMP files like 5% of the time? Anything I can do to "influence" them to be caught correctly? I know that exceptions (especially memory), are a slippery slope, just trying to make progress. :)

I've had many server crashes since 1.42. 1.44 is on a different level though. I get sometimes 3 crashes a day. I'm adding my crash logs to this tracker.


Adam added a comment.May 15 2015, 1:29 PM

Thank you for attaching the new dump files. We will take a look at them.

Adam added a comment.May 20 2015, 8:07 AM

Hello, please try using the profiling branch and see if that fixes your issues. Thank you.

Still seeing the crashes on my end. MDMP files are not being created still, either....

Adam added a comment.Jun 15 2015, 9:28 AM

Is it still crashing even after the 1.46 update?

Yup. Twice yesterday, and once today so far.

Adam added a comment.Jun 18 2015, 11:00 AM

As the crash does not generate MDMP dump files it is most probably either Memory or Windows related crash.

It's not windows. If it were windows, there would be events being thrown and a memory dump would be created (because I have user-mode dumps enabled for that executable).

Memory related crash is possible, but you, as the software that is running are responsible for managing those memory calls and handling them should they fail.

Is there anything I can do to help further debug the issue on your end? I'm an operating system level debugger for a living and have a lot of experience in this area, I just need to know what I can do with your software to do so. I am doing everything possible from the OS level, and am getting no where, which leads me to believe it's on ARMA side of things.

Adam added a comment.Jun 19 2015, 10:46 AM

Are you by any chance running any mods?

Just extDB for database connectivity.

So there is nothing more that I can do to debug this issue?

Adam added a comment.Aug 4 2015, 8:21 AM

The reason why mdmps are not generated might be due to the server running out of memory.

The only thing on the box is this particular server (and the MySQL instance for it) - and the server has 32 GB of RAM.

Most of the time, the ARMA server idles around 110-200 MB of RAM (with the 3rd party malloc) and 1.4GB-1.8GB (with the default malloc) depending on player count, object count, ect....

The system NEVER gets above 25% RAM usage (if we are doing testing with another server, or something else with the box at that point in time). Point being, we aren't even coming close to running out of RAM.

Adam added a comment.Aug 10 2015, 10:55 AM

Could you please try reproducing the issue on Vanilla version of the game and Running Vanilla maps?

Altis is a vanilla map......

Your software isn't handling an exception the way it should. That is a fact. If it were, we would be getting MDMP files. It's irrelevant if I'm running a mod or not.

Just close this issue out. It's apparent that it's going no where. Thanks.

Adam added a comment.Aug 13 2015, 10:12 AM

But you are using community made mission (Altis life) which very well could be the reason why you are experiencing this issue.

Xeno added a subscriber: Xeno.May 8 2016, 11:55 AM
Xeno added a comment.Aug 13 2015, 12:53 PM

99,9% of the missions played in MP are community made missions. If they cause crashes then you should find out why your game crashes (it's still the game which crashes not the community made mission).

How should the mission maker find out what causes the crash without having access to the engine?

Thanks Xeno - my points exactly.

If you create an engine that is flexible and made for customization, then you need to handle exceptions correctly so that the modders knows what went wrong and how to fix it.

I am not disagreeing that the code written could be causing the issue, but how am I to determine what code is causing the issue when your engine isn't handling the exception correctly?

Adam added a comment.Aug 17 2015, 12:44 PM

I'm just asking that you try running a MP map that is officially made by Bohemia.

I don't consider that a valid debugging step and I will not be able to test that, and additionally, of course it's going to work.

I can even run the Altis Life file just fine with no one on it and it runs just fine and never crashes.

For the sake of proving absolutely nothing, I ran a server on the box (default map with no customization) since my last post, with a tool restarting it every 12 hours and it never crashed. So, as was already obvious it is something in the custom code that is causing the issue (but we already knew that), but that doesn't help us (content creators and server admins) figure out what is causing the issue because it's YOUR engine that isn't handling the exception correctly. What's more, your code is "handling" it enough to prevent windows from seeing the failure (hence no user-mode dumps and no event log entries) but not enough to do its job.

I would like to be able to figure out what code is causing the issue, but you, the creator of the engine, provide me no valid way of doing so.

I poked around in the hex editor in the bidmp files and can see the error
that it "thinks" is causing the issue which is:
"Out of memory (requested 4203 KB).

footprint 536870912 KB.
pages 81920 KB.

B, mapped 50040832 B), free 60440576 B", but as I said before, the server is on a box with 32 GB of RAM ( and its the only thing running. It's RAM consumption stays around the 110MB-169MB range. (

Altis Life is running a Multiplayer Map that is officially made by Bohemia, it resides on the Altis map.

The content in Altis Life is created with the SQF language, Bohemia's official language for the Arma series. This language is maintained & surrounded by your container - the game.

Adam added a comment.Sep 7 2015, 10:22 AM

Closing as expired. If the issue persists please create a new ticket. Thank you.