Actor 150 errors in Pit runs

PC Bug Report
1

I’m going to completely repost this because after further investigation I believe I have found the cause of my crashing and it changes the scope of my original post quite a bit….

Full investigation results — Pit crash (c0000005) + data corruption, build 3.1.1.72903

Posting a full update after several weeks of digging into two separate issues that turned out to be potentially unrelated to each other, but both worth documenting. Long post, but I wanted to give the full trail in case any of this is useful for reproducing or fixing things on your end.

System configuration

  • Custom-built desktop, SteamOS 3.8

  • AMD Ryzen 5 5600X, AMD Radeon RX 9070 XT (RDNA4), 32GB DDR4-3200

  • Single NVMe drive, ext4, default SteamOS install

  • Steam version of Diablo IV, build 3.1.1.72903

Issue 1: Data corruption on first launch after the 3.1.1 update

After a clean SteamOS reinstall, Diablo IV downloaded and ran fine for one short session. Running Verify Integrity of Game Files afterward began failing repeatedly with corrupted data errors. The debug log showed the actual cause:

[Sigma] [tact] Failed decode block (0): hash verification failed
[Sigma] [tact] Read failed for file '...' while streaming is disabled. Error (8): data error
[Game] TACT data error detected.

Steam’s own content_log.txt traced this to a specific bad chunk delivered from Steam’s CDN:

Failed updating depot 2344521 while unpacking bad chunk
fcd8127aec3e6ceee027b29da61a1275c9029b70
(Unpack failed) cache14-ord1.steamcontent.com/depot/2344521/chunk/...

Repeated verify attempts converged from 10 flagged files down to a single 1.05MB file that failed identically every time — the signature of a bad CDN edge-node cache, not a local disk issue (confirmed via SMART, extended self-test, and a full read-only badblocks scan, all clean). Switching Steam’s download region (Settings → Downloads → Download Region) resolved it immediately; verify came back clean on the next pass. Reported this to Valve/Steam Support separately with the chunk hash and server hostname. This error has not returned.

Issue 2: Reproducible crash in the Pit (ACCESS_VIOLATION / c0000005)

Separately, and starting the same week, the game crashed reproducibly a few minutes into Pit runs (though it may not be limited to the Pit):

UNHANDLED EXCEPTION: ACCESS_VIOLATION (c0000005)
Crashed thread: 'JobWorker' (varies)

Every crash was preceded by dozens to hundreds of repeated errors:

[Game] sAttachmentCreate: Cannot find attachment with Actor ID 150 when creating
Play_Class_FxKit_Sorc_Lightning_Rope_Loop_2ch_3P_Enemy

Same Actor ID (150) and same FX kit every single time, across multiple separate sessions, on a Barbarian (not a Sorcerer) — this reads like an enemy in the Pit using a Sorcerer lightning FX kit that its own rig doesn’t have the attachment socket for. TACT logged zero errors in any of these sessions, ruling out corrupted data as the cause of this specific crash — the game files were provably intact each time.

Cross-platform testing

To isolate whether this was hardware/OS-specific, I reproduced the exact same build (3.1.1.72903), same Steam depot, same character, on two other machines:

  • Windows 11, RTX 5070: the identical sAttachmentCreate / Actor 150 error appeared 330 times across a single session (two separate spawns of whatever enemy carries this FX kit) — zero crashes.

  • Bazzite (handheld, AMD RDNA 3.5 iGPU): same error present, reproduced across multiple Pit runs — zero crashes.

So the underlying broken content is universal — every platform hits the same error (at least the Steam version of the game) — but only my RDNA4/SteamOS desktop ever escalated it to a fatal crash.

Isolating the crash mechanism on RDNA4

On the SteamOS machine, I tested with RADV_DEBUG=zerovram MESA_SHADER_CACHE_DISABLE=true launch options:

  • With the Mesa/RADV shader cache disabled entirely: 12 consecutive Pit runs, zero crashes (at a real cost to framerate).

  • After clearing ~/.cache/mesa_shader_cache and re-running with caching re-enabled (fresh cache, normal performance): 13 more consecutive clean runs.

25 total clean runs, 2,000+ combined occurrences of the Actor 150 error, zero crashes either way — versus reliably crashing at 35–69 occurrences beforehand. Best working theory: the first time this specific machine ever compiled/cached the shader for that broken FX kit, the compile-and-cache-write itself went wrong on RDNA4’s current Mesa/RADV stack, corrupting that one cache entry and crashing simultaneously. Every subsequent encounter then read the corrupted entry and crashed again, until the cache was cleared and a fresh compile succeeded. Either that, or it compiled a corrupt shader due to Steams CDN download issue.

Summary

  1. Data corruption (resolved, likely unrelated to the crash): a bad CDN edge server delivered a corrupted chunk during the 3.1.0 or 3.1.1 update. Fixed by switching Steam download regions.

  2. Local shader cache corruption (mitigated, not a permanent fix): clearing ~/.cache/mesa_shader_cache resolved the crash for 25+ consecutive Pit runs. Whether this is connected to the CDN issue above, or purely a symptom of RDNA4’s Mesa/RADV driver maturity on Linux mishandling a first-time shader compile for this specific broken content, is currently inconclusive — I lean toward the latter given the CDN issue was already fixed in a prior session before this crash first occurred, but I can’t rule out a connection with full confidence.

  3. Root cause (still open, needs a fix on your end): regardless of what makes it fatal on my specific hardware, the actual bug is the same everywhere — Actor ID 150 in the Pit references an FX kit (Play_Class_FxKit_Sorc_Lightning_Rope_Loop_2ch_3P_Enemy) that its rig doesn’t have the attachment socket for. This is present in every build-3.1.1.72903 session I’ve tested, on every platform, regardless of crash outcome. This is the part that needs a data/content fix from Blizzard — everything else here is downstream of it.

As I have a way to mitigate this issue, I don’t require any further support. But I wanted to provide this detailed report in case the issue has affected anyone else and to help you address the underlying issue.

Thanks,

CJB