View Issue Details

IDProjectCategoryView StatusLast Update
0009163Multi Theft Auto : San AndreasClientpublic2016-06-07 14:31
Reportereinheit-101 Assigned Toccw  
Status resolvedResolutionfixed 
Product Version1.5.2 
Target Version1.5.3Fixed in Version1.5.3 
Summary0009163: setElementModel crash

I have collected data about 6 crashes, 3 from me and 3 from a friend.
It seems all have the same crash reason.

Steps To Reproduce

Additional Information

6 Dumps in a .zip download link:

TagsNo tags attached.


related to 0008819 resolvedccw Multi Theft Auto : San Andreas Projectile setElementModel crash 
has duplicate 0008890 closed New issues Random crashes with no visible reason 
has duplicate 0009248 closedDutchman101 New issues MTA Crashes 



2016-02-25 18:19

updater   ~~0024459

Can you add /private dumps instead of public, also.


2016-02-25 18:32

reporter   ~~0024460

Last edited: 2016-02-25 18:34

Sorry, my fault. I was confused about the text in that readme.txt which says
"Dump files in this directory are encrypted and copied to 'dumps\public' during startup",
but it seems the "public" dumps are the ones that get encrypted. What software do you use to look into these dump files?

€DIT::: Dropbox Download link contains now "private" dumps instead of "public", zip name is still "", dont worry

€DIT::: 3 more dumps will follow soon


2016-02-27 20:52

updater   ~~0024483

Last edited: 2016-02-27 23:42

The reason is simply that not all devs have the decryption key, so priv means looking for the cause isn't limited to just afew people.

proxy_sa crash (dump 1) output:
this tells the offset/EIP is same as this old crash:

which was fixed, that crash was related to explosions / custom projectiles.
Another crash with this EIP is which again, is related to explosions, and duplicate of custom model crash.

So now you know where to look for the crash cause, look at what sort of (custom) explosion or model scripts you run. As I know einheit, the gamemode you develop uses alot and you script custom explosive shells.
When it started to happen, check on what you have changed in the code in this period and try to reproduce after reverting.

Also, could you just collect the crashdata (core.log registers) for each crash, put them together and attach?


2016-02-27 21:00

updater   ~~0024484

In addition, your v-reload script is known to cause that type of crash.

While the EIP was 49646550 (relating to previously mentioned, old crashes)
the offset for this one was 0x000096AD and some users of your v-reload script on community encounter this same crash when using that script of yours.
So do you run that script now, or something with similar code?


2016-02-27 21:32

reporter   ~~0024485

Last edited: 2016-02-27 21:34

€DIT::: 4 More logs from a friend:

€DIT 2::: My core.log file:

Strange. I dont use vreload, i use a heavily modified resource that does similar things and much more.
But the real strange thing is, no explosions occur while the client keeps crashing from time to time. Is something known about the crash reason? My gamemode depends on custom explosions and projectiles.


2016-02-27 22:38

updater   ~~0024486

Maybe you can upload an resource like that (which does similar things in your words) or just all resources that relate to the functions used for (custom) explosions/projectiles, to so that an dev could investigate it further with reproduction of random crashes.

Or else just list all functions/hacky code you use to create custom explosions or projectiles involved.

It's definately MTA or GTA in the wrong, since certain scripting in your resources can apparently cause crashes, and I'm not sure if within the dev team anyone yet knows the cause of them or if it still needs to be looked into.
Also remember, as I don't think its highly occurent crashing (appears to stick to your scripts, ways/methods used in code, or gamemode properties) this can play a role in priority for it to eventually be investigated further.


2016-02-27 23:55

updater   ~~0024487

Gotta add that after looking into the second SA crash ( 0x00133EA9 ) this is also related to same stuff (see ) and also the previously mentioned 0x000096AD is also listed there by an user crashing on your resource (topic page 3)

This further confirms that the answer lies within your scripts/resources as something in it's code triggers these crashes.
So until a fix/cause is found you'll have to live with the crashes, if your gamemode depends on custom explosions/projectiles, as you said.


2016-02-28 05:42

reporter   ~~0024488

Last edited: 2016-02-28 06:07

I will upload the whole resource, but the good old vreload should work since it causes the crashes, too. It's not really something special, createProjectile, onClientProjectileCreation, createExplosion, processLineOfSight... And the crashes can occur 1 second after joining the current WW2 Beta Testserver or 1 hour after joining, while no one is doing a thing. Once it crashed shortly after a new round has been started - me and my friend just spawned, i Pressed “W“ and Goodbye.

€DIT:: i use setElementModel to change the look of all projectiles onClientProjectileCreation (bc model argument not synced), I disable this method and watch out for crashes. If they still occur, i´m gonna disable more stuff until it works.

€DIT 2:: I'm pretty sure it's the setElementModel:


2016-03-01 23:59

developer   ~~0024491

Last edited: 2016-03-02 01:45
This code makes my game crash always after ~2k projectiles got created.

My results:
1) 2174 created projectiles before crash
2) 2292
3) 2388
4) 2378 (100 ms timer)
5) 2337 (grenade instead rocket, 50 ms timer)
6) 2376 (grenade, 50 ms, source:destroy() after model change)

Can't reproduce if I do same thing without model changing.


2016-03-02 01:23

reporter   ~~0024492

Last edited: 2016-03-02 01:48

Dat code will crash your game from time to time even if no 2000 Projectiles have been created.
I dont think i created 2000 projectiles in the last 2 Months, but had 10+ crashes. I removed setElementModel() and had no crash since then BUT i played for - maybe 1 hour. I wanna do more testing but i am 100% positive its setElementModel(projectile). I guess setting a projectile Model could leave a memory adress locked and the crash occurs if another function wants to use that memory adress 30 minutes later - or 2 hours later.

€DIT::: the exact same crash reason it seems


2016-03-07 03:08

reporter   ~~0024510

Had another proxysa.exe crash at offset 0x00133EA9, code 0xC0000005.
setElementModel are all disabled. This was the first crash for one week.
Happened randomly again.


2016-03-07 16:13

updater   ~~0024511

Last edited: 2016-03-07 16:14

Einheit, I already covered that crash (0x00133EA9) in my note 0024487 as it was also in the crashdumps folder you sent.

It's also related to vreload of functions similar to / or also used in your current set of scripts as seen at (quoted from my older comment, next time read it first)


2016-03-07 22:55

reporter   ~~0024512

Last edited: 2016-03-07 22:55

I know, but i wanted to mention that it happened without setElementModel being involved at all. That was the special thing.
I commented all of them out.


2016-03-07 23:36

administrator   ~~0024513

Crash offsets are shared by different crash types, so outliers can be ignored when looking for causes/patterns


2016-06-07 09:44

updater   ~~0024759

Fixed in


2016-06-07 13:01

reporter   ~~0024762

Hell yeah! Updating my Server now :)

Issue History

Date Modified Username Field Change