I’m working on Unity 2020.3.0f1, targeting UWP ARM64 devices and using Microsoft’s MRTK. I’m dealing with constant delays in the editor that make it impossible to do my job.
Nearly every time I attempt to build my application, the build will get stuck perpetually (and I mean it - I left one of these waiting until it said “busy for 7:00:00” a few days ago) on either:
Gathering Build Data…
Importing Assets… (No idea why this would trigger on build, but it does)
There are nearly no assets in my project and most of my changes between builds consist of small scene changes or script changes.
Before manually disabling all automatic importing and asset refreshing, there was also essentially a random chance I would get bricked out of Unity by infinite “Importing Assets…” every time I alt-tabbed back into Unity.
I don’t experience this kind of delay on other Unity projects. As I write this, Unity has been “Gathering Build Data” for 11 minutes straight. Any workarounds to make Unity behave just a little while working on this project? A way to cancel out of these dialogs without terminating unity entirely, at least?
Hey, thank you for posting this problem. I don’t think this is a known issue, and so please file a bug for it.
Since you’re using MRTK, I strongly recommend you also post this issue on Microsoft’s HoloDevelopers Slack channel (if you haven’t already), which you can join via this link: https://holodevelopersslack.azurewebsites.net/. You might get better help there.
Yeah that shouldn’t happen.
It sounds like something within the project (possibly within MRTK itself) is modifying an asset file or generating a new file under the Assets folder during the build process, which kicks off the Asset Importer.
Is there anything you can think of that might be writing to the Assets folder during the build?
Does the Editor log show any Asset file activity prior to Importing Assets showing?
Hi, I’ve just narrowed this down a bit - it’s almost definitely an issue with MRTK and not Unity itself. It triggers most often when using MRTK’s Build panel rather than Unity’s built-in Build window (which I had been avoiding because of earlier massive build issues, but which now seems to work just fine). It’s possible that ‘Importing Assets’ perpetually is still a problem during alt-tab, but as I’ve disabled automatic importing due to the project being unusable otherwise, I won’t really know. Other than that, the best workaround is to stay away from MRTK when possible. I’ve been using it for weeks and this sort of weird build behavior crops up on the daily.
I just managed to trigger the ‘perpetual import’ again by re-enabling Auto Refresh and Directory Monitoring - Unity and all its subprocesses just sit there for all eternity at 0% CPU and 0 MB/s disk usage (the project window process will occasionally rise to around 0.1% CPU and 0.1MB/s disk usage just for the sake of tormenting me, but it never accomplishes anything!)
Checking the logs during this activity, all that I can see is a good amount of this, but it appears to be from prior to getting stuck as it hasn’t added anything new for the past 5 mins.
Struggling to make it happen once again - having that age-old issue of being unable to reproduce a bug just after telling others about it! I’ll reply again with a dump when I manage to make the editor do its thing again.
Hello, I’ve managed to trigger the issue and create a dump. What is the best way to send a dump directly? I’d rather not share it publicly on the forum.
Hey, thanks for that dump. It seems like for some reason, something is calling “EditorUtility.DisplayProgressBar” and forgets to call “EditorUtility.ClearProgressBar”. Unfortunately, it’s not clear whether it’s something on Unity’s side or on your project’s side.
Could you search for “ProgressBar” code in your C# scripts (including all used packages)?
If nothing comes up, could you report a bug and work with our QA to help us reproduce this so we could fix it?
Thanks for that lead, looks like it’s probably a bug in the Mixed Reality Toolkit and not on Unity’s end - I can find several instances where it calls DisplayProgressBar and fails to clear it at any point afterward, but these only occur in build-related code - I’m not sure why it happens sometimes during regular alt+tabs.
I am facing similar issues where the UWP build process doesn’t complete. It gets stuck for hours at (Building player - checking requirements). Although checking task manager shows that the process takes 0% CPU. Kindly help.
That sounds bizarre. Can you capture a dump file for the Unity editor and send it to me? You can capture it by finding Unity.exe in the process list in the task manager under Details tab, right clicking it and pressing “Create dump file”. Make sure to compress it to a .zip or .7z file before uploading it as it will make it much smaller!
Thank you for your reply. As I looked at Task Manager, there were two processes running Unity.exe, as shown in the attached picture. I have uploaded the zip dump files in a Google drive and shared with the link to those in a private message.
OMG… you found a really nasty bug. We have an O(m * n²) loop where “n” is the file count in your build and “m” is assembly count in your build. Since your project has a lot of files in the build, it just takes forever. I’m preparing a fix for this. I don’t see how you can work around it unfortunately. This regression has been introduced in 2020.1 and has gone unnoticed since .
I was able to reproduce this issue by generating a synthetic project with a lot of files. I fixed it for Unity 2022.1 and I’m going to be backporting it all the way back to 2020.3 LTS.
.