Game Dev Cheat Sheet

Build errors

Unexpected error in Burst compilation: System.AggregateException: One or more errors occurred.

The exact message

Unexpected error in Burst compilation: System.AggregateException: One or more errors occurred.
Variants of this message
  • Unexpected error in Burst compilation
  • System.AggregateException: One or more errors occurred.
  • Unable to load the unmanaged library
  • Burst internal compiler error
  • BuildFailedException: Burst compiler failed running

What it means

Burst failed somewhere inside its own compilation pipeline rather than rejecting your code, so it reported the wrapper exception instead of a BC error with a line number. The AggregateException is only a container: the useful message is the inner exception underneath it, which usually names a file, an error code or a missing tool. Almost every occurrence is environmental rather than a problem with the job you just wrote, which is why the same project often builds cleanly on another machine.

Causes and fixes

Ranked by how often they actually occur, most common first.

  1. The Burst cache is stale or corrupt

    Burst caches the native libraries it generates under Library/BurstCache, and Unity caches the surrounding build artefacts under Library/Bee. A cache that no longer matches the code it was built from produces failures that look random: the same project compiles one day and throws on the next, or one machine fails while everybody else is fine. Unity has fixed at least one bug of exactly this shape, where Burst returned out of date cached libraries and deleting the cache was the documented workaround.

    The fix: Close the Editor, delete Library/BurstCache and Library/Bee, then reopen the project. Deleting them with the Editor running achieves nothing, because Unity holds the files open and writes them back on exit. Both folders are regenerated, so nothing is lost beyond the time it takes to recompile.

    Run these with Unity closed, from the project root. Both folders are caches and are rebuilt on the next launch.

    # Windows
rmdir /s /q Library\BurstCache
rmdir /s /q Library\Bee

# macOS and Linux
rm -rf Library/BurstCache Library/Bee

# Neither folder belongs in version control. If either is
# tracked, a teammate's stale cache arrives with their next
# commit and the error follows it.

    Source: Burst changelog 1.8.0-pre.1: out of date cached libraries, BurstCache workaround, Unity Discussions: internal compiler error for Burst, resolved by deleting Library/Bee

  2. Windows blocks the library Burst just generated

    Burst compiles to an unsigned .dll in Library/BurstCache/JIT and then loads it. Windows Smart App Control and WDAC policies block unsigned libraries at load time, so compilation succeeds and loading fails. The inner exception is the giveaway: it names the generated file and an operating system error code, most often 4551 or 126. Nothing in the project is wrong, which is why the failure follows the machine rather than the repository.

    The fix: Read the error code in the inner exception first. Delete the specific .dll it names and recompile, which is enough to get moving while Smart App Control is in evaluation mode, then turn Smart App Control off or move the project outside its scope for a lasting fix. Updating to Burst 1.8.30 or later also helps, because Burst now detects this case, logs a clear warning and deletes the blocked library itself.

    Source: Unity Discussions: Burst error 4551, Windows Smart App Control blocking JIT libraries, Burst changelog 1.8.30: warns and deletes libraries blocked by Smart App Control or WDAC, Unity Discussions: unable to load unmanaged library, error code 126

  3. Security software quarantined the Burst toolchain

    Burst shells out to its own bundled executables, including the linker burst-lld-18-hostwin.exe. Endpoint protection treats an unsigned compiler writing native code as suspicious and removes or blocks the binary, so the inner exception reports that the system cannot find the file specified even though the package looks correctly installed. Managed corporate machines hit this far more often than home ones, and it typically appears the day after a security policy update rather than after any project change.

    The fix: Check that the executable named in the inner exception actually exists on disk. If it is missing or blocked, have the Burst package folder excluded from real time scanning rather than running the Editor as administrator, which does not address the block and introduces a separate problem.

    The paths worth checking, and excluding from scanning where a policy allows it.

    # The toolchain that gets quarantined
Library/PackageCache/com.unity.burst@<version>/.Runtime/hostwin/

# The libraries Burst generates and then loads
Library/BurstCache/JIT/

# Unity's shared package cache, where a partly extracted
# package can also leave the executable missing
%LOCALAPPDATA%\Unity\cache\packages\

    Source: Unity Discussions: Burst compile error in Unity 6, burst-lld-18-hostwin.exe blocked by antivirus

  4. The Burst package does not match the Editor

    Upgrading Unity, or updating Burst on its own, can leave the project with a Burst version that the rest of the package set was not built against. A partly downloaded or partly extracted package produces the same symptom, because the compilation pipeline is present but one of its pieces is not. Burst clears its own JIT cache when the version changes, so a mismatch that survives that usually means the package itself is wrong rather than the cache.

    The fix: Delete the Burst folder from Library/PackageCache and the global package cache under %LOCALAPPDATA%\Unity\cache, then let the Package Manager resolve again on the next launch. Pin Burst to the version the Editor ships with rather than the newest available, and update it only alongside the packages that depend on it, such as Collections, Mathematics and Entities.

    Source: Unity Discussions: Burst internal compiler error, package cache cleared and Burst updated, Burst changelog 1.3.0-preview.12: JIT cache is cleared when changing Burst version

  5. The platform toolchain is missing at build time

    Building a player compiles Burst code ahead of time into a single native library per target, and that step needs the platform's own toolchain. Windows needs the C++ build tools and the Windows SDK, Android needs the NDK, and the Apple platforms need Xcode. When the tools are absent, or the Editor cannot work out which version to use, the failure surfaces during the build rather than in the console while you work, often as a BuildFailedException wrapping the same aggregate exception.

    The fix: Install the missing workload for the target platform: Desktop development with C++ in the Visual Studio Installer for Windows, or the NDK through the Unity Hub for Android. Where you need a build before the tools are available, untick the target under Edit then Project Settings then Burst AOT Settings, which builds without Burst optimisations rather than failing.

    Source: Burst manual: building your project, toolchains and AOT compilation, Unity Discussions: BuildFailedException, Burst compiler failed running, fixed by installing the C++ build tools

How to prevent it

Expand the console entry and read the inner exception before doing anything else. The aggregate exception is a wrapper and carries no information of its own, while the exception underneath names a file, an error code or a missing tool, and that is what decides which fix applies. Working through the fixes in order without reading it turns a two minute job into an afternoon.

Keep the Library folder out of version control. Sharing a cache between machines is how one developer's stale or blocked library becomes everybody's build failure, and the folder is rebuilt on every machine anyway.

Update Burst with the packages that depend on it rather than on its own. Collections, Mathematics, Entities and the render pipelines are all built against a particular Burst, and moving one of them alone is the most common way to introduce a mismatch that only appears at compile time.

On continuous integration, delete Library/BurstCache before the build. A fresh compile costs a few minutes and removes the whole class of stale cache failures from a machine nobody is sitting at.

Install the platform toolchain when you add a build target, not when you first need a release build. A missing NDK or C++ workload is trivial to fix on the day you set the target up and disruptive on the day you are trying to ship.

Unity version differences

The wrapper wording has been stable across Burst 1.6 through 1.8, so the version matters less than what the inner exception says. Burst 1.3.0-preview.12 began clearing the JIT cache when the Burst version changes, and 1.8.0-pre.1 fixed a bug that returned out of date cached libraries. Burst 1.8.30, released in July 2026, detects libraries blocked by Windows Smart App Control or WDAC, logs a warning naming the cause and deletes the blocked library so it is rebuilt, which turns the most confusing form of this error into a readable one.

Related errors

Related tools

Sources

Frequently asked questions

Is this error caused by my code?
Usually not. Burst rejects unsupported C# with a BC error code and a line number, such as BC1091 for a managed type in a job. The aggregate exception is what you get when Burst's own pipeline fails, which points at the cache, the security software on the machine or a missing toolchain rather than at the job you just wrote. If the inner exception does name one of your methods, treat it as a Burst bug and report it with the method attached.
Where do I find the inner exception?
Click the console entry and read the detail pane underneath, or open Editor.log directly. The wrapper line is followed by the exception it contains, which is the one naming a file path, an error code such as 4551 or 126, or a missing executable. Console rows are truncated, so the log is more reliable than the list view.
Is it safe to delete Library/BurstCache?
Yes. It holds compiled output only, it is rebuilt the next time Burst compiles, and it should never be in version control. Delete it with the Editor closed, otherwise Unity writes the files back on exit and nothing changes.
Can I just turn Burst off?
You can disable it to get unblocked, through Jobs then Burst then Enable Compilation in the Editor, or by unticking the target under Burst AOT Settings for a build. Both are temporary measures: Burst compiled jobs typically run several times faster than the same code without it, so shipping with it off gives up the reason the code was written as jobs in the first place. Burst also cannot be uninstalled, because the render pipelines and several core packages depend on it.
Why does it only happen on one machine?
Because the common causes are local to a machine rather than to the project: a stale cache under Library, a security policy blocking the generated library, quarantined toolchain executables, or a build target whose tools are not installed. That is also the quickest diagnostic available to you. If a colleague builds the same commit cleanly, stop looking at the code and start with the cache.

Last updated: