Script compilation sometimes fails with "Internal Build System Error" and only fix is restarting Unity Editor

Sometimes when reloading scripts Unity will fail with an “Internal build system error” and refuse to recompile.

Effect:
It’s considered a compile error so I can’t go into play mode, but most of other editor’s functions still work.

Fixing:
Neither changes in code or importing assets do anything, the only fix I found is restarting the whole editor.
(*There was a period where forcing the code to reload would fix the error. So I had a button to reimport a single script. Sadly, this fix stopped working at some point and I’m back to restarting the whole editor)

Occurrence:
The occurrence really does seem random, but it has by far the highest chances of occurring after switching git branches with relatively large diffs.

Sometimes it will happen several times in a row. (ex. switch git branch while unity editor still open, get the error. Close editor open it again, get the error again. After closing and opening the second time it works fine)

It can still happen if you do a very small change in the code though.
(Editor runs fine, play mode works, do some one code change, still works, another small change and suddenly it may break)

Error message:
Internal build system error. read the full binlog without getting a BuildFinishedMessage, while the backend process is still running

Any ideas on what may be causing this or how to fix it?

At first I thought it was the fault of some hot code reload package, but the error still happens with it disabled.

I would try deleting the Library folder.

If it comes back after switching git branches, get in the habit of closing the editor before switching branches. Consider that this is effectively pulling the rug out under the editor and replacing it with a largely different set of assets. For the most part it works fine but the more things change, the more likely something will break.

Also, if you happen to have the Library, Temp or Obj folders under source control that would also contribute to the problem.

I have Library, Temp and Obj all ignored in git, we know these shouldn’t be source-controlled.

Deleting the library doesn’t seem to help any more than restarting the Editor.

Closing editor before switching branches does seem like a good idea, if not only bit time consuming.

If it was only after switching branches, the case would be clear-cut, sadly it isn’t. The error will randomly occur at some unlucky code reload, regardless of actual size of the change.

Ideally I’d like to know anything more about the error itself, such as maybe it has something to do with Asset Postprocessors, since I have many packages in project and some of them run some stuff in the background, but they’re either essential in the project or turning them off didn’t achieve anything.

When I tried looking the error up all I found was people indeed having problems with the Library and they couldn’t even open the project properly or build it – In my case, most of the time my project works just fine and Builds complete successfully too. If the error occurs, a simple editor restart fixes it (even though it takes a while).

Maybe it’s something that Unity added in some version at some point, where restarting the Editor fixes this issue (like it automatically finds out that library is an issue and refreshes whatever it needs to in order to fix itself)?

What Unity version? Try the latest patch if you haven’t, and particularly more so the further behind your version is to 46f1.

Since you have Asset Postprocessors from external sources I’d check those for obvious faults, such as calling AssetDatabase.Refresh anywhere inside, or any uses of Start/StopAssetEditing that isn’t guarded with a try/finally as per documentation.
Particularly in the postprocessor callbacks (except for PostProcessAllAssets) one must not create/import or modify existing assets.

When that issue occurs, try Ctrl+R (Refresh) to see if that helps.

Background as in background thread? That would be problematic because Unity is largely not threadsafe.

If you have “parallel imports” enabled in Project Settings (in General or Editor I think), try disabling that. Custom Importers are not always compatible with parallel imports.

32f1 (6000.0.32f1)

Updating Unity will be first thing I’ll try in that case.

The option is turned off. Didn’t know it even existed.

I was being general, because admittedly there might be more things happening than I may be aware of.
But one example of background process is Find Reference 2. It’s a utility package that helps you find where an asset is used, but it has it’s own cache that’s being updated automatically in background (at least that’s how I understand how it works).
Turning that off didn’t solve my issue though.

I suppose I’ll have to thoroughly analyze what other post-processors are doing, but seems like that will take a while. Would be nice if updating the editor fixes it first.

Thanks for the info.

I’m seeing the same behavior with 2022.3.58 LTS and 6000.0.45 LTS. Compilation and subsequent import of a .NET Standard 2.1 DLL (i.e. a game library) manifests the issue 90% of the time. I tried creating a stand alone project to reproduce this bug for Unity but it does not manifest in a small test. The size of the library and/or size of the Unity project appears to be related to whether the bug manifests.

Did you ever find out where this alleged “binlog” is? It would be great to provide Unity a more detailed error message.

Sadly, no. Checking usual editor logs didn’t give me any useful information either.

The message seems to be written bit weird, so at some point I just assumed “read the full binlog without getting a BuildFinishedMessage” means unity thinks it should’ve been done compiling bit it isn’t, not necessarily that there’s a log somewhere I should check. Again, just assuming, I’d like to know for sure as well…

Initially, I suspected a race condition related to file read access—Visual Studio compilation and Unity import might be competing for access. However, since I’m copying the DLL into the \Assets folder, Visual Studio shouldn’t be holding a file lock at that point.

I checked Window’s real-time antivirus protection and realized I hadn’t set up an exclusion for the folder containing the Unity project. I’ve now added that exclusion and will test to see if it resolves the issue.

Disabling antivirus makes no difference.

Internal build system error. read the full binlog without getting a BuildFinishedMessage, while the backend process is still running

Just a small update, the error has not manifested in the last 4 weeks, which is a little bit surprising, because I updated the Unity version to 46f.1 in the middle of that period.

As mysteriously as it appeared, it also mysteriously disappeared (at least so far)

I’m on 2022.3.62f1 and it appears fixed. Strangely, it stopped happening a week prior to upgrading.