Unity project won't start I get: Fatal Error! Could not allocate memory: System out of memory!

So I was just working on my unity project when suddenly it crashed. Then from now on I can’t launch the project it just crashes after a long while of loading.
this is the error message I get:
Fatal Error!
Could not allocate memory: System out of memory! Trying to allocate: 171798691848 with 16 alignment. MemoryLabel: DynamicArray
Allocation happened at: Line: 78 in
C:\buildslave\unity\build\Runtime/Utilities/dynamic_array.h
Memory overview
[ALLOC_TEMP_THREAD ] used: 3019958B | peak: OB | reserved: 218890248
[ALLOC_TEMP_JOB_1_FRAME ] used: OB | peak: OB | reserved: 1048576B
[ALLOC_TEMP_JOB_2_FRAMES ] used: OB | peak: OB | reserved: 1048576B
[ALLOC_TEMP_JOB_4_FRAMES ] used: OB | peak: OB | reserved: 2097152B
[ALLOC_TEMP_JOB_ASYNC] used: OB | peak: OB | reserved: 1048576B
[ALLOC_DEFAULT] used: 46763193136B | peak: OB | reserved: 46790459392B
[ALLOC_GFX ] used: 73392B | peak: 0B | reserved: 33554432B
[ALLOC_CACHEOBJECTS] used: 2749528B | peak: OB | reserved: 58720256B
[ALLOC_TYPETREE] used: 591792B | peak: OB | reserved: 178257928
[ALLOC_PROFILER] used: 12824648 | peak: 12881288 |
reserved: 16777216B
[ALLOC_PROFILER_EDITOR] used: 19872B | peak: 291048 | reserved: 1048576B

things i did to try to fix it:

  • turning other programs that used up memory off while starting it.
  • turning my pc off and on again
  • deleting library and temp folder
  • initially the project is a unity 2020.3.36f1, i tried launching it with unity 2020.3.48f1 and unity 2022.3.4f1
  • i only had one scene in my project I could launch the project from so i tried creating another scene in another project and putting the “.unity” and “.meta” file of the scene in the projects assets and launching the project from that and i still got the same error message.
  • I found this thread here were someone reports similar issue, someone says it’s fixed but doesn’t seem fixed for me. Then again i seem to get it in a different circumstance: Fatal Error: Could not allocate memory: MemoryLabel" DynamicArray

I also submitted a bug report.
Any help would be highly appreciated thanks.

Scroll down to the part about bisecting.

Lost progress / project / work / stuff disappeared in Unity.

This article is to help you when you have lost significant progress or work in your Unity project.

It is designed to give you avenues of discovery and investigation.

It is NOT a guarantee of restoring your lost work. It is NOT a substitute for proper IT / Data security procedures.

To decide which parts are applicable to you, look for major bolded headings.

EVERYTHING IS GONE, YOU CANNOT OPEN THE PROJECT

Your project probably is still on your computer. Try a computer-wide search for some unique filenames that you know are in the project you think is gone.

To start your search, one common file to all Unity projects is named ProjectSettings.asset

Some things that might have happened:

  • you are not opening the project that you think you are
  • you are in the correct project but not opening the same scene you had open before
  • you dragged the project (or part of it) into the trash (intentionally or inadvertently)
  • you moved the project (or part of it) somewhere else (intentionally or inadvertently)
  • an overly-aggressive antivirus solution quarantined it because it saw code being compiled in there
  • you’re using a directory sync like OneDrive or Dropbox… NEVER USE THESE SERVICES WITH UNITY!
  • something else??

As I said, it’s probably still all on your system to be found if you look in the right places.

A typical Unity project will have at a minimum the following folders:

ProjectSettings\
Packages\```

**EVERYTHING IS PRESENT BUT MY SCENE WINDOW IS BLANK**

Close Unity and make a full project backup RIGHT NOW. Do not do ANYTHING else until you back it up 100%.

Ideally copy that backup to another computer, or back it up to another external hard drive entirely. This is just basic data processing best practices during data recovery operations.

If you can see all the files and folders of your project, make sure you are opening the scene file you were working in.

Once you have opened the scene, look in the hierarchy window, select an object and move the mouse over the Scene window and press F to focus that object.

Additional notes:

- ALWAYS use proper industrial grade source control (see below)
- NEVER use Dropbox or any file sync mechanism in Unity.
- NEVER move files within your project, except by doing it within Unity
- ALWAYS be sure you are fully backed up before upgrading Unity

**SCRIPTS OR ASSETS ARE MISSING OR BLANK**

Some info about Missing script warnings, broken prefabs, GUIDs, renaming GUIDs, etc:

https://discussions.unity.com/t/836322/2
https://discussions.unity.com/t/815173/7
https://discussions.unity.com/t/815173/9

EVERYTHING in Unity is connected to the above GUID, which is stored ONLY in the metafile, and hence why the metafiles ALWAYS MUST be source-controlled.

**When Renaming**: It is super-easy to inadvertently change the GUID by renaming outside of Unity. Don't do that. Instead:

- close Visual Studio (important!)
- rename the file(s) in Unity
- in Unity do Assets -> Open C# Project to reopen Visual Studio
- now rename the actual classes, and MAKE SURE THE FILE NAMES DO NOT CHANGE!

If you are NOT using source control while you do this, renaming files is an EXTREMELY dangerous process. Use source control at all times so that you can trivially revert if you miss a critical step and damage your project.

**UNITY CRASHES / FREEZES WHEN I OPEN MY PROJECT**

You must isolate if there is something wrong with your Unity installation, something wrong with your project, or perhaps just a corrupted import or asset database.

First, ALWAYS back your project up. Then try deleting the ```Library/``` and ```Temp/``` folders that are within your project, the directories that are peers to the ```Assets``` and ```ProjectSettings``` folders.

If that doesn't work it is time to bisect. Make a new empty project and get Unity to open that. If you cannot then it is time to fix your Unity installation, either by fully reinstalling or verifying it with the hub.

Once you have an empty project open, begin copying over your project. Try the entire thing. If it crashes, try half of the project, then the other half, etc.

As always, if you're using Windows, another thing to try is to simply reboot the system. This often fixes typical Windows issues related to locked files and locked directories.

**ISSUES RELATED TO UPGRADING PROJECTS (eg, changing to a higher Unity version)**

Upgrading to a later version of Unity is a one-way process. Any project that has been updated should NEVER be reverted to an earlier version of Unity because this is expressly not supported by Unity. Doing so exposes your project to internal inconsistencies and breakage that may actually be impossible to repair.

If you want to upgrade to a newer version of Unity, do not even consider it until you have placed your project fully under proper source control. This goes double or triple for non-LTS (Tech Stream) versions of Unity3D, which can be extremely unstable compared with LTS.

Once you have source-controlled your project then you may attempt a Unity upgrade. Immediately after any attempted upgrade you should try to view as much of your project as possible, with a mind to looking for broken animations or materials or any other scripting errors or runtime issues.

After an upgrade you should ALWAYS build to all targets you contemplate supporting: iOS and Android can be particularly finicky, and of course any third party libraries you use must also "play nice" with the new version of Unity. Since you didn't write the third party library, it is up to you to vet it against the new version to make sure it still works.

If there are issues in your testing after upgrading Unity, ABANDON the upgrade, revert your project in source control and be back where you were pre-upgrade with the earlier version of Unity.

Obviously the less you test after the upgrade the more chance you will have of an undiscovered critical issue.

This risk of upgrading is entirely on you and must be considered whenever you contemplate a Unity version upgrade.

Do not upgrade "just for fun" or you may become very unhappy.

**PROPERLY CONFIGURING AND USING ENTERPRISE SOURCE CONTROL**

I'm sorry you've had this issue. Please consider using proper industrial-grade enterprise-qualified source control in order to guard and protect your hard-earned work.

Personally I use git (completely outside of Unity) because it is free and there are tons of tutorials out there to help you set it up as well as free places to host your repo (BitBucket, Github, Gitlab, etc.).

You can also push git repositories to other drives: thumb drives, USB drives, network drives, etc., effectively putting a complete copy of the repository there.

As far as configuring Unity to play nice with git, keep this in mind:

https://discussions.unity.com/t/736093/3

I usually make a separate repository for each game, but I have some repositories with a bunch of smaller test games.

Here is how I use git in one of my games, Jetpack Kurt:

https://discussions.unity.com/t/807568/3

Using fine-grained source control as you work to refine your engineering:

https://discussions.unity.com/t/826718/2

Share/Sharing source code between projects:

https://discussions.unity.com/t/719810/2

Setting up an appropriate .gitignore file for Unity3D:

https://discussions.unity.com/t/834885/5

Generally the ONLY folders you should ever source control are:

Assets/
ProjectSettings/
Packages/

NEVER source control Library/ or Temp/ or Logs/
NEVER source control anything from Visual Studio (.vs, .csproj, none of that noise)

Setting git up with Unity (includes above .gitignore concepts):

https://thoughtbot.com/blog/how-to-git-with-unity

It is only simple economics that you must expend as much effort into backing it up as you feel the work is worth in the first place. Digital storage is so unbelievably cheap today that you can buy gigabytes of flash drive storage for about the price of a cup of coffee. It's simply ridiculous not to back up.

If you plan on joining the software industry, you will be required and expected to know how to use source control.

"Use source control or you will be really sad sooner or later." - StarManta on the Unity3D forum boards

Do you remember what exactly you were doing when it crashed?
You may have written some code that generates a lot of content and possibly in a way that it happens every time you load the project. Try removing all the .cs files in a copy of the project and see if it opens. Also check for any files that have unusually huge sizes, for example a .unity scene file with > 1GB.

But there is a chance that something got corrupted due to the crash occuring while an asset got written to disk. Removing assets could help you narrow down that issue. Again: in a copy of the project!

171798691848 bytes ? isnt that 160gb?

I wasn’t doing anything too special i think.

I’m making a board game prototype, the last thing I did is added a 3dtextmesh to a piece, to show a variable relevant to the piece directly on the piece.
Coding wise this did involved adding a new variable in one of my [Serializable] classes that also contains one [NonSerialized] other variable. It’s my first time using [NonSerialized] variables in [Serializable] classes. But at this point my project contained already at least already 13 such [Serializable] classes with many variable some [NonSerialized]. Just now as an experiment I tried to remove that last variable I added. To see what would happened it didn’t change anything.
I’m going to try following your advice and duplicate the project and to slowly remove stuff to see if i can eventually get it to start again.

There is not really anything I have told unity to explicitly do when launching my project. It is to my opinion not really a big project it’s quite basic. It’s at prototype level so i didn’t add any shaders no weird code except those [Serializable] classes with some non [NonSerialized] variables.

I did how ever find it really weird that while i was working on the project when switching between visual studio and unity the loading time was massive and the loading time was also pretty long when starting the play mode around 10 seconds.
I just thought this was an inconvenience of unity 2020 or something since from the start they were quite long already. But now that i think about it those times were getting maybe far too long for the size of my project.

I guess it is indeed quite a lot. Even in play mode i don’t think i do anything that should be using a lot of memory.

thanks i’m going to go through that and see if it helps

Let me speculate about a trivial way to get Unity to attempt to allocate a phenomenal amount of memory.

Steps to crash:

  • have a public array of things, say “tiles across in my world”

  • see it has a value of 8192 in it

  • decide you want to change that to 16384

  • click twice and type 16384 without removing the 8192

  • now you have 163848192 things

This is why we use source control.

This is also why bisecting lets you find it.

Deleting files half at a time also works, once it is in source control and you can revert with one click.

EDIT: I just noticed this is crashing in Unity’s “dynamic array” file… :wink:

I‘m also considering a circular serialization as the issue. I know Unity does a good job detecting and preventing those but there may be ways to mess it up.

Well after much experimentation I realized that I could launch my project as long as their were compilation errors in my last launch attempt. Even if in my current launch attempt the project had compilation errors it would not work I would have to do a second launch attempt for it work.
Then i saw your message :

So I commented out all [Serializable] key words which are not necessary to make the project compile just necessary for the saving loading feature of the game and I was able to launch the project despite it compiling. I shall note that the project also seems to play faster. I count three seconds for it play.
Thanks a lot for your help
Do you have any advice on properly making classes serializable. I had never heard of the circular serialization issue.
In any case i shall look in to it thanks.

i didn’t really understand exactly what you mean here.

In any case I did put my project in a source control initially i was like this is too small I’m not going to bother but seems I probably should have put it in source control.

its never too small for it to F up and need a rescue

Just to help future visitors of this page: I got this error upon loading my android app on-device. Turns out I had ARMv7 as the target device, and not ARM64 checked, and my device was ARM64.

9476566--1332271--upload_2023-11-16_17-24-42.png

This is in Project settings/player/android tab/other settings/ configuration

This issue with this error blindsided me today. Posting here as a reference for anyone in the future. Maybe it’ll save someone as it was blatantly unintuitive until I’d realized what I’d done.

I had a Monobehaviour class I was using, say MyCustomClass. This Monobehaviour had a reference to a public MyCustomClass inside of itself. As a monobehaviour this works fine because when you look at it in the inspector, you just see one line with that variable reference.

But then I changed this class to be a non monobehaviour, instead making it [Serializable], and that demolished everything. Because now the inspector wants to show this serialized variable embedded inside some other serialzed display where it shows everything, including it’s serialized variables of it’s own type, which contain the serialized variable, which contain the serialized variable… Infinite serialization.

I gotta say this seems like an extremely easy issue to hit (create a class, make it serializable, and add a variable reference of itself inside) so there might be something else going on for my case.