Jump to content

DISM vs DISM, corrupted mount points and images

Recommended Posts

Here I will outline a situation where you can corrupt a mount point and an image by using a system with multiple versions of DISM. We already know that there is some differences between the DISM that comes with Windows and the one in the WAIK/ADK (hereafter referred to as ADK). This difference is beyond the stock DISM not supporting all command line options. It is important to note this, as we do have the technical ability to have multiple ADK versions installed or by using JFX's Get WAIK Tools to skip the large download. NOTE: This applies to all versions of Windows and WAIK/ADK versions.

This problem has 2 parts. One is recoverable, the other one is not 100%. There are 4 problems.

Problem #1: Stock DISM is the default.
DISM exists in c:\windows\system32. Even if you cd into say c:\adk10\ and that is where your DISM from ADK v10 is kept, if you just type DISM, Windows will execute the one in System32. You need to fully qualify the DISM command in order to execute the one you want.

Problem #2: You can mix DISM versions interchangeably and it doesn't care.
You have mounted an image with ADK DISM. You can then run commands using any other DISM, even if those versions do something different or do not fully support the mounted image.

Problem #3: DISM doesn't know all the mount points.
You can mount multiple images, or even nested images, but /CLEANUP-WIM shows that it does not know all the mount points.

Problem #4: Windows protects files based on filename.
You may have run into this situation before. You have a folder called Windows or Program Files somewhere that is not part of your booted OS, but Windows won't let you delete it.

Recoverable Situation
- Mount image using ADK DISM to c:\mount
- Add-driver using stock DISM.
In this scenario, stock DISM can't actually add a driver to the image, but it still tries. The DISM.exe process will start gobbling up memory. It will do this until the process crashes or your computer does. It also will lock the command prompt so that Ctrl+C will not cause the process to stop. You can kill the process and then clean-up the mount point.

Unrecoverable/Corruption Situation
- Mount image using ADK DISM to c:\mount
- Mount nested image using ADK DISM to c:\mount2
- Add-driver using stock DISM.
In this scenario, we wanted to add a driver to a nested wim. One example of a nested wim could be winre.wim. Here, the same as the last scenario happens, DISM can't add the driver and starts incrementing RAM usage. DISM process goes away (crash/kill process) then you can run /CLEANUP-WIM, but only mount2 is cleaned up. Here is what happens next:
1. c:\mount still has the mounted image in it.
2. DISM /CLEANUP-WIM doesn't see it as a valid mount point.
3. DISM /UNMOUNT /DISCARD gives you an error.
4. You can't delete everything in the folder because of Windows file protection.
5. You can't remount your image to another folder because DISM says that index is already mounted.

You can get past the issue by never using that mount folder again, but you can rename it and probably move it somewhere else. I encountered the corrupt image situation just once (enough for me to make this thread) and played it safe by deleting the .wim file and restoring a backup and THEN rename the file. Even if you delete and restore, DISM will tell you the image is already mounted. If you rename it, then it can be mounted again to a new location.

So just a word of caution for anyone using multiple ADK or DISMs on the same system to service images.

Link to comment
Share on other sites

Yep it hasn't, sorry I wasn't clear at all, :( my bad :blushing:.

The idea was more leaving the non-adk version alone, i.e. having not *any* DISM in \%Windir%\system32 and have instead Wimlib.

For "normal" operations you can use Wimlib, "installing" it and when you need to /Add-Drivers or /Add-Package you use the (appropriate) WAIK/AIK/ADK DISM from its sub-directory (I believe - but I may well be wrong - that you really need the "corresponding" WAIK/AIK/ADK DISM version to use "servicing" commands like /Add-Driver, /Enable-Feature, etc.).

In theory such capabilities can be added - I believe - as "simple" scripts on the mounted image, in practice I don't think anyone took the trouble to put them together.


Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...