Official Editor Progress Bar stalls (request for bug reports)

Hi,

There is no crash, also this is a new project so unfotunately i cannot share any data on this.

It gets stuck in all my 2021.3 projects though, so is not a singular bug imo

Sometimes can take hours to export even 3 small files

In other case lasted 4 hours to upload an asset to store, but did finish

This last 7 hours export did not finish though, maybe if stayed much more, not sure

In another case, the same project that did 4 hours, exported for store upload in half hour.

Is very random too.

 

is the same thing we talked about for the past two years. every time some unity staff member show up like he never saw this before.

you didn't even manage to finish your own game, that gigaya one, because of this bug.

your editor is broken, if you could had fixed you would had fixed. hope your engineers figure out how to rewrite the editor core so at least the 2023 will be fixed.

 

Easy, regress to 2019 that worked.

Or better to 2018 that worked, and very fast.

 

even better, not easy, but better in the long run. I've just moved to unreal. This engine can crash and burn and the rest of unity devs can get fired for what i care.

Losing time here for more than a year trying to get an answer to this bug. like common, how idiot i was. This company CEO was right all along

 

Hi there, where can I start, OK, here's my story... (I'm not an app savvy though, so I may messing up or the new unity App is not as user-friendly than before because of this bugs or unexpected weird behaviors)

Part #1
I came from Unity 2017.4.7f1 (64-bit) and just work with MonoDevelop (with autocomplete), then now I download the latest stable Unity which is Unity 2021.3.6f1,

I watch this guy's tutorial as I installing mine 2021.3.6f1
His version is Unity 2020.3.8f1

Now I proceed even though his download and mine have a little differences (I don't have to worry though)
Mine: (note: this is a late image, not the actual, as long as I can remember)

His:


This guy in the video, his Unity works as fine, no disturbance...
His Unity version is 2020.3.8f1, mine is 2021.3.6f1
When I double click my script, I open MonoDevelop, maybe because I also have Unity 2017.4.7f1 (64-bit) installed with me. Then I realized, there's no autocomplete with my script editor (MonoDevelop), then I see it's not Visual Studio (as what I know, unity stop supporting Monodevelop and I'm fine with that), then I check Edit > Preferences > External Tools > External Script Editor (only have: [Open by file extension] and [MonoDevelop (internal)] with both have External Script Editor Args [$(File)]); the Open by file extension opens my Sublime Text before via Unity script, but now it's Visual Studio via Unity script, anyway both MonoDevelop, Sublime text, or Visual Studio by Open by file extension do not have autocomplete function.

Here I download my VS 2022 and installed: https://visualstudio.microsoft.com/

Next, Game development with Unity installed:

So what happen is now I have the option

After that, somehow, I still have no autocomplete? Will it takes time to load or something? I done the same what the guy in the video. But then I restart my PC, and even went reinstalled Unity/VS, no luck, still none. Then I google it: I then click Regenerate project files (again) with Embedded packages and Local packages checked, but still no autocomplete from Unity, so I search more and read some article somewhere says check all, then I click Regenerate project files again, then now I have autocomplete, but there's a new problem:

Part #2
When I open my script in Unity 2021.3.6f1 and opens VS 2022, this goes:

OK, no problem there right? (But that will be there forever: "Starting up V...", until I return to Unity)

Then when I go back to Unity window or even close the VS, this hover window sticks out (Importing assets):


But when I click menu bar on top or right click for menus, it close; then when I just move object then save or when I alt+tab and return to unity window, it pops up again infinitely. I found it annoying, it won't go away... one solution I found is I have to open my Editor first, so I'll have no "Importing assets" forever display on top.


Then I try again to only check the Embedded packages and Local packages, uncheck others then Regenerate project files again. No change with this 'Hold on... Busy for' but at least I have now autocomplete.

Later I download VS 2019 and tried with unity 2021.3.6f1:
https://my.visualstudio.com/Downloads?q=visual studio 2019&wt.mc_id=o~msft~vscom~older-downloads
Then later too, I tried Unity 2020.3.9f1 (64-bit) with VS 2019 like him...
But unfortunately still the same ('hold on' pop up persisting, instead of auto closing, or how does he do it?)

skip to timeline 21:31 when he start opening his script, same as mine.
skip to timeline 24:10 what I expect will happen, but mine remaining open and hover, the 'Hold on, busy for...' not closing, instead it keep on going saying "importing assets" on top in the middle of my Unity space. it kills me.

With Unity 2020.3.9f1 (64-bit) and Visual Studios 2019, I search, somehow I lead to this... what's going on? Maybe done by Edit > Preferences > GI Cache > Clean Cache


But there are just two things I know:
No autocomplete in editor and also no annoying 'Hold on... busy' in Unity; or
Have autocomplete in editor and have this annoying 'Hold on... busy' in Unity;

I'm doing one step forward, then one step backward...

Note: I have no error that now, but again the 'Hold on... busy' welcomes me again...

 

And oh, here's the thing

And then I drag the 'Log' folder? IDK, that take forever though? https://www.speedscope.app/ so I just close the browser after longer time...


One more thing, what is this error (somehow exist as i try looking for some solutions on the way)? When I drag the script to the object to the Scene window, maybe that problem related to this? But nothing serious as it adds Component and function normally after that.


For now I'll return to Unity 2017.4.7f1 (where I'm very comfortable with and very smooth to operate, no pop up annoyance), until the 'Busy for...' (at least make it as a sidebar somewhere maybe at corners and part of Unity that you can drag and attach inside Unity windows just like others, or give us an option to turn it off) and the slow process or start up is solve. Maybe in stable Unity 2022 or 2023? Unity 2017.4.7f1 for me is lightning speed compared to Unity 2021.3.6f1 (it feels heavy loading), glitch or bugs...

 

I am unsure if this is the exact same issue that is being discussed in this thread but I am having having an issue when creating a project the progress bar just stops at importing assets and hangs (I have left it for 16+ hours).

 

Unity now includes several junk packages when opening new project. I believe these packages are designed for beginners. Removing the junk packages after you eventually make a new project after the 10 minute wait means that it never happens again.

I can confirm the junk packages Unity has introduced to the standard empty project are entirely useless.

 

It would be helpful to post a list of these packages, what they are doing and why you don't need them.

I didn't opened unity in the past 5 months so i don't what are the recent changes but I recall always removing part of the packages because I didn't used them. They were those about saving backups online, the packages that give support for code editors I didn't had, the team collaboration packages.

 

Oh just the stuff tht contains art work. And icons

it’s not junk junk but some of it has an import time I been working since 6am and happy right now so I don’t want to go in and pick at Unity trying to answer this question

 

To note at least once you have a project on the go the start up time is not noticable. I don’t use assets from asset store anymore so I rarely have many problems I just have frustration and anger issues sometimes because of the things I try to make and standard quality that i eventually hit.

 

@richardkettlewell sorry to disturb but is there any new news on this bug yet and is there a link to an issue tracker post?

 

I spend more time waiting for the progress bar than I do everything else combined. It reaches a point where I'll be lucky to get 30 minutes of productive time for every hour I spend waiting for it to reload because it crashes. Click something? Progress bar. Update one line of code? Progress bar. It's anywhere from 30 seconds to where I give up after 20 minutes, Ctrl + Alt + Del, and wait another 10 minutes to reload the project. I've had to do it 3 times today when all I've done is change a few lines of code and click "Clear occlusion culling".

 

Is indeed very bad and i fear that is getting zero notice for some reason, i see unity come up with new versions without fixing the old, which means will be worse as gets more complex.

Hopefully all progress in new features will stop and every team will focus on fixing the million critical issues in unity 2021 than anything else

We really not need any new things if the editor is not working. This is reason to leave Unity development and is ten billion times more cricial to address than add new things all the time and breaking everything further.

 

Yeah that's exactly how I feel. It's like adding cosmetic features to a new line of cars when the brakes don't work. I've been dealing with this for a full year and a half across all versions.

 

Is exactly like that, have lost days just trying to export 3-4 files from some of my 2021 projects, is just not possible to work seriously with such huge issues.

Some other issues is the fact that impose by default the Async Shader Compilation, which is broken and make shaders compile 10x slower, of course now i change it manually to non Async in every project, but this is another thing that if not careful can slow down compilation exponentially.

Every new version get slower and slower and with more problems too.

 

I've "fixed" this issue by installing a dedicated SSD, and I've moved there the unity projects which had this issue. I've also made sure to defragment the SSDs, even if they say is not required, and will shorten the SSD life. Did it anyway.

It took me two months to figure this solution, two months were I've got no work done. I've even rebuild the entire project twice.

On this SSD I've had the last rebuild project and the two old projects. Around 30 Gb of data all of them.

When I've had the projects on the normal HDD I've had the exact behavior with 10+ minutes of loading bars. Mind you, I've worked on the same project for the big part of 2021 and it worked just fine on the same normal HDD. Then the issue described in this thread.

After moving the projects to the SSD I've had 3 (three!! ) unity editors opened at the same time, each with its own project open. Switching between projects or editing stuff was lighting fast. no loading bars in any of the projects, no lock up or wait for 20 minutes, not even 5 seconds.

It was amazing. You can't believed. yes, you hear that right, three complex projects opened at the same time and unity worked just perfect.

Why I have moved to unreal then? Why I've invested 4 months to learn unreal and abandoned unity?

Well, turns out that unity had one last F_YOU up there sleeves. One last bug to rule them all. Unity wills say that it saves your level. But, it doesn't. It doesn't save it. You click save, it appears the level was saved, the asterisk star in the loading bar goes away. But nope, nope, it doesn't save. Imagine working 5 hours, close the editor, open it up next day, and all your work has gone.

this was the last line. You can't trust this software anymore. Is the one thing that any software should never do. You can crash on me, you can lock up, but lying to me, saying you are saving and all is fine and you don't save. That is it.

never again in my life.

tldr: move your project to a dedicated SSD and ensure all file are in one piece and correctly defragmented. Also make sure you have only this project on this SSD. then, after you did this and all works great, uninstall unity and move to unreal. you will thank me later.

 

Wow, working on an SSD is faster than a HDD, particularly with large amounts of files.

Who knew! Next you'll be telling me a keyboard is faster than a typewriter!

Try working on an NVME drive. You'll be blown away!

 

Did you have tried this solution or not? Or you are just annoyed I'm not using unity anymore?

 

No, I just think that saying an 'SSD is faster' is like saying 'water is wet'. Well duh!

If it took you two months to figure this out then, well, sorry but that's on you. Anyone who knows anything about computers knows hard drives are shockingly bad when dealing with large quantities of small files.

Pretty much anyone working with media, be it games, 3d, music or video who are worth their salt will be running off NVME drives. 3 of the 4 NVME slots in my motherboard are currently in use.

 

if you have this issue then try my solution, if not, what is your problem, I've provided a solution to fix this broken editor for people that have the issue. And is not "SSD are faster". The solution is "empty SSD, with only one project. Also defragmented correctly" And no, not the main SSD you have all your OS and program and stuff on it.

no is not, the editor and that specific project worked fine with a normal HD for months. So it was not obvious what was the issue. It didn't help that unity staff kept their mouth shut and ignored all people requests for help, thing that this one year old thread proves quite well.

You know about the unity problem with small files because I've posted about it months ago, so good joke trying to lecture me about this.

No, they are not using all of them what you are using. that is just stupid logic, to think everyone use what you are using.

 

The stall issue has nothing to do with small files, since in exact same projects i have never seen it happen in unity 2019, is just a huge bug on Unity side in new versions after 2019.

Same as the new default async shader compilation option can increase shader compile ten or more times. But at least that is solvable by manually turn it off in all new projects.

 

not sure about your logic. you didn't had this issue in the 2019 version so my theory is not correct? this bug doesn't exist inside the 2019 version. is a bug for versions 2020 and higher. you can't get this bug in the 2019 version because that version works fine.

 

I reply only about the ssd part, ssd does not help at all in this case, that was my point. Is not about the speed of the disk imo.

I have a fast ssd also and in 2019 never had a delay, but in 2021.3 can be hours, so is just a bug in newer versions.

 

ah, yes then. This can be true, because after moving the projects to the SSD and have them working fine, I didn't continue the work for long time after that. Because unity kept saying that he saved the scene and it didn't actually saved. So I've abandoned unity and those projects even if the loading bar was not present anymore.

For this, I can't exclude that after some time the projects would had got back to the loading bar issue.

I suggest trying this. Download defraggler and check the fragmentation of the project files (even if they are on an SSD) then if possible try cleaning up the SSD and leave only the unity project. Then, don't forget to defragment all the files (even if is not recommended on the SSD)

Why this could help I can't explain and no guarantees. But if you are desperate to make the damn project work it doesn't hurt to try.

Note that some SSD do not deal well with really small files (which in the case of unity project is the norm)

If you do the steps above I would love for you to show us what where the fragmentation on the disk before and after.

Unfortunately I never manage to convince anyone in actually trying the method described by me. I only got answers that "my project is already on SSD so you are wrong" I mean I'm saying "empty SSD with only the project files that are all defragamented in one piece"

Just try and see what happens

 

I'm not sure if I am experience incredibly long stalls or just crashes. But very frequently when I return focus to the editor window it will try and compile scripts and take forever. Well, to be fair the longest I have waited for this bar is about 13 hours, which is completely ridiculous for something that should take seconds.
So there is no crash, and the only way I can stop the editor is to use the task manager to shut it down, losing any work that was not saved (which I am getting really sick of, should I have to save every single keystroke?!?!)

The timer on the progress bar continues to tick away, so I am not sure if there is any crash, or if changing 'stall' timers in terms of logging will help?

 

Try to put the computer to sleep mode and restore it, it has solved the issue for me in some cases.

 

interesting, never tried this. so how this works? how unity reacts to this?

this may hint to something windows is doing to block the editor, or the editor not getting out of the loop when windows sends some message to it.

basically under the hood windows will send and expects various messages from running programs, if there is a bug where unity misses some event sent by windows at a certain point, then putting windows to sleep and then getting it back on again, may force windows to resend an event and this time unity may listen.

 

Indeed, could be something like that or similar.

Is strange, but this helped to actually finish fast after waiting an hour and half for submitting a package update, which was stuck in saving files state

 

I have countless hours in my projects, and still get this daily. Can happen when I open a scene, when I try to click a prefab in a scene, if I try to click any menuitems, or if I do literally **anything** in unity.

Turned off asset monitoring in preferences

Attempted to fix by putting PC into sleep mode and taking it out.
Literally *no change*.

I left this to load overnight, and came back to the scene being able to be manipulated. As soon as I click or right click, I'm greeted with this same window.

It can be between 5 minutes and 5 hours that this stays on the screen. Two ways out of this: I restart Editor via Task Manager, or I force close it.

Meanwhile, my PC is unusable as Unity is using 100% of my CPU and over 20GB of RAM



I've spent at least 10 hours attempting to resolve this. Debugger shows no loops in code, and breaking in debugger doesn't fix either (despite reports in other posts about this issue)

I'm 99% mentally preparing to just move over to Unreal Engine at this point. I spend hours building a game in Unity, only to be met with this each time.

I've attempted a full rebuild from the ground up 10 times now, and always reach this point.

 

i guess you have an ssd? can you give some information about how big in Gb the folder is, and how many files you have inside "yourprojectfolder/Library/Artifacts"? Can you use the program defraggler to check what is the fragmentation of this folder? it will also show you where on disk the files are located.

for example the image bellow shows the fragmentation of an SSD where I have a unity project that has 78.979 artifacts files (size 5.17Gb) None of these files are fragmented all of them are in one piece and they are located in the blue squares in the image bellow. The red squares are files which are fragmented. They are not unity files, other not important files, like a game or some documents.



the next image shows one of the files that is fragmented (has no connection with unity is just as example, is a pdf) This file is broken in 57 pieces and all pieces are spread around the disk.

If you want to open this file the OS needs to find and read all those pieces. But it doesn't matter in this case, is just one file. But if the 78.979 artifacts files would had been broken in 10 pieces each, we have off course 789.790 small files spread all over the place. This increases the time to read write these files. Maybe the OS is feed up with unity trying to access all these files which decreases SSD life, and tries to block it. Maybe unity just gets nuts and try to reload and recreate all these files all over again. No one knows. Or maybe this has nothing to do with anything



unfortunately I think except maybe one person, no one actually wanted to look into their projects fragmentation to check how it is for them. And i bet that person didn't tried this program. So, try investing some time in learning how defraggler works and how to check the fragmentation of the files and how to see where they are on disk.

If not, come to unreal, here the pastures are always green and butterflies are flying and animals sing and dance.

 

I have an update on the issue where unity is stuck on project export, seems disabling Trend micro, put pc to sleep and then awake make the infinite wait time go and proceeds with compress and make the package.

This never happens in unity 2019, so perhaps some change in 2020 and above affect it.

 

I'm getting this everytime I try to export my package - I don't know if it's something else or it's something in Unity, but Unity is showing this and I decided to see how long it was taking, and finally used task manager to force Unity to quit:

 

I get a stuck like this when try upload an asset to store from Unity 2021.3, at saving assets note, i disable my antivirus, put PC to sleep and then awake it and this make the bar progress little after every time.

Otherwise can last forever, have tried leave it and was hours without any signs of life

Note that none of those issues happen in Unity 2019, so is clearly some bug.

 

what unity version?

 

It's 2020.3.36f1
I've always had marginally short hangs but not like this, it's every time as well

 

I started using Unity in Apr 2020. As someone who has also run into this bug quite a bit lately (and has also been unable to pinpoint why it's happening), and as someone who recently spent about $800 on Unity Asset Store purchases during a sale because I was excited to make games, it is incredibly discouraging and disconcerting reading all of this. This thread as well as an older one I found on the same topic from 2019.

I was searching for an answer and only come across people scrambling to find a way to save hours of their life they are wasting on this, and occasionally a Unity employee chiming in asking for information that apparently isn't helpful to them anyway (or at least, I presume that's why there is no fix for this).

Does Unity have any idea why this is happening and how we can avoid or eliminate it?

Mostly unrelated but yesterday I spent hours figuring out why importing a specific FBX was crashing the Editor but the Editor would just sit at the progress bar dialog like it was still doing something. I had to open task manager and see that the UnityCrashHandler was there and end process all the Unity stuff running. Until I'd end the processes, Unity would just sit there with that dialog box as if it were still working on something even though it was a simple FBX that was not any more complex than any other FBX I had already imported.

Having things like this sink hours or even *months* of your time is incredibly frustrating.

 

I'm not sure what's going on with the newer Unity versions but haven't been using newer releases since 2019.4.38f1
Everytime I tried a new version it just does that very annoying 'Hold On Busy' Repainting, Unity Editor Core Module .dll. It does this at every small step of navigating through my project. Whilst changing properties, whilst fiddling with shaders, whilst changing settings ect.

 

Just reported a bug for this: IN-26676
Just started working on a project with like... 20 script files tops, and compiling script changes is causing stalls of anywhere from 2 minutes all the way up to *10 minutes*. It's severely killed the momentum of this project, to say the least.

Stall report is attached to the bug report.

 

Hit this with a consistent repro on 2021.3.9f1

Submitted a bug IN-28037

The editor will hang forever on enter play mode until it is force closed. This is not a slowdown, but essentially a crash.

Tried enabling the stall diagnostics mentioned at the top of the thread, but this particular stall didn't capture any logs (other small 2-3 second stalls did report diagnostics which told me it's working).

Repro is me deleting one specific gameobject from the scene. It's not referenced by any other scripts in the scene. Reimporting all assets and creating a new scene by copy/pasting the hierarchy did not solve the issue.

Image attached of the dialog box. Just says 12sec in the image, but I've let this go many minutes and it never resolves itself.

Hoping this bug/repro helps find a resolution!

 

Does the GameObject (or any of it's children) have any script on it? If it's got a script with [ExecuteInEditMode] or [ExecuteAlways], and that script causes an infinite loop in it's OnDisable or OnDestroy, then deleting that GameObject would cause the hang.

 

Commented out one line of code that wasn't needed on a very tiny project with a subscene and two game objects. Second time today.



12 minutes and counting... Good times with Unity.

 

Can you try to save the scene as a new scene and work with that one and see if it keep showing that bar?

For me is like an archaeological curiosity this bug.

 

Well it's just random... maybe 1 out of 5 times when I hit play it would freeze up (for hours) unless I killed unity in the task-manager. I disabled domain reloading and it has only happened once since yesterday after doing that.

 

Cool, so the bug report I made earlier in the thread, with my entire project attached to it, and a stall report attached, was apparently closed with "not qualified" and the comment that they were unable to reproduce it :|

This is honestly making Unity just... completely unusable to me.

 

Have you tried

• reinstalling unity,
• disabling your virus scanner,
• deleting the libary,
• checking the settings of DLLs and AsmDefs,
• removing DLLs and AsmDefs from the project,
• checking the Profiler in Editor-Mode,
• checking your drivers and connected devices,
• checking the hard drive & RAM,
• checking your hardware (e.g. extracting a large zip file, seeing if the stall happens there too)
• and maybe reinstalling Windows if everything else didn't help?

 

I reported a bug, which took quite a lot of time because the only repo project I had is quite large. What happened? They closed the case because I was using Unity 2022.1 and not 2022.2.

Might I make a suggestion?

How about your QA team takes the time to upgrade the repo project to the next higher "supported" version and then tests whether the bug still occurs? No, instead you just close the case and ask the customer to take more time out of their work schedule to upgrade the project and resubmit the bug, when the alternative solution is to simply have the QA person open the project on the newer Unity version and wait for it to upgrade . . . probably more than half the time needed vs upgrading on our end and resubmitting the bug.

Edit: I replied to the bug report and the QA person clarified that they actually did do exactly what I suggested, it was just that the bug did not appear in 2022.2 after they upgraded the project. There was simply some miscommunication on their end, because they did not state this originally, just that the project had to be upgraded and bug resubmitted on the newer version.

 

This sucker, endless progress bar, coming up about in half unity 2022.2 shutdowns. I created a powershell script to kill the process and mapped it to a hotkey, it's so bad. Could be related to ECS, because I mostly work with that atm.

Code (CSharp):

1. stop-Process -Name Unity

 

We're getting very long hangs (2-3 minutes) on shutting down Unity in 2021.3.16f1, if we have made a build while the editor was open. If we don't make a build, shutting down the editor takes a few seconds.

I did what @richardkettlewell asked, and activated the diagnostics switches. Opening the project, building the project, and then closing the project gives three stalls in the log:

===== STALL END after 22.40s
From opening

===== STALL END after 324.81s
From building

===== STALL END after 150.37s
From closing



Looking at the closing stall from the log, the vast majority of the lines are spent cleaning up SpriteAtlases. Approximately 120.000 lines start with this string:

Code (csharp):

1. WinMain;MainMessageLoop;DispatchMessageW;CallWindowProcW;ContainerWindow::ContainerWndProc;GetWindowTextW;IsCompositionActive;IsCompositionActive;Ordinal96;GetUserColorPreference;IsIconic;GetWindowTextW;NtUserMessageCall;KiUserCallbackDispatcher;SendMessageTimeoutW;DispatchMessageW;CallWindowProcW;ContainerWindow::ContainerWndProc;GetWindowTextW;IsCompositionActive;IsCompositionActive;Ordinal96;GetUserColorPreference;IsIconic;GetWindowTextW;NtUserMessageCall;KiUserCallbackDispatcher;SendMessageTimeoutW;DispatchMessageW;CallWindowProcW;ContainerWindow::ContainerWndProc;Application::Terminate;Application::CoreShutdown;CleanupEngine;CleanupAllObjects;delete_object_internal;delete_object_internal_step1;SpriteAtlas::MainThreadCleanup;SpriteAtlas::CleanupPackedState;SpriteAtlasDatabase::RecordSpriteAndAtlasRelationship

The interesting part, with ; replaced with newlines, is this:

Code (csharp):

1. SpriteAtlas::MainThreadCleanup
2. SpriteAtlas::CleanupPackedState
3. SpriteAtlasDatabase::RecordSpriteAndAtlasRelationship

120.000 times!

I would suggest that Recording the relationship between Sprites and their atlases is probably not something Unity needs to do when we shut down Unity This might have been fixed in SpriteAtlas V2, who knows.

@richardkettlewell, I tried to open the log in https://www.speedscope.app/, but it failed. The failure I get in the console (Failed to load format RangeError: Invalid string length) doesn't surprise me if it's trying to handle the stalls.log; I'm getting some lines in there that's 8783 characters long, due to being a 93 calls deep stack trace with some very, very chunky signatures.

Should I send the stalls.log as a part of a bug report? Should I PM it? Should I attach it to this post?