You are correct in that the storage driver is the most likely culprit. It also appears you are using the older, manual option for drivers with copydrivers then dism instead of the HII options directly. In either case, the outcome is likely the same, and it comes down to the driver and the OS, and not really Provisioning or whatever else.
Windows obviously ships with a set of drivers that "just work" - basically the necessary files (.inf + supporting files) have been baked into the image. After Windows is installed and finishes the sysprep process, it looks at the available hardware and the available drivers (baked in). Drivers are scored and ranked based on the information that comes from the hardware and from the .inf file(s). The driver with the lowest rank (best match) is then "loaded" for that hardware. In many cases, there are overly generic drivers that can provide basic functionality for hardware until a better driver is installed - this is very commonly seen with video drivers - it starts as a generic vga device, then later you install the latest Nvidia driver and it figures out you actually snuck a Titan X into your machine and that driver is used instead. This usually doesn't lead to serious problems, like BSOD, but just reduced or missing functionality.
However, there are a couple cases that will lead to a BSOD. One is if the driver is just plain bad or wrong - Windows has used the .inf and decided that DriverA is the best match, so loads it up. However, that driver is bad or wrong and so then attempts to interact with the system or hardware in an unsafe, illegal or invalid way, which can lead to a BSOD. This can happen really anytime, depending on what you are doing. You might not see the BSOD until a certain action is attempted or something similar. The second case is for specific device classes that are considered "boot critical" - these are the devices that Windows REALLY REALLY NEEDS to work right in order to boot - for example storage devices so it can read the necessary files. When these drivers are wrong, you will normally see a BSOD at boot time, often leading to a boot loop (system boots, crashes, set to reboot on crash, reboots, crashes, etc.). These crashes should be accompanied with a STOP code that can sometimes be used to identify the device that is having problems. The stop code 0x07b for example generally means the storage device or controller has a problem.
This is a lot of information that doesn't directly help, and you might already know, but hopefully it helps you or someone else. In the end, the problem is likely because of a driver loaded into Windows, either already in the image or being added by dism during the Provisioning task. LANDESK/Ivanti can't FORCE Windows to use a specific driver, we can just make them available for Windows to rank and then load what it considers the best driver. In your case, it seems Windows has decided that a particular driver is the best match, but it isn't a good match at all. This is based on the rank of the driver(s) - so DriverA might be wrong, but scores a better rank than DriverB, which is the correct driver. Here is what I'd recommend:
- Make sure the image that you are deploying has been sysprep'ed - this clears the hardware information so that Windows will find new, matching drivers for the hardware when it boots up after imaging. Otherwise old drivers may not be replaced leading to a BSOD
- Remove the step(s) that copies new drivers and runs DISM and deploy the image. If the BSOD still exists, then the problematic driver is already in the image. If the problem goes away then the problem driver is being copied. Also note that the problem might remain because now it can't find a driver, vs before it found a bad driver.
- You can boot the system to Windows PE using a PXE rep or other options to allow you to look at the system better and make some changes that might help:
- Set the system to not reboot on crash, which will allow you to validate the STOP code and if it changes based on what drivers are available
- Use DISM to install, remove and look at drivers in the Windows image
- Review logs about driver installation - specifically the SetupAPI log, which includes information about driver rank and selection
- Manually add and remove specific drivers for testing
- Run other diagnostics tools
You can find some more information here:
- How Windows Ranks Drivers (docs.microsoft.com)
- How to configure system failure and recovery options in Windows (support.microsoft.com)
Hopefully this helps. If you are still having problems, you can call Ivanti Support, and we can see if there is something we can find or help with. Even though we can't directly change this part (that's on the driver writers and Windows) - we want to help out our customers and have worked through this a few times now.
We've switched to TII with Dell's new models this year due to the issues you describe, and have had no issues since doing so, insofar as drivers are concerned...