After applying WIM image using Dism, Windows doesn't work correctly

Question

I have a freshly installed Windows 11 that isn't experiencing any errors or problems. All of my applications are working just fine.

I would like to move this installation to a different hard disk. For example, I bought a new, better SSD. I want to copy my system completely.

I found on the internet that there is a tool called DISM. It can help me with this task in three steps:

1. Create a WIM image of the original partition
2. Apply this image to the new drive
3. Create EFI partition

I've found this guide. It completely describes these steps:

What is the most efficient, native way to image a Windows partition?

So I booted to the Windows installation DVD. Pressed Shift+F10.

Captured my old system with this command:

mkdir "D:\Temp"
Dism /Capture-Image /ImageFile:"D:\Base.wim" /CaptureDir:"C:" /Name:"Windows Backup" /Compress:Fast /ScratchDir:"D:\Temp" /EA /CheckIntegrity /Verify /NoRpFix

All drive letters are correct. I checked them because they're different after the reboot.

As far as the last four options go, they don't seem to matter!

Junction points are correct anyway https://rmprepusb.blogspot.com/2017/02/if-using-sysprep-and-dismimagex-to.html

I tried capturing and applying the image several times, adding a new options, with formatting the new drive. I still had the same problem.

The next step is disconnecting the old drive. Then rebooted to the installation DVD again.

I did this partitioning on my new drive:

diskpart
lis dis
clean
convert gpt
cre par efi size=500
for fs=fat32 quick
cre par pri
for fs=ntfs quick

Applying the new image file:

mkdir "C:\Temp
Dism /Apply Image /ImageFile:"G:\Base.wim" /Index:1 /ApplyDir:"C:" /ScratchDir:"C:\Temp" /EA /CheckIntegrity /Verify /NoRpFix

Creating an EFI partition

cd /d E:
mountvol Z: /s
BcdBoot C:\Windows /s Z: /f UEFI

The new system is booting correctly, but when I try to start most of the uwp applications (Snipping Tool, Terminal, Notepad, etc), it just says "This app can't open" like this.

And the funniest thing of all is that when I try to launch this application for the second time, it actually works! Windows somehow repairs itself, even without access to the internet.

However, this doesn't work for all apps; in some cases, it will open Microsoft Store, where you'll see the Reinstall button. Alternatively, a manual click on Repair in the app's settings will also do the trick.

Also, if the original system didn't have any sfc errors, the new one has a lot of them. Here is a log of the sfc /scannow https://gist.github.com/megapro17/8e025130eb2e2d670ad79d4ab1d550af

What am I doing wrong? Why does my system have errors after the restore?

Answer 1

OP's issue may be related to /EA (capturing extended attributes), not the answer the OP linked to - that answer is correct and is how system images are captured and applied everyday by businesses, universities, power users, etc. (it's also how Windows itself is installed).

• The answer the OP linked to contains the man page link for /capture-image - was it reviewed?

If the purpose of capturing extended attributes was for user files, generally the USMT (User State Migration Tool) is used, which is what is recommended by Microsoft (extended attributes appear to only be for .cab files and certain variables when using a LTI/ZTI). AFAIK, extended attributes should not be captured when capturing/applying system image WIMs and I've never come across someone doing so on StackExchange or Spiceworks. The man page isn't clear on what use case /EA should be used, only:

Captures extended attributes. The switch must be explicitly specified to capture extended attributes. DISM will capture extended attribute bits if they are set in the components to be captured in the WIM image. If the bits are not set, DISM won't set them. Only the inbox components of CAB packages and drivers will have these extended attribute bits, not the AppX package components or Win32 application components. Extended attributes with prefix “$Kernel.” in name will be skipped because only user mode extended attributes are captured. If you use DISM in Windows 10, version 1607 to capture extended attributes and use an earlier version of DISM to apply the image, the operation will succeed but the extended attributes will not be set to the applied image.

Re-capturing without /EA should resolve the issue.