New
#410
Sorry, I did not see this until today.
Yes, use Diskpart - list volume is my standard also. MBR disks often get the drive letters reassigned in Windows RE (C: becomes D:).
I had the /ScratchDir option as default, because I always get a warning that the results may not work. It's simple enough to do and the DISM processing takes quite a while, so I always felt it would be time wasted if DISM failed and the user might immediately wonder if they should have done the /ScratchDir option. Usually I forget until I see the warning, then I use CTRL+C to cancel, create the ScratchDir and start over. The Temp directory is by default on the X: drive (X: = RAM Disk and limited in size, which is why the warning is displayed). So it seems easier to make the Scratch directory, or else change the TEMP Environment variable to use the disk instead:orCode:set TEMP=C:\TEMPI have found that if the Windows component store is not corrupt and sfc /scannow works the offline DISM /RestoreHealth should complete 100%.Code:set TEMP = D:\TEMP
However, I have also had it happen, with Windows 10 version 1703, that the offline DISM repair did not fix an issue, but the /Online DISM did fix it. Even though /Online complained about the missing FlightSigning package, CBS.log still showed that DISM fixed the other corrupted file that the offline scan could not repair. Maybe it actually pulled it from Windows Update? Hard to know.
EDIT: Sorry I did not see your post about it not being applied to the online Windows. What does that mean? Others have said this too. You are repairing your only copy of Windows with DISM, whether Windows is running or not at that moment. In most cases, there is nothing to fix anyway and sfc /scannow works.
Obviously, offline repair does not insert the missing FlightSigning package to the WIM file, but users are upset that DISM fails with an error that suggests that it did not find the Source files, even if it uses them to fix other errors. Users often do not look in the right log to find what actually happened, so providing a means to see the 100% complete with no error may satisfy them. The concern is usually misplaced because Windows is fine. Only by reading the CBS.log will they see what happened. Running the DISM repair offline may satisfy that concern for those who will not read the log anyway.
A relevant question would be, "What makes our running, or "Online" Windows look for the FlightSigning package during DISM repair, while repairing the same copy of Windows while it is not running does not look for that package?"
Last edited by DonCuthbert; 23 Apr 2017 at 00:15.