Addressables build stuck on "Write Serialized Files" for hours, uses all RAM+pagefile then crashes

[LazloBonin]

Hi,

I’m no longer able to build addressables for our game, meaning I can’t build the game.

As the title indicates, the process gets stuck on “Write Serialized Files”, uses all the available RAM and virtual memory from the pagefile, and crashes Unity after hours of being stuck.

Setup:

• Unity 2020.3.48f1 LTS
• Addressables package version 1.21.19 (avoiding 1.21.21 due to a reported major performance regression)
• High-end development PC (16GB RAM, SSD, Intel 13th Gen Core i7-13700, etc.)

What I’ve tried:

• Splitting our addressables into smaller bundles

• Running “Check Duplicate Bundle Dependencies” and clean any duplicate entry

• Disabling CRC on all bundles

• Rebuilding the entire project Library/

• Increasing the pagefile to 64GB

• Restarting my PC

Related issues I’ve found, but I don’t think they’re the fix:

• " Build addressable stuck\crush when write serialized files " (appears to be the exact same issue, but the user reported fixing it by buying a better PC, which is not a realistic solution given my specs, and also the fact that I used to be able to build our project recently)

• " [BUG] Building Asset Bundles never finish building (Write Serialized Files) " (same issue, no fix except maybe downgrading lighting settings for a scene, but we don’t use lightmap baking)

• " 1.1.4 Cannot Build Player Content " (seemingly similar issue, reportedly caused by a big FBX, but in their case they knew the FBX in cause; in mine I don’t know what FBX it is, if even if it is a FBX, nor how to find it)

• “Building addressables with cached elements using ScriptableBuildPipeline 1.21.21 EXTREMELY slow” (but it seems to be a regression introduced in 1.21.21, so I’m staying at 1.21.19)

• " Very long processing time on “Write Serialized Files” when building assetbundles without changes " (this looks like it might be related, but I don’t know what “UseCache” is or how to disable it, plus it seems like the reported issue was fixed in 1.7.0)

Questions:

• Is there any way I can know which bundle is being serialized with this dialog path in the screenshotted progress bar? It’s always the same ID which I assume is a hash (CAB-385dd2…), but I can’t seem to find the hash associated to a bundle in the GUI. I looked in Library/BuildCache, but that ID can’t be found, presumably before Unity crashes before it could serialize it.

• Say I have to test each bundle, is there even a way to do that? Can I build a single bundle at a time and see what’s crashing? How? If not, should I just start deleting bundles in a binary-search way to build until it starts working again?

Please help! This is an urgent issue for us, as it’s preventing our final build from entering QA on time. Any help would be greatly, greatly appreciated. I’m at the end of my wits here. Please share any insight you may have to debug this!

[LazloBonin]

I figured out the cause: we had too many shader variants (probably went up exponentially because of one or two new pragma multi_compile since the last successful build). I was able to trim down the number of variants by using shader_feature when possible.

I imagine Addressables should probably error out more nicely in this case and I should probably file a report, but unfortunately I’m too rushed at the moment to do so.

Someone also pointed out it may be related to this memory issue , which in turn references five other memory leak reports describing a similar problem. If an Addressables dev finds this thread, please consider improving the error reporting / failure handling in cases where a bundle is too big to be supported. It’s fine to ask the user to shrink/split it somehow, but we need some help figuring out what to target, otherwise we’re left in the dark with a memory leak crashing the system.