Boot XP Embedded in Under 10 Seconds

2. Boot XP Embedded in Under 10 Seconds Alexander Wechsler eMVP Microsoft Regional Director, GermanyWechsler Consulting GmbH & CO. KG awechsler@wechsler-consulting.de Blog: http://spaces.msn.com/weconlog

3. Booting a Virtual Machine in HORM Mode

4. What is Going on Here? • System boots from the hibernation file into a predefined system state • Drivers, services and programs are immediately up and running • System boots into this state any time, regardless of the shutdown method you choose.(For example, restart, hibernate, shut down or, even more drastically, cutting power.) • File system will not get corrupted -> it is protected

5. Hiberfile Hibernate Once Resume Many Processor EWF Overlay RAM (re-hydrated) System Memory EWF Protected OS partition Windows XP embedded HORM device

6. Why Can’t Microsoft Windows XP Do This? • HORM requires the heavy use of Windows XP Embedded EEFs (Embedded Enabling Features), not available for Windows XP • Some limitations to system functionality to achieve data consistency: • Windows XP invalidates the hibernation file after every reboot • Windows XP requires new creation of the file when entering hibernation mode

7. Hiberfile Hiberfile Windows XP Professional Hibernation Processor RAM (re-hydrated) System Memory Windows XP embedded HORM device Unprotected OS partition

8. File Headers From Valid and Invalid Windows XP Hibernation Files Shown in Hex-Editor

9. HORM Usage Scenarios • Ideal for fixed function devices such as: • Information kiosks • Ticket machines • Cash registers • Automation controllers • Especially when: • No data is stored locally • Systems act as service brokers or functional nodes

10. HORM Overview Hibernate Once Resume Many, benefits: • Uses an on-time, create-hibernation file to always boot from it fast and reliably • Shortens boot time significantly • User can modify and recreate this file any time • Protected system partition makes the system robust against e.g. power outage and viruses • Manage the system in well-defined intervals having complete control

11. HORM Overview Hibernate Once Resume Many, drawbacks: • Persisting information is getting harder • Deployment and maintenance are more difficult • Not all HW and SW supports HORM • Mixed configurations having protected and unprotected volumes are challenging. Data consistency is an always-present topic. • Network shares must also be treated specially after waking the system up

12. HORM System Design

13. What Do I Need to Do HORM? Ingredients: • Windows XP Embedded runtime image for your target device • Hibernation support (power management) • Enhanced Write Filter in RAM or RAM/Reg mode • An extra file, resmany.dat • Optional things like: • Enhanced Write Filter (EWF) Manager and API • Windows XP Embedded power management tools and API • Task Scheduler • HORM Manager (Demo application)

14. Enhanced Write Filter 1/2 EWF Architecture: • Filter driver • EWF NTLDR • EWF Manager

15. EWF Info in Registry EWF partition info Enhanced Write Filter 2/2 • EWF modes • Disk overlay • RAM overlay • RAM/Reg overlay RAM Disk Protected partition Overlay partition

16. Creating a HORM Image 1/3 Standard image • Configure a standard Windows XP Embedded target image as usual • Using Target Analyzer to detect hardware components • Add required functionality and custom applications/drivers • Add system cloning component (turn off auto-reseal)

17. Creating a HORM Image 2/3 • Enhanced Write Filter RAM/Reg • Add enhanced Write Filter components, configure RAM or RAM/Reg mode • Add EWF NT Loader • Add RAM/Reg registry keys • Disable FBAReg.dll Resource in the EWF component • HORM • Add resmany.dat • Enable hibernation • Add Windows XP Embedded power management

18. Creating a HORM Image 3/3 Build and deploy • Run FBA • Customize image • Reseal the system HORM field configuration • Turn off EWF • Add Resmany.dat • Turn on EWF • Create hibernation file • Ready to go

19. HORM ConfigurationThe necessary steps in Target Designer to enable HORM

20. Application Design for HORM

21. Making Things Harder • Having only protected volumes is the ideal world • Reality check! • Mixed protected and unprotected volume configurations are quite common • Complexity to regain data consistency rises • Effects OS as well as running applications • But -> most situations can be handled!

22. Where is My Data? 1/3 • Five ways for applications to persist data • RAM overlay – volatile • Data lost after reboot • Hibernation file – persistent • Requires recreation of hibernation file and reboot • Data is reloaded after reboot • Data loss is possible (not fail-safe) • Protected disk - persistent • Requires commit of RAM overlay and reboot • After commit new data is part of the protected volume • Data loss is possible (not fail-safe)

23. Where is My Data? 2/3 • Unprotected disk - persistent • No reboot to persist data • Risk of data loss is minimized • Network share - persistent • No reboot to persist data • Risk of data loss is minimized

24. Where is My Data? 3/3 Application Network Share direct write volatile write direct write Intermediate write Hiberfile Unprotected Partition RAM Overlay partition Disk Protected Partition RAM Persisted at checkpointby application or OS

25. Application Design for HORM 1/2 Mixed configurations of protected and unprotected partitions • Requires data management strategies to achieve data consistency • Mount and unmount drives to keep unprotected data out of the hibernation file (see MSDN article: Dismounting Volumes in a Hibernate Once/Resume Many Configuration) • Start and Stop applications and services before hibernating • Restart applications and services after waking up • Applications (especially custom shells) ideally should be HORM enabled using the Windows XP Embedded PM and EWF APIs • Control HORM and manage Volumes • Control EWF from the application

26. Application Design for HORM 2/2 Use of Network shares • Applications should use UNC names not drive letters to connect • Avoids security and reconnection problems • Especially when running headless and as services (no common desktop or drive letters) • Defensive programming rules should be applied • Retries if first connection attempts fail • Offline capabilities often desirable (smart clients!)

27. EWF API • Disabling/enabling EWF for a protected volume • Restoring or discarding an overlay level • Creating a checkpoint by adding an overlay level • Committing the current overlay • Persisting data through a reboot API files can be found at: [Program Files]\ Embedded\Installer\disk3\ewfapi on your development system

28. Windows XP Embedded Power Management API is located in the VALUEADD\MSFT\XPEPM folder of disk 1 of Windows Embedded Studio The files xpepm.dll, xpepm.lib and xpepm.h are required. Console power management application gives access via command line Tip: • XPE_Hibernate does not lock the desktop after waking up • Normal hibernation via Shut Down -> Hibernate does!

29. Data Inconsistencies in Mixed ConfigurationsUsage of EWF API and Windows XP Embedded Power Management API to Achieve Data Consistency

30. Maintenance and Deployment

31. HORM Change Management 1/3 Challenges • Fighting EWF protection for maintenance and installations • OS as well as application updates are need to be considered • Again our different ways to persist data in the system • On disk (persistent) • In hibernation file (persistent) • In RAM overlay (volatile) • -> Need to develop a fitting strategy

32. HORM Change Management 2/3 Best practices • Use a maintenance window to apply updates • Integration into enterprise change management systems is desirable • SMS Server • WSUS (OS patches only!) • Third-party solutions, such as Tivoli (client componentization issues) • Virus and malware scanners (client componentization issues) • Embedded and customized solutions • Automated field deployment using scripts and RUN registry keys. (Do not forget to seal your devices!) • Device Update Agent • Roll your own update solution • Plan for high availability and robustness

33. HORM Change Management 3/3 All approaches adhere to two basic scenarios • Turn off HORM/EWF and update (fail-safe) • Updates are applied and persisted directly to disk • Update live and commit (dangerous) • Updates are applied in memory overlay and then persisted to disk • Danger of overflowing the RAM overlay! Things to keep in mind • Recreate the hibernation file after successful update to re-enable HORM • Applying XP Pro patches will grow Your image (CF card - size!) • -> Having an OS deployment strategy at hand is very useful

34. OS Deployment • Basically all Windows XP Embedded deployment options are possible • Cloning / Windows PE Deployment (CD/DVD)-> Think about sealing issues! Seal with EWF turned off! • PXE / RIS • Challenges: • Manual or automated field configuration of EWF / HORM required • Console applications for EWF and Windows XP Embedded PM can be used in batch files • Use “Run”-registry keys to start scripts

35. TroubleshootingHORM

36. Checklist • Enable hibernation support in the Windows XP Embedded image • EWF must be active • Hiberfile must be created once with EWF turned off! • Resmany.dat needs to be existing • Be aware that committing EWF turns off HORM! (Hiberfile must be recreated)

37. Avoiding Common Pitfalls • HORM is not working on diskless systems • El Torito CD boot • Network RAM Boot • Reason: The hiberfile is a dedicated system resource that cannot be shared between different systems • Changing HW configuration • Take care with plugging in/out peripherals, especially when using custom shells • Starting applications • Run entries work most reliably if persisted into the protected volume

38. Tuning Boot Time • Use fast boot devices such as HD or flash disk. Normal CF cards are slow. • Limit the hiberfile by using just the system memory required. Reading a 2GB hiberfile will never be fast! • Use the BootVis utility to profile and optimize your Windows XP Embedded system for fast boot in factory (before sealing the image) • Be aware that network timeouts of not connected NICs can slow boot time significantly. (Disable them if not used.)

39. Known Issues Overflow of RAM overlay message: Windows: Delayed Write Failed. Windows was unable to save all data for the file. The data has been lost. This error may be caused by a failure of your computer hardware or network connection. Counter measures: In the Enhanced Write Filter component in your configuration, on the EWF Configuration Setting tab, click the Use Less Overlay Space and less Writes check box Rule out any unnecessary disk I/O (especially write requests). NTFS is a good candidate! Make sure that the disk defragmenting tool is not running in the background

40. Summary • HORM is able to add significant value to a Windows XP Embedded system • Fast boot times • Robustness • High availability • It does not come for free • Higher complexity keeping data consistent • Higher deployment and change management efforts • Application design considerations using mixed configurations But, you can make it if you try! 

42. Resources Stop by the MED Content Publishing Team Station in the Microsoft Pavilion or visit the MED Content Publishing Team Wiki site:http://msdn.microsoft.com/mobility/wiki Need developer resources on this subject? awechsler@wechsler-consulting.de Alexander Wechsler

43. © 2006 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.