Usage of DISM fails inside container due to missing device driver

[JensNordenbro]

Describe the bug Running 'dism /mount-wim /wimfile:"winpe.wim" /mountdir:"c:\MOUNT_DIR" /index:1' inside a container such as mcr.microsoft.com/windows/server:ltsc2022 does not work regardless of isolation mode:

To Reproduce

Expected behavior It should just work. DISM seems to need WimMount driver and the driver is present inside the Docker image:

However I cannot find it to be installed using 'sc query type=driver'.

Configuration:

• Edition: Windows 11 container host
• Base Image being used: mcr.microsoft.com/windows/server:ltsc2022 (all of them..)
• Container engine: docker
• Container Engine version: Docker version 25.0.2, build 29cf629

Additional context We tried to mount the folder outside container and Docker volume mount it into the container however it does not work for us.

(It is ok if it only works in hyper-V mode as far as I am concerted. I can run in any mode. ) (Maybe there is some argument that can be used to share the HOST driver?)

[JensNordenbro]

Also tried DISM from ADK-installation with the same result:

[ntrappe-msft]

@JensNordenbro Hi, I'll try to repro this Issue. In the meantime, can you explain what you're trying to do? If you're trying to mount a volume with files you'll have to do that when you start up the container, not while in it.

[ntrappe-msft]

Quick note: I'll be slow to respond this week because of Build but I'll repro it as soon as I can.

[JensNordenbro]

Hi @ntrappe-msft !

I have also tried to mount the wim file outside the container (see text) and volume mount it but using this mount inside the container leads to crashes when doing further dism operations on that volume.

Inside the container, try to do something like "DISM.exe /image:"c:\mount" /Add-Driver /ForceUnsigned /DriverName:"C:\Drivers\1.inf" /DriverName:"C:\Drivers\2.inf" /DriverName:"C:\Drivers\3.inf"" or similar from https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/what-is-dism?view=windows-11

WE can survive not being able to mount a file as folder inside the container as long as the following DISM commands would work, inside the container. I do think it is a bit strange that this is not possible at least inside a Hyper-V backed container where the WM could host all drivers / services need for DISM.

[JensNordenbro]

Any chance to try this out @ntrappe-msft ?

[ntrappe-msft]

@JensNordenbro Hi, sorry for the delay. My backlog is too long right now so I'm going to triage this to another engineer.

[ntrappe-msft]

Spoke to the other engineers today. What you're trying to do is currently not supported. You're probably encountering issues due to two things: (A) the container can only see a few drivers on the host, wimmount.sys is likely one it cannot and (B) the operation you're trying to do would need to install a driver in a container which isn't permitted.

It is possible to enable this scenario but we'd need more information about your use case. Could you explain what you're trying to do with winpe.wim and the impact of this blocker on your work?

Thanks!

[madspaulsen]

Hi, my team would like to see this issue resolved also :) We're doing customized Windows images (Win10 and Server) and we're currently trying to migrate our old process into a Github workflow. We're starting from a Windows OPK (OEM Pre-installation Kit) which is pulled into the build runner where the image is mounted and we apply various customizations and finally publish a new, modified image. Or, that is what we want to do..

On our build runners (Windows in docker containers) we hit the same issue that we can't mount the Windows images (dism /mount-image /imagefile:...) and we're currently blocked by this: DismException: The image could not be mounted because the wimmount.sys driver is not installed on this machine. To fix this error, install the wimmount.sys driver.”

[JensNordenbro]

We are doing customized Windows 10 Iot Enterprise images. We want a reliable build environment, always reproducable, using containers.

I do not understand why hyper-v containers would not be able to pick this up quite easilly. In The VM you could add more drivers (command line option perhaps) and suddenly we could mount the wim inside the machine. This is all software so having to amount from the host seems wrong although tolerable.

[bewster]

I to have ran into this issue - got excited about the idea to try containerisation to maintain our Windows 10 IoT Enterprise Images.

Had hoped I could bypass the "run as admin" on dev machine requirement to mount and work with the WIM files.

[johnstep]

@JensNordenbro While mounting .wim files is not currently supported in containers, DISM can be used to apply and capture images within a container. Is that a viable workaround? For example, first apply the image to extract the files:

dism /Apply-Image /ImageFile:winpe.wim /ApplyDir:c:\MOUNT_DIR /Index:1

Next, make changes to the applied directory. Finally, capture the changes to the image:

dism /Capture-Image /ImageFile:winpe.wim /CaptureDir:c:\MOUNT_DIR /Name:winpe

See this page for more information: Capture and apply Windows, system, and recovery partitions

[JensNordenbro]

@johnstep , we will try!

[JensNordenbro]

We are still investigating. Partial success on work around but we have problems with the image produced

[johnstep]

We are still investigating. Partially success on work around but we have problems with the image produced

Thanks for the update. What kind of problems do you have with the images? Can you compare them?

[JensNordenbro]

We are off for the weekend but apparently the image just did not boot. The finding happened this thursday. Will keep you posted.

[chaitanya2ivvala]

Hello @johnstep, I am @JensNordenbro colleague. I am working with the dism stuff. We have tested winpe.wim with /Apply-image and /mount-wim commands and we installed updates and drivers on both environments.
Note The experiments were not carried out in docker. We can be able to boot the image that generated using /mount-wim but unable to boot the image which is generated using /apply-image command.

Here is the file’s structure difference between the two environments. The differences occurred when we patch updates.

[ankamat-msft]

@chaitanya2ivvala can you please share the steps you used in both working and not-working flows? Here's what I expect:

Your old flow: dism /mount-image /imagefile= /index= /mountdir= <<< perform servicing changes >>> dism /unmount-image /mountdir= /commit

Your new flow: dism /apply-image /imagefile= /index= /applydir= <<< perform servicing changes >>> dism /capture-image /imagefile= /capturedir= /name=

[chaitanya2ivvala]

@ankamat-msft Here are the working and non working flows. OS Windows 10 Dism version 10.0.19041.1 winpe path %ProgramFiles(x86)%\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\arm64 \en-us\winpe.wim

Packages in "%PACKAGE_DIR%"

ssu-19041.1704-arm64_dac34c98382f951bd654fe3affe0b3e7100b3745.msu windows10.0-kb5032189-arm64_fbd330648a90d373f3e055a02a37efbd72660775.msu

Working solution dism /mount-wim /wimfile:./winpe.wim" /mountdir:"%MOUNT_DIR%" /index:1

dism /Image:"%MOUNT_DIR%" /Add-Package /PackagePath="%PACKAGE_DIR%"

dism /unmount-wim /mountdir:"%MOUNT_DIR%" /commit

Non working solution dism /Apply-Image /ImageFile:"./winpe.wim" /ApplyDir:"%MOUNT_DIR%" /index:1

dism /Image:"%MOUNT_DIR%" /Add-Package /PackagePath="%PACKAGE_DIR%"

dism /Capture-Image /ImageFile:" winpe1.wim" /CaptureDir:"%MOUNT_DIR%" /Name:"winpe1"

[JensNordenbro]

@johnstep , @ankamat-msft - any idea about this problem?

[ankamat-msft]

Apologies for the delay. @chaitanya2ivvala can you please share DISM logs from working and not-working cases?

[ankamat-msft]

Just to clarify another thing - I attempted to reproduce this issue locally, but I could not. Essentially what I have observed is that the captured WIM file and committed WIM file have the packages installed.

[6ILY]

@chaitanya2ivvala

this was worked for me

maybe the windows adk or wdk had changed our registry image path of dism wimmount. try this.

1. In the Registry Editor (click the Start Menu icon and type regedit), go to this location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WIMMount
2. FIrst thing to do is make a backup of this entry in case anything goes wrong. Right click on WIMMount and select Export and save the backup somewhere.
3. Now click on the top level WIMMount entry (if you expand it you will see Instances and WIMMount sub-directories but we will not be using those) and in the right side panel you should see 11 or so entries.
4. Find the entry with the name "ImagePath" and make sure the Data column shows this: system32\drivers\wimmount.sys
5. If it does not say this, click on "ImagePath" and change the Value data field to system32\drivers\wimmount.sys In my WIndows 10 registry, this entry showed something different so I changed it. I confirmed this entry on my two other Windows 10 PC's.
6. Finally, check to make sure the wimmount.sys file is in this location: C:\Windows\System32\drivers\wimmount.sys

you can checkout detail in link bellow https://learn.microsoft.com/en-us/answers/questions/55836/windows-update-failed-error-0x80070003

[danielforsbergbeijer]

Hi, I run comparison between Mount and Apply method. Her is the result. It seems like the "apply" version image is corrupt after applying update. Could it be something with applying arm64 updates in a amd64 environment?

dism.log CommandsLog.txt

[chaitanya2ivvala]

@6ILY Did you manage to run dims /mount-image inside Docker with the solution you had?

[JensNordenbro]

@ankamat-msft , please see above!

[ankamat-msft]

@danielforsbergbeijer - regarding your corruption observation - if you're thinking of the image name and description - those are parameters to image capture. You can pass them at capture time to retain the correct image information. Check this out for more details: https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/dism-image-management-command-line-options-s14?view=windows-11#capture-image

Per your CommandsLog.txt, if you change your capture command you will get the desired image info result:

dism /Capture-Image /ImageFile:winpeApply.wim /CaptureDir:testApply /Name:"Microsoft Windows PE (arm64)" /Description:"Microsoft Windows PE (arm64)"

[danielforsbergbeijer]

@ankamat-msft - The corruption is not about the name and description. It is that it doesn't run and behave the same way. I have posted DISM log and command log for the replication action. The Windows PE with "Apply" doesn't boot/behave the same way as the "Mount". The content in the working folders differ after applying patches. The size of the Windows PE images are way different after the steps.

[JensNordenbro]

@ankamat-msft , your comment and fix resolves only

in @danielforsbergbeijer comment above.

[ankamat-msft]

@danielforsbergbeijer The difference in WIM size you are seeing is expected because a mounted/unmounted WIM still has "old" files even though they are dead weight. If you want to optimize the WIM size after mount/unmount, you can use /Export-Image after unmount. The size of the exported image ought to be pretty close to the size of the apply/capture image.

The difference in content that you're seeing only seems to apply to some binary-data or log files, whose contents need not be identical but they ought to be functionally equivalent.

Please confirm your observation after running /Export-Image and that should reconcile everything you're observing.

[JensNordenbro]

we are still testing but it seems promising. I will comment or close when tests are done!