SHDR004
Everything went magenta after the upgrade: the shader no longer compiles
The most visible way an upgrade goes wrong: shaders that compiled fine on the old version stop compiling, and every material using them renders magenta — or doesn’t render at all. Include paths move, macros are renamed, HLSL syntax tightens, and pipeline-specific includes (Lighting.hlsl, the URP core library) shift between versions.
What the scan looks at
Unity records shader compile messages at import time; the scan reads them per shader asset (ShaderUtil.GetShaderMessages) and reports any shader with at least one error, with the first error’s text and line number when available. Critical severity, because the visual impact is total for anything using that shader.
Shaders under Packages/ that you can’t edit are reported too — knowing that the breakage is in a package you don’t own is the useful part of the finding.
How to fix it by hand
- Locate the shader and open its Inspector — Unity lists the full error set there, which is more than the first message the finding quotes.
- Fix the source if it’s yours. The recurring upgrade breakages, in rough order of frequency:
#includepaths that moved,UnityObjectToClipPos/ macro renames,SV_Targetand semantics tightening, and URP/HDRP core includes that changed folder between package majors. - Get an updated version if it came from a store asset or package — this is usually a published fix rather than something to patch locally.
- If the asset is unmaintained, switch the affected materials to a shader that ships with your current pipeline. Losing a bespoke look is better than shipping magenta.
Check package compatibility while you’re here: a package that declares a minimum Unity version higher than your editor produces the same class of breakage from the other direction (MIG.PackageUnityIncompat).
While the shader Inspector is open, it’s worth glancing at the variant count in the same window — a shader that survives the upgrade can still be the reason your builds take 40 minutes (SHDR001).
What PerfLint does about it
Report-only. Rewriting shader source is not a rename-style edit — the fix depends on which pipeline version you’re targeting and what the shader was trying to do — so the tool locates the failure and quotes the compiler rather than pretending to fix it.
Note that this rule complements MAT001: there the shader compiles but belongs to the wrong pipeline; here the shader itself is broken. When a whole scene goes magenta after an upgrade, it’s usually worth checking both, plus MAT003 for materials whose shader disappeared entirely. We ran that exact sequence taking Unity’s Viking Village to URP on Unity 6 — write-up here.
Check your own project. The scan is free, runs entirely on your machine, and reports this rule with the exact assets that trip it — nothing is uploaded.
Last reviewed · All rules