Unreal Engine 5.5 ShaderCompileWorker Crashes During Packaging - DDC and RHI Fix - How to Fix

Problem: Unreal Engine 5.5 packaging fails because ShaderCompileWorker crashes mid-build, usually after a long shader compile phase.

Common symptoms:

packaging stops with ShaderCompileWorker crashed or worker exit errors
UAT reports compile worker failure and aborts cook/package
crash appears only on one machine or CI runner
deleting Intermediate helps once, then failure returns

This usually means your build is hitting a bad shader permutation, stale Derived Data Cache state, or unstable RHI/driver combinations during mass compile.

Root cause

ShaderCompileWorker is a separate process. It can crash when:

stale or corrupt DDC artifacts are reused across engine/project changes
one shader/material permutation explodes compile complexity or hits driver edge behavior
RHI selection (often D3D12) is unstable on specific drivers/hardware during compile
CI and local machines compile with mismatched shader environment settings
plugins or custom shader code introduce invalid compile paths

So the fix is usually a controlled cache rebuild plus an RHI and shader-scope isolation pass, not random retries.

Quick fix checklist

Fully clear local and shared DDC paths for the affected build target.
Clean Saved, Intermediate, and prior packaged output.
Re-run package with verbose logging and capture first failing shader/material.
Test a stable fallback RHI profile (for example D3D11) to confirm RHI sensitivity.
Reintroduce risky shader features/plugins in small batches.

Step 1 - Rebuild cache and build state from clean inputs

Close Unreal and your build agents, then clear:

project Saved/DerivedDataCache
project Intermediate
project Saved/Cooked and old package output
shared DDC location used by team or CI (if configured)

Then run one clean compile/package pass.

If the crash disappears only after DDC purge, keep reading and lock prevention steps so it does not return on the next branch merge.

Step 2 - Capture the first real failing shader context

Do not debug from the last log line only. Find the first shader compile error context:

run packaging with verbose log flags
locate first worker crash marker
scan backward for material, permutation, platform, and feature level clues

You are looking for one problematic shader family, not every warning in the log.

Step 3 - Test RHI stability as a diagnostic gate

If your project defaults to D3D12, run one packaging pass with a stable fallback profile to test whether the crash is RHI-sensitive.

Examples:

temporary packaging profile targeting D3D11
disabling optional high-cost features during diagnosis

If fallback RHI packages cleanly while D3D12 crashes, lock drivers and investigate feature-specific shader paths before restoring default RHI.

Step 4 - Isolate plugin and material permutation risk

Common crash triggers:

experimental rendering plugins
custom HLSL paths or large material function graphs
broad permutation flags enabled globally

Isolation routine:

disable one suspect plugin/feature group
recook/package
re-enable in small batches
stop when crash reappears and inspect that delta

This gives you an actionable culprit instead of a generic worker crash label.

Step 5 - Normalize CI and local shader environments

If local packages pass but CI fails, compare:

engine patch version
GPU driver/runtime on build machine (for any GPU-dependent compile path)
shared DDC usage and invalidation policy
command-line cook flags and target platform profile

Many recurring worker crashes are environment drift, not project logic.

Verification checklist

After applying fixes, confirm:

two consecutive clean packaging runs pass on the same machine
CI packaging run passes with same commit and target
no worker crash lines appear in UAT logs
tested RHI profile matches release target
DDC reset and rebuild procedure is documented for the team

Alternative fixes

If crash appears only after enabling one rendering feature

Pin that feature behind a config toggle and ship with stable defaults while you validate a safer material/shader setup.

If crash appears only on one developer machine

Reinstall/repair toolchain components and align GPU drivers with known-good team baseline before deeper project surgery.

If crash happens only in Shipping package

Compare Shipping-only defines and strip settings. Some issues hide in Development but fail with Shipping optimization paths.

Prevention tips

Version your DDC strategy in project docs, including when to invalidate.
Keep a known-good RHI fallback packaging profile for emergencies.
Avoid wide shader permutation flags unless you need them.
Add a weekly CI smoke package to catch shader drift earlier.
Record first-failure shader clues in incident notes for reuse.

FAQ

Why does deleting Intermediate sometimes fix this once

Because stale artifacts are removed temporarily, but the underlying permutation or environment mismatch remains and reappears later.

Should I permanently switch from D3D12 to D3D11

Not automatically. Use D3D11 as a diagnostic/stability gate, then resolve the D3D12-specific cause if your release target needs it.

Is this always a bad material graph

No. It can also be cache corruption, plugin shader code, toolchain drift, or machine-specific RHI/driver instability.