Launching project gets stuck on "Importing (busy for XX:XX)"

I have been getting this issue for many recent versions of unity. Basically, I keep updating with the hope that It would be fixed in a certain version. But it still happens.

I have seen other forum threads from a long time ago address a similar issue, but I don't know if the causes are the same. And I did try the solutions that were mentioned in that thread, which seemed to work, but after restarting my computer, it continues to do the same thing again.

Basically, when I launch my project through Unity Hub, as you normally should, I will get stuck on the loading window as shown in this image. And the "busy time" will keep going up forever.


I can fix this by then going into the Task Manager is force quitting Unity and relaunching, and it launches 100%.
But then if I shut down and start up my computer, I have to do the same thing all over again... Annoyingly...

I'm not 100% sure if deleting the library folder actually fixes the issue. I tried it, but I still get this issue the next day (after PC shutdown).

I don't know if maybe it's associated with a file of sorts??? And the file causes unity to take infinite time to import because it keeps "retrying"? No clue.

I forget which exact version of Unity I had this issue in, but I know most of the versions I've had this issue with are all 2021.1

Right now I am in 2021.1.19f1
But I have updated versions at least 5 times, but those versions were still 2021.1.XXf1 etc etc.

 

*BUMP UPDATE*

So, I have confirmed that for some reason this issue has to do with only my specific project files.
This issue does not happen with a brand new project. So I need to find out what file may be causing it to hang...

 

I have the same problem. It seems to be a unity bug https://forum.unity.com/threads/2020-3-15f2-importing-at-every-editor-launch.1153883/#post-7458074

 

I read through the thread you linked, and decided to investigate more by looking at the log files, like that other person suggested.

First, I moved the existing log files out of the folder (AppData/Local/Unity/Editor)

Next, I restarted my computer. (because the issue only happens after restart)

I then launched my project again, while watching the folder that holds the log files.
While unity was launching, it created a new "Editor.log" file.

When it got to "Importing" on the progress bar, I noticed where the log file ended.

These were basically the last few lines of the log:

*** Tundra build success (0.27 seconds), 0 items updated, 761 evaluated
AssetDatabase: script compilation time: 0.952068s
Begin MonoManager ReloadAssembly
Symbol file LoadedFromMemory is not a mono symbol file
Symbol file LoadedFromMemory is not a mono symbol file
Symbol file LoadedFromMemory is not a mono symbol file
Native extension for WindowsStandalone target not found
Refreshing native plugins compatible for Editor in 138.76 ms, found 6 plugins.
Preloading 0 native plugins for Editor in 0.00 ms.

Then, I force quit the still "importing" unity process in Task Manager.

Relaunched the project again, to where it launched normally (as this is basically what has been happening, nothing new).

But now, the log file should contain more info about what it was doing. Because somehow, something must be changing when I force quit unity; and when I restart my computer.

Interestingly, there seems to be something that looks like an error message directly after where the ^ above log message ^ shows up in the file. But the second time unity launches, it seems to "brush off" this error. Even though it is "fatal".

This is the message that follows:

Stacktrace:

at <unknown> <0xffffffff>
at (wrapper managed-to-native) System.Reflection.FieldInfo.internal_from_handle_type (intptr,intptr) [0x00015] in <695d1cc93cca45069c528c15c9fdd749>:0
at System.Reflection.FieldInfo.GetFieldFromHandle (System.RuntimeFieldHandle) [0x0002a] in <695d1cc93cca45069c528c15c9fdd749>:0
at System.Reflection.MonoModule.ResolveField (int,System.Type[],System.Type[]) [0x0003e] in <695d1cc93cca45069c528c15c9fdd749>:0
at System.Reflection.Module.ResolveField (int) [0x00004] in <695d1cc93cca45069c528c15c9fdd749>:0
at Unity.Burst.Editor.BurstReflection.CollectGenericTypeInstances (System.Reflection.Assembly,System.Func`2<System.Type, bool>,System.Collections.Generic.List`1<System.Type>,System.Collections.Generic.HashSet`1<System.Type>) [0x000e5] in C:\Users\Andre\Documents\Unity Projects\Below The Stone\Library\PackageCache\com.unity.burst@1.5.6\Editor\BurstReflection.cs:800
at Unity.Burst.Editor.BurstReflection.FindExecuteMethodsForGenericInstances (System.Collections.Generic.HashSet`1<System.Reflection.Assembly>,System.Collections.Generic.HashSet`1<System.Type>,System.Collections.Generic.Dictionary`2<System.Type, System.Type>,System.Action`1<Unity.Burst.Editor.BurstCompileTarget>,System.Collections.Generic.List`1<Unity.Burst.Editor.BurstReflection/LogMessage>) [0x0004c] in C:\Users\Andre\Documents\Unity Projects\Below The Stone\Library\PackageCache\com.unity.burst@1.5.6\Editor\BurstReflection.cs:206
at Unity.Burst.Editor.BurstReflection.FindExecuteMethods (System.Collections.Generic.List`1<System.Reflection.Assembly>,Unity.Burst.Editor.BurstReflectionAssemblyOptions) [0x001d8] in C:\Users\Andre\Documents\Unity Projects\Below The Stone\Library\PackageCache\com.unity.burst@1.5.6\Editor\BurstReflection.cs:134
at Unity.Burst.Editor.BurstLoader/<>c__DisplayClass40_0.<TriggerEagerCompilation>b__0 () [0x00001] in C:\Users\Andre\Documents\Unity Projects\Below The Stone\Library\PackageCache\com.unity.burst@1.5.6\Editor\BurstLoader.cs:615
at System.Threading.Tasks.Task.InnerInvoke () [0x00010] in <695d1cc93cca45069c528c15c9fdd749>:0
at System.Threading.Tasks.Task.Execute () [0x00011] in <695d1cc93cca45069c528c15c9fdd749>:0
at System.Threading.Tasks.Task.ExecutionContextCallback (object) [0x00006] in <695d1cc93cca45069c528c15c9fdd749>:0
at System.Threading.ExecutionContext.RunInternal (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00073] in <695d1cc93cca45069c528c15c9fdd749>:0
at System.Threading.ExecutionContext.Run (System.Threading.ExecutionContext,System.Threading.ContextCallback,object,bool) [0x00004] in <695d1cc93cca45069c528c15c9fdd749>:0
at System.Threading.Tasks.Task.ExecuteWithThreadLocal (System.Threading.Tasks.Task&) [0x00054] in <695d1cc93cca45069c528c15c9fdd749>:0
at System.Threading.Tasks.Task.ExecuteEntry (bool) [0x0005e] in <695d1cc93cca45069c528c15c9fdd749>:0
at System.Threading.Tasks.Task.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem () [0x00002] in <695d1cc93cca45069c528c15c9fdd749>:0
at System.Threading.ThreadPoolWorkQueue.Dispatch () [0x00075] in <695d1cc93cca45069c528c15c9fdd749>:0
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback () [0x00000] in <695d1cc93cca45069c528c15c9fdd749>:0
at (wrapper runtime-invoke) <Module>.runtime_invoke_bool (object,intptr,intptr,intptr) [0x0001f] in <695d1cc93cca45069c528c15c9fdd749>:0

=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================

I don't know what a "SIGSEGV". Maybe I'll look into it. But maybe this is what the issue is, because this looks like something that shouldn't be happening. And this is the message that *WOULD* show up if Unity never got stuck on "Importing" for me. So I hope maybe someone can explain what this error means.

I know there has to be some code maybe, or some unity package that is causing this.

 

Recently, I did some hardware upgrades on my PC. And in the process, I had to do a clean install of Windows and copy all my important files over.

I then launched my Unity project from the hub and surprisingly now, it doesn't get frozen anymore.
I did end up installing a much newer version of Unity hub.
And I also updated my project to 2021.1.27f
So I don't know if any of those things fixed the issue. But I would not be surprised if the issue was rooted in something in a temp directory, maybe something in %AppData% or in the registry? Because I did a fresh install, so it might've deleted a bunch of stale cache files or somthing. Who knows.

I'm just reporting everything that has changed since then so that maybe people can explore these options to solve the issue for themselves.

 

Do you have and SSD in your computer and the project files are on the SSD?

 

Yes. (it was always on an ssd)

Previously, before my recent upgrades, I had a 250GB SSD where my files were held. And it was actually getting close to full. Like there was always about 20 GB free.

I got a new 1TB SSD that I moved all of those files onto. So now I have more space.

Now that you bring this up, and I am thinking about it, the issue **may** have also been caused by having very little drive space left? And Unity would get into an infinite loop where it kept trying to find more drive space. Not sure.
But if other people having the same issue had their files on an almost full drive, then that is solid proof for what was going on.

 

My theory is that disk fragmentation will slowdown disk access. but if you have them on an ssd that should not be an issue I think. I mean not sure how ssd deals with fragmentation but should be faster than a spinning disk

 

That could have some connection.
Although I started having this issue while the project files were already on an SSD.

But whatever has changed since then, it must've solved it.

Like I said, I had made a fresh install of Windows and transferred all my files over to that. So maybe there was something wrong in the registry. But I also updated my project to a more newer version of Unity. So maybe it was simply a developer bug that finally got taken care of.

Also. When I did have the issue, there were a few times where I just walked away from the pc. or just waited a long time, like well over 20 minutes, probably even an hour. And it would just hang there forever. So even if it was fragmentation slowing things down, it would be slowing it down by ludicrous amounts.
But for some people, it might be beneficial to do a defragmentation, yea.

 

That's not true. New projects may experience the same problem.

 

hello i have same problem but i waited it is loading

 

Still happening in 2022.2 version for 3D projects with many fbx files

 

Here is the thing: Unity has problems with its local data as soon as you install a newer Unity version in which you want to migrate your project. I just had the same problem with the latest 2022 LTS migration/import. It got stuck. Reading comments about it everywhere, from here to reddit, stackoverflow braught me to one conclusion, which solved the whole thing and my 200GB of assets in this project were imported faster than usual, and I was like 'huh, how? what?'. Tested my scenes and everything works fine!. And I have tons of custom shaders, all kinds of addons, and all the high res meshes, like trees etc and everything was imported faster than usual. Just the whole cache data needs to be generated again, which brings a clean structure managed by the newer system. Ok, so how did I solved the issue? Simple:

Delete the following cache folders:

C:/users/<youruser>/AppData/Roaming/Unity/cache
C:/users/<youruser>/AppData/Roaming/Unity/Caches
C:/users/<youruser>/AppData/Local/Unity/cache

and since cleaning is so much fun, this folder too, which is just the GI-cache xD
C:\Users\/<youruser>\AppData\LocalLow\Unity\Caches\GiCache

Import now! Should work all fine.

Also, before importing: Right click and close all tray icon apps like crappy skype, discord and all the other tools, that prevent importing unity faster, because of their priority calls they constantly make. I have a very clean system, because I take my work and workspace serious. However, I noticed working with the PC, surfing, or whatever, next to import can cause Unity to halt too. But if you clean all the cache folders, start the import again and just watch and meanwhile make yourself a coffee or something, the editor screen will appear faster than you can imagine.

 

unity my despised (i had to fight it for like, three hours for it to even let me build the game this morning)