With Windows 8.1 Update Microsoft has released WIMBoot technology that is very useful on tablets with 16 or 32 GB SSD. I was wondering if WIMBoot correctly works with Windows Embedded Industry 8.1 Lockdown Features such as Unified Write Filter with HORM because WIMBoot definitely modifies file/disk subsystem. Unfortunately, I cannot find any documentation/white paper that can clarify the problem.
What is WIMBoot?
Usually manufacturer puts an additional hidden partition on a device where Windows recovery images are stored. So we have Windows files duplicated: one time in recovery images and second time in Windows image itself. The WIMBoot idea is simple: why not to use Windows files directly from recovery partition instead of file duplication and therefore save expensive SSD space especially on small SSDs?
There are many papers describe how exactly WIMBoot works (I recommend an original paper); Microsoft provides comprehensive manual to reprpoduce WIMBoot setup on your device. The only thing I would like to add the the manual is make sure you use Windows PE and Windows image (*.wim) with the same architecture as device's UEFI subsystem (x86/amd64), otherwise UEFI boot and deploy process won't work correctly.
Ok, WIMBoot somehow definitely modifies file subsystem, will it work with Industry 8.1?
To check it, I have created Industry 8.1 image on Intel NUC DC3217IYE (what's inside?) and manually updated it to 8.1 Update using the guide. I also have updated Windows PE 5.0 to 5.1 using the same guide. Then I prepared image to WIMBoot and captured it, then deployed again with WIMBoot. NUC has 32 GB SSD, and below is small performance test.
*Boot up time has been measured from power on to Windows logon screen, POST time was about 16 seconds in the both cases.
** Free space on images partition.
As you can see
Finally, what about UWF and HORM? Ok,
UWF does work correctly. File exclusions work as well.
Hibernation does work but HORM does not work; when I attempt to enable it I get an error message although HORM requirements have been met.
I'm going to retry the experiment on different hardware and software configurations because at the moment I see no reasons for such HORM behavior.
What is WIMBoot?
Usually manufacturer puts an additional hidden partition on a device where Windows recovery images are stored. So we have Windows files duplicated: one time in recovery images and second time in Windows image itself. The WIMBoot idea is simple: why not to use Windows files directly from recovery partition instead of file duplication and therefore save expensive SSD space especially on small SSDs?
There are many papers describe how exactly WIMBoot works (I recommend an original paper); Microsoft provides comprehensive manual to reprpoduce WIMBoot setup on your device. The only thing I would like to add the the manual is make sure you use Windows PE and Windows image (*.wim) with the same architecture as device's UEFI subsystem (x86/amd64), otherwise UEFI boot and deploy process won't work correctly.
Ok, WIMBoot somehow definitely modifies file subsystem, will it work with Industry 8.1?
To check it, I have created Industry 8.1 image on Intel NUC DC3217IYE (what's inside?) and manually updated it to 8.1 Update using the guide. I also have updated Windows PE 5.0 to 5.1 using the same guide. Then I prepared image to WIMBoot and captured it, then deployed again with WIMBoot. NUC has 32 GB SSD, and below is small performance test.
| Boot up time* (s) | Space used by WIM images (GB) | Space used by Windows files | |
| without WIMBoot | 20.8 | 0 (no images) | 13.2 |
| with WIMBoot | 23.8 | 4 + 0.1** | 5.4 |
** Free space on images partition.
As you can see
- WIMBoot saved 3.7 GB in this case which is pretty noticeable for 32 GB disk and very noticeable for 16 GB disk. I think this is not a limit because I didn't make component cleanup before capturing image to avoid removing any features.
- If you consider the POST time you'll see the boot time is increased significantly, but in absolute value it is still very small because we use SSD disk which is very fast. This is in conform with the fact that WIMBoot is supported only on SSD disks.
Finally, what about UWF and HORM? Ok,
UWF does work correctly. File exclusions work as well.
Hibernation does work but HORM does not work; when I attempt to enable it I get an error message although HORM requirements have been met.
I'm going to retry the experiment on different hardware and software configurations because at the moment I see no reasons for such HORM behavior.
Комментариев нет:
Отправить комментарий