Friday, July 3, 2015

Deployment error on Apply Driver Package (DISM) step

Recently deployment went wrong on a few system types, part of a lot different system types. At every deployment it went wrong on the Apply Driver Package step. At earlier deployments all went fine, but now it stops working. Both were heavy HP workstations with 16GB and 32GB memory onboard. A lot of errors in SMSTS.log and DISM.log were seen.

-Dism failed with return code -2147467259
-Failed to add driver to driver store. Code 0x80004005
-Failed to provision driver. Code 0x80004005
-Exiting with return code 0x80004005
-Failed to find a matching version

Failed to find a matching version for servicing stack: E:\Windows\WinSxS\x86_microsoft-windows-servicingstack_31bf3856ad364e35_6.1.7601.17592_none_0b0e4b4025cf4049\ [HRESULT = 0x80070490 - ERROR_NOT_FOUND]
Failed to find servicing stack directory in online store. [HRESULT = 0x80070490 - ERROR_NOT_FOUND]
Failed to open the registry root: n/a, key: Microsoft\Windows NT\CurrentVersion\ProfileList. [HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND]
Failed to query for path to user profiles directory. [HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND]
Failed to load the default user profile registry hive. [HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND]
Failed to unload offline registry: {bf1a281b-ad7b-4476-ac95-f47682990ce7}E:/Windows/System32/config/SOFTWARE, the client may still need it open. [HRESULT = 0x80070005 - E_ACCESSDENIED]
Failed to load offline store from boot directory: '\\?\E:\' and windows directory: '\\?\E:\Windows\' [HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND]
Failed to initialize store parameters with boot drive: E:\ and windows directory: E:\Windows [HRESULT = 0x80070002 - ERROR_FILE_NOT_FOUND]

After some digging I found the following solution:
Deployment failures with Precision systems
Win2008R2/Win7: STOP 0xF4 during Task Sequence / OS Deployment
Corrupt Segoe UI font and .NET framework after OSD with 2012 R2 CU1

It mentions:
The issue in this case occurs because WinPE tries to compact the offline registry and fails to commit the registry hives back to disk. This problem only happen when you deploy Windows 7 and use WinPE 5.x 32-bit to deploy the image. Resolution is to set this registry value in the boot.wim using DISM or using a 64-bit boot image.

In my case I changed to use the 64-bit boot image, because of Windows 7 x64 deployment. Otherwise you need to edit the 32-bit boot image with the regkey. Very easy solution and no errors seen anymore :-)


  1. Thx ! Stumbled on it with a HP Zbook 17 with 32 GB ..

  2. Just had this exact problem with Z220 (8GB) and Z230 (16GB). Removing the extra RAM and leaving just 4GB proved the point and now looking at adding the reg key to the x86 boot image. Thanks for this post!!

  3. Hi, I have a twist to this. I have a x64 boot wim already yet see similar DISM activity AFTER the drivers are applied in OSD Windows 7x64. The machine cannot release the OS.wim package to restart and continue the build. Precision 7710 32gb. The CBS lines in the DIM log are identical for each of the 6 hive areas and the ntuser.dat are noted as access denied.
    Software, system, security, sam, components, default and ntuser.dat.
    2016-03-28 18:01:28, Info CBS Unloading offline registry hive: {bf1a281b-ad7b-4476-ac95-f47682990ce7}D:/Windows/System32/config/SOFTWARE
    2016-03-28 18:01:28, Info

    CBS Failed to unload offline registry: {bf1a281b-ad7b-4476-ac95-f47682990ce7}D:/Windows/System32/config/SOFTWARE, the client may still need it open. [HRESULT = 0x80070005 - E_ACCESSDENIED]

    In the DISM.log from the stlled build.
    Do you think that this registry compress operation can fix this and allow the build to complete?
    Note; if I pare down the driver package to just the bare minimum the OSD finishes with many unconfigured drivers. I have not removed memory it has 2 16gb sticks and I dont have any smaller of the speed to tst the memory swap build..

    1. Did you find a solution to this?

  4. I've had the same problem as Brian. Just wondering if you solved your issue Brian?

    1. I've ended up just using DISM to add in the drivers directly to a copy of our Win7 Image and creating a duplicate task sequence just for the Dell Precision 3510's we were having this problem with due to time constraints to get this out to some of our users. Not ideal, but I now have the machine building at least.

    2. Thanks for comment and workaround on this! Still a nasty situation for sure.

  5. Bump - yep also having the same issue. Dell Optiplex 7040. SCCM 2012, Driver cab A04. 64-bit boot media. Dism failed with return code -2147467259. Anyone else found a fix?

    1. Thanks for comment. Will post on twitter again!

    2. Came across this post, while running into same issue. Moving from stand alone MDT to integrated with ConfigMgr, using CB 1606. Is there a known fix for this issue without work around. Funny thing is the package applies to one image on same hardware and fails on another image on same hardware.

    3. I'm on 1602, ADK 10 1607, with MDT 8443. That brings my version up to 10.0.14393.0 for my WinPE. According to MS Premier, this hotfix for Windows 7 deployments has to be used in the cases they have seen. Particularly with the 7040, no Root Cause, but I would say we push back on Dell at the least.

      P.S.- Don't do what I did and use an admin cmd prompt, actually open DISM. Otherwise you scratch your head for 15 min going, why but I have the latest ADK installed, is there a new one again? LOL

  6. Having the same problem with 7040's and Windows 7 x64. We found if we used the WinPE version from the 1507 ADK, instead of the newest 1607 ADK, the driver installation completes successfully. If we use the newest ADK WinPE DISM fails with the error code mentioned above....frustrating to say the least.

    1. That's very interesting to hear. Are you able to advise of the exact version numbers for the WinPE Boot images you found worked and didn't work?
      Will have to give them a go and test with all our task sequences to see if I can remove the standalone TS for just the one model. Makes it much easier to manage.

    2. See my reply from MS Premier above about the errors with 7040s

    3. I too was getting this on the HP 640 G2's and Elitedesk 800 G2's. I was using the WinPE x64 Version 10.0.14393 boot image in SCCM 1602. My temporary workaround was to revert back to our WinPE 5.0 version 6.3.9600.16384 boot image. It then installed the driver packages without errors.

  7. Same Issue here with HP 650 G2. Any Idea? I think it might not be Notebook related then. I don't want to skip in TS if Error Occurs.
    I prefer to get that done.

  8. Hi,

    Thanks for posting this. Getting a very similar error deploying win 7 x64 to lenovo T440s. Sccm platform 2012 latest build. problem is that some of the T440 build w/o problem and the others ( same bios / HW config settings etc) fail during driver applying step ( always). So any ideas would be really welcome. Thanks again.

  9. Hi Nu,
    I've had some success with changing the way I deploy the drivers to these machines as I have also had a similar issue to yours in that some machines will build fine and others of the same model and batch we ordered will crash and kill the Task Sequence at applying the drivers.

    Rather than deploying a separate Driver Package for each device type, I changed it to Auto Apply Drivers with the option to install only the best matched drivers.

    Am yet to test with the original 3510's we had this issue with, but the other machines that were randomly failing to install the drivers and killing the Task Sequence have now started working with this option enabled.


    1. Hi James,

      I've tested this on our environment and can confirm that this does resolve the problem for us. Thank you.

      I'm running the same queries that I did with the driver packages and using the best matched drivers with the labels for Windows 7 x64 and the model number I'm querying. I haven't tested all our model yet, but initial indicators are very promising.

      Thank you again.
      Kind regards

  10. None of these solutions are good. The biggest issue here is that Windows 7 has been out for a long time and supporting older and newer machines with a single boot image is becoming more difficult. The best way to go is to use an older build boot image and inject whatever is needed for new models into it.