none
Error 0x8000FFFF when applying a customized answer_file.xml to WIM file RRS feed

  • Question

  • In our Windows 7 Embedded development environment were are attempting to generate a customized WIM file. We start by generating a customized answer_file.xml in the Image Configuration Editor. Using a customize install.wim file as a template, we execute the next two commands to apply our answer_file.xml. Would this step be similar to running Windows Update?

    There's a "dism mount" command to executed before the two commands below to prepare the install.wim and the "mount" folder (being the folder that contains the product).

    > dism /image:mount /apply-unattend:answer_file.xml
    > imagex.exe /capture mount "custom.wim" "CUSTOM Windows"

    It's during the dism step that we receive the following error. Which informs us to check the dism.log file. This log contains thousands of lines of messages. We are unable to figure out where the real error lies.

    Error 0x8000FFFF

    But, when re-executing the dism command right after it fails we get a successful completion of the process. Next we execute the imagex.exe command to generate the WIM file.

    We could use some insight as to why our first attempt at applying the answer_file.xml customization's fail but works by re-executing the command.


    • Edited by lintek Thursday, March 23, 2017 1:20 AM
    Wednesday, March 22, 2017 10:51 PM

Answers

  • I've made a discovery that seems to be the solution. Given the fact that Microsoft has changed their methodology in the way they delivery security updates within their "cumulative" rollup packages. It seems our development team has to rethink our current method in how to apply the updates in our process to create the WIM file when dism is executed.

    dism /image:mount /apply-unattend:AutoUnattend.xml

    But when only the "latest" "security monthly quality rollup" (KB4019264), is included (while excluding all the previous rollups) in the DSSP1 folder, the creation of the WIM works as with the installation of the OS to the CF Card. The final test was booting up the OS on the CF Card, which was successful. I consider this a closed issue for now.

    • Marked as answer by lintek Thursday, June 8, 2017 2:52 PM
    Thursday, June 8, 2017 2:52 PM

All replies

  • This is the command we use to mount the install.wim file.

    dism /mount-wim /wimfile:install.wim /index:1 /mountdir:mount

    More information I captured from the C:\windows\logs\dism\dism.log

    C:\Windows\Logs\DISM>grep -i E_ACCESSDENIED dism.log
    2017-03-24 10:46:56, Info                  CBS    Failed to unload offline registry: {bf1a281b-ad7b-4476-ac95-f47682990ce7}C:/ccviews/zKD_W1.3.2.2/COTS/WES7/Con
    figuration Set/mount/Windows/System32/config/SOFTWARE, the client may still need it open. [HRESULT = 0x80070005 - E_ACCESSDENIED]
    2017-03-24 10:46:56, Info                  CBS    Failed to unload offline registry: {bf1a281b-ad7b-4476-ac95-f47682990ce7}C:/ccviews/zKD_W1.3.2.2/COTS/WES7/Con
    figuration Set/mount/Windows/System32/config/SYSTEM, the client may still need it open. [HRESULT = 0x80070005 - E_ACCESSDENIED]
    2017-03-24 10:46:56, Info                  CBS    Failed to unload offline registry: {bf1a281b-ad7b-4476-ac95-f47682990ce7}C:/ccviews/zKD_W1.3.2.2/COTS/WES7/Con
    figuration Set/mount/Windows/System32/config/SECURITY, the client may still need it open. [HRESULT = 0x80070005 - E_ACCESSDENIED]
    2017-03-24 10:46:56, Info                  CBS    Failed to unload offline registry: {bf1a281b-ad7b-4476-ac95-f47682990ce7}C:/ccviews/zKD_W1.3.2.2/COTS/WES7/Con
    figuration Set/mount/Windows/System32/config/SAM, the client may still need it open. [HRESULT = 0x80070005 - E_ACCESSDENIED]
    2017-03-24 10:46:56, Info                  CBS    Failed to unload offline registry: {bf1a281b-ad7b-4476-ac95-f47682990ce7}C:/ccviews/zKD_W1.3.2.2/COTS/WES7/Con
    figuration Set/mount/Windows/System32/config/COMPONENTS, the client may still need it open. [HRESULT = 0x80070005 - E_ACCESSDENIED]
    2017-03-24 10:46:56, Info                  CBS    Failed to unload offline registry: {bf1a281b-ad7b-4476-ac95-f47682990ce7}C:/ccviews/zKD_W1.3.2.2/COTS/WES7/Con
    figuration Set/mount/Windows/System32/config/DEFAULT, the client may still need it open. [HRESULT = 0x80070005 - E_ACCESSDENIED]
    2017-03-24 10:46:56, Info                  CBS    Failed to unload offline registry: {bf1a281b-ad7b-4476-ac95-f47682990ce7}C:/ccviews/zKD_W1.3.2.2/COTS/WES7/Con
    figuration Set/mount/Users/default/ntuser.dat, the client may still need it open. [HRESULT = 0x80070005 - E_ACCESSDENIED]

    What is this message (E_ACCESSDENIED) telling me to correct? 

    • Edited by lintek Friday, March 24, 2017 2:52 PM
    Thursday, March 23, 2017 3:43 PM
  • I've made a discovery that seems to be the solution. Given the fact that Microsoft has changed their methodology in the way they delivery security updates within their "cumulative" rollup packages. It seems our development team has to rethink our current method in how to apply the updates in our process to create the WIM file when dism is executed.

    dism /image:mount /apply-unattend:AutoUnattend.xml

    But when only the "latest" "security monthly quality rollup" (KB4019264), is included (while excluding all the previous rollups) in the DSSP1 folder, the creation of the WIM works as with the installation of the OS to the CF Card. The final test was booting up the OS on the CF Card, which was successful. I consider this a closed issue for now.

    • Marked as answer by lintek Thursday, June 8, 2017 2:52 PM
    Thursday, June 8, 2017 2:52 PM