Search Unity

  1. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Resolved Unity crashes when building with more than 100 scenes

Discussion in 'Editor & General Support' started by drsalvation, Nov 23, 2023.

  1. drsalvation


    May 2, 2014
    Updating to 2022.3.14f1 fixed the issue. I still don't know what was the exact cause.

    For more context:
    I used to work with Unity 2022.3.5 LTS. I had a large project, which I kinda screwed over when I tried bringing in some assets from the 'Enemies' pack (which was a dumb idea considering how large my project was and that even in a new project, 'Enemies' is broken and will break the new project). I also had some issues with windows and had to reinstall.
    After that, I updated unity to 2022.3.13 LTS created a new project, move my assets into that new project, and continued working on it, this did fix the issues I had with the graphics on my previous project. I need to emphasize that I only moved assets, no

    The short of it, I have over 100 scenes (I stream them with SECTR, so I have small connector tunnels). And every time I try building my game, Unity will crash.

    Unhandled exception at 0x00007FF7DD564B3E (Unity.exe) in crash.dmp: 0xC0000005: Access violation reading location 0x0000000000000040.

    I was looking for more help but the answers seem highly ambiguous, I don't know if that's a unity issue or a windows issue. I started builds with a few scenes assuming it might be a corrupt scene, adding scenes in batches, multiple times, every time the build was successful, the issue came when I reached 100 scenes.

    So I'm wondering what might be the cause, before the updates I was completely able to build the entire game, now there's that limit issue.

    I'm wondering does it have to do with how I migrated my project (moving Assets to new project, including metadata), or is there something new in the latest LTS version of Unity I'm not aware of, or is this a hardware issue? As I mentioned, before ruining my original project with 'Enemies' I was able to export the full game, and at least I now know it's not a corrupted scene.
    Last edited: Nov 23, 2023
  2. Skiriki


    Aug 30, 2013
    Have you tried to do a binary search / divide and conquer on your scenes? I.e.
    1. build with top 50 scenes or bottom 50;
      1. if both fail 1st, 2nd, 3rd, 4th quarter of scenes;
      2. if on fails, divide it and add half to the build and/or only build with that half
    2. Etc...
    Kurt-Dekker likes this.
  3. Kurt-Dekker


    Mar 16, 2013
    Yes, what @Skiriki suggests: bisect to find the problem scene.

    It doesn't matter if the earlier version of Unity thinks it is okay if the current version of Unity crashes on it.

    Otherwise, you really need to start using source control. Stuff like this:

    becomes a non-issue: you just revert.

    Beyond that, here's the full list of troubleshooting steps. Scroll down for parts that might apply:

    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.


    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

    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:



    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


    ALWAYS move all Unity assets by using the Unity Editor. Any other way risks disconnecting the GUID in the meta file from the original file, and this will result in all connections to that asset being broken.

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

    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.


    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
    folders that are within your project, the directories that are peers to the

    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.


    Keep in mind that Unity does NOT back your files up. That's on YOU.

    Use either version control (see below) or else make your own backups.


    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:

    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:

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

    Share/Sharing source code between projects:

    Setting up an appropriate .gitignore file for Unity3D:

    Generally the ONLY folders you should ever source control are:


    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):

    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.

    Source control does require learning, but there are TONS of tutorials and courses and online reference.

    You should strive to use source control as well as you use your file/folder system.

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


    May 2, 2014
    yeah, as I said:
    "I was looking for more help but the answers seem highly ambiguous, I don't know if that's a unity issue or a windows issue. I started builds with a few scenes assuming it might be a corrupt scene, adding scenes in batches, multiple times, every time the build was successful, the issue came when I reached 100 scenes."

    To elaborate on that, I was adding batches, when I reached 100 unity would crash, I removed the scenes I thought might be corrupted and added new ones, still crashed, removed scenes, added the scenes I thought might be corrupted but kept the list below 100, and it built with no issues.

    For now I'm wondering if everyone else has issues with exporting more than 100 scenes, or if that's just me. If it's the former, then it's a unity issue, if it's the latter, then it's my own issue, and I'm trying to figure that out before I get into the nitty gritty of it all
  5. MartinTilo


    Unity Technologies

    Aug 16, 2017
    Using Unity version 2022.3.14f1 I can build (for Android) with 100 and 101 scenes just fine, so this either got fixed on 2022.3.14f1, or it needs something else than 5 simple scenes duplicated 20-21 times.
  6. drsalvation


    May 2, 2014
    Thanks! That's very useful to know, before I switch versions I'm gonna try a few other things, but it's good to know that there really isn't some sort of scene count limit (at least not in .14) if I figure it out I'll post it here.
    MartinTilo likes this.
  7. MartinTilo


    Unity Technologies

    Aug 16, 2017
    Maybe it's some single file in the Data folder that bloats past 2 GB (int.MaxValue) or 4 GB (32 bit limit)?
  8. MartinTilo


    Unity Technologies

    Aug 16, 2017
    We did fix something in our native allocators regarding those limits that might have landed in .14f1
  9. drsalvation


    May 2, 2014
    To be fair, I still don't know what exactly caused the issue, from the crash.dmp I thought it might've been some sort of graphics card issue due to the thread and call stack, I updated my drivers, cleaned up my project a bit, and still had no luck...
    But in the end, updating to .14f1 did end up solving the issue, it would've been worth checking that data folder you mentioned before I tried updating, at least because I am intrigued by whatever was causing that issue, but I'm also glad everything's working now, so thanks for the suggestion! I appreciate it!
    MartinTilo likes this.