The inner workings of a media creation tool

I thought to myself “I wonder how many people would download and run a random executable” — implicitly trusting what it does. Of course I already knew the answer — I guess my blog is considered “trustworthy enough” to take the chance. (If you don’t know what I’m talking about, see my previous blog post.)

But at the very least, there are those who are curious about what it is doing, so let me explain. First, as I noted in my original blog about ARM64 ISOs, the “official” Media Creation Tool for Windows 11 downloads a CAB file from https://go.microsoft.com/fwlink/?LinkId=2156292 that it uses to determine what’s available; the Windows 10 version of that tool downloads a similar manifest, but from https://go.microsoft.com/fwlink/?LinkId=841361. Both have exactly the same format, with entries like these:

So, by downloading both of these and merging them together, the result is 5174 entries (at present). These are all for the 22H2 releases of Windows 10 and Windows 11 (looks like Microsoft only allows downloads of the latest release of each, so these will likely change each time there’s a new release).

The file name in each of these entries represents the OS version and release, e.g. 19045 = Windows 10 22H2. Since that’s not explicitly called out in the file, I added a new property to each entry to specify the “friendly” OS version. Then it’s just a summarization process:

• Based on the OS version, show a list of architectures available. For Windows 11, that’s just x64 and ARM64, while Windows 10 still has x86.
• Based on the OS version and architecture chosen, show a list of available languages.
• Based on the OS version, architecture, and language, show a list of available editions. (As a comment on the original blog post pointed out, these aren’t actually the editions of the images in the ESD file, but rather the editions of Windows that could use one of the images in the ESD file to perform an upgrade. So if you choose an edition that no longer exists, e.g. Cloud or Ultimate, you’ll get an error generating the ISO. That’s more of an edge case, so it’s not a big concern at the moment.)

Once you’ve finally gotten it down to a specific entry, then we just need to download the needed ESD file, extract Windows PE/setup files as well as the selected edition (finding an image that matches the selected edition — if it exists), and then capture the ISO file.

So how does that work behind the scenes? It’s pretty much all PowerShell, with a simple WPF wrapper that fires off the needed PowerShell commands. You could do the equivalent using just the PowerShell module. First, you can load and initialize the module, then use the Get-MediaToolList cmdlet to sift through the available files:

Once you’ve found what you want, you can generate the ISO:

It will download the specified ESD file (if it doesn’t already exist) using BITS, then extract the needed images using Expand-WindowsImage and Export-WindowsImage, and finally capture the ISO using the OSCDIMG.EXE utility from the ADK.

There’s one other slight complication: To find the edition that you specified, we need to enumerate the available images in the WIM file to see the “EditionID” or “FLAGS” value. Sadly, the “Get-WindowsImage” cmdlet doesn’t return those values; it just returns the display name of the image. To solve that problem, I borrowed a PowerShell cmdlet that uses the WIMGAPI API to get more details via the “Get-WimFileImagesInfo” cmdlet.

There are a couple of options available in the Get-MediaToolISO cmdlet too, which you can see in the UI:

Specifying “Do not require pressing a key” changes the ISO from “efisys.bin” boot sector to “efisys_noprompt.bin” (you can read up on those separately); specifying “Re-compress the OS image using standard compression” exports the OS image but changes it from solid/recovery compression to maximum compression so that the WIM can be used with tools that don’t know how to handle solid/recovery compression. (Don’t check that box if you want to use a USB key, since the resulting WIM will be bigger; since FAT32 only supports a 4GB maximum file size, you’ll find that the file will no longer fit and would need to be split.)

The app itself is then just PowerShell “glue.” It needs to load the module, initialize it by calling “Initialize-MediaTool,” populate the drop-downs with “Get-MediaToolList”, and finally generate the ISO with “Get-MediaToolISO”. It also needs to capture the output and progress from the PowerShell commands, which is displays back in the UI. Fairly straight-forward overall, at least if you regularly do WPF and PowerShell SDK stuff — I had to do way too many Bing searches to remember how to do this stuff, but it’s at least common enough that the answers can be found.

Want to check out the source yourself? If you promise to not make fun of my coding (I was going for “speed,” not “prettiness”), you can find it on GitHub at https://github.com/mtniehaus/MediaTool/.