The 0xc0000428 during WinPE boot is the kernel's code integrity module doing exactly what it's supposed to — rejecting any driver that doesn't carry a valid Microsoft-cross-signed or WHQL signature. On x64, this isn't optional; it's a hard enforcement baked into the boot path, independent of Secure Boot settings.
What likely happened: DISM's /Add-Driver will actually refuse unsigned drivers on x64 by default. If you got the driver into the image, you (or your build script) probably used the /ForceUnsigned flag. That bypasses the DISM-side gate and stuffs the driver into the offline store — but the WinPE kernel still runs its own integrity check at boot, and that's where the 0xc0000428 fires. In other words, /ForceUnsigned only skips the injection check, not the boot-time check.
For a definitive build-phase validation of driver signatures before a WinPE image ever boots, running Dism /Image:C:\mount /Get-DriverInfo /Driver:OemX.inf against the mounted WIM after injection will show you the signature status of every injected package — any driver showing as unsigned is your boot-crash candidate.
The real fix is upstream: get a properly signed .inf package from your storage controller vendor. If this is a dev/test scenario where signing isn't feasible, you'd need to put the WinPE image into test-signing mode via bcdedit /store <BCD_path> /set {default} testsigning on against the offline BCD — but that's a test-only path, never production.
One more thing worth checking — Microsoft's docs explicitly state that driver signature verification can fail if your technician PC (the machine running DISM) isn't on Windows 10+ or Server 2016+. What OS is your build machine running?