Quality Assurance Checklist - Microsoft Windows Embedded Standard 2009 Developer Resource Kit Componentizing Windows...

This chapter is divided into the following QA task categories:
Development environment audit.
To help you maintain an appropriate development environment for developing your XPe image.
Functional audit.
To ensure that your XPe image contains all the functionality it needs to fulfill the needs of your limited functionality runtime.
Serviceability audit.
To ensure that your image is serviceable after it has been deployed to the end user. This includes having in place a fully-tested process for updating the image or applying hotfixes.
Security audit.
To produce a secure solution, based on considerations such as the environment in which your device will be deployed.
Reliability audit.
To eliminate or reduce potential points of hardware or software failure. This includes but is not limited to prevention or elimination of software bugs.
Image footprint reduction.
To offer guidelines regarding building configuration files and satisfying dependencies, in order to produce the smallest footprint possible.
The steps above can offer a reduction in development time thereby resulting in reduced development cost and quicker production deployment.
Introduction to the Windows Embedded Standard 2009 Component Manifest
This chapter makes reference to a companion Excel spreadsheet, named
"Windows Embedded Standard 2009 Components.xls".
This spreadsheet contains a list of all feature-type components found in Windows Embedded Standard 2009, along with columns that you can sort in order to group components by various categories.
The spreadsheet enables you to improve your component choice decisions.
For example, if you want to group all the Debugging/Development type components together, in order to make it easier to pick and choose components that are useful during image development, follow these steps:
Using Excel, open " Windows Embedded Standard 2009 Components.xls"
Choose Data->Sort
In the Sort by field within the Sort dialog, choose Debug / Development tools, and turn on the button to indicate your data range has a Header row.
Click OK to perform the Sort operation
Note that all the Debug / Development Tools related items will be grouped together at the beginning of the spread sheet. Pick and choose those components that you wish to use for development.
Here is a summary description of the columns contained within " Windows Embedded Standard 2009 Components.xls":
COLUMN NAME
|
DESCRIPTION
|
Component Name
|
This is the formal component name as observed in Target Designer.
|
Purpose
|
A short description of the component name.
|
Unique customizable component settings
|
If the component can be customized using Target Designer, this column contains a brief description of the customization options. Sort by this column if you wish to identify and review all the customizable components in your Target Design.
|
Macro Component
|
An “X” indicates the component is a Macro component, i.e. a component that contains only component dependencies. Macro components are a convenient means of specifying an arbitrary group of components to be included in your build.
|
Networking
|
An “X” indicates the component is a networking related component. Sort by this column to group together networking components. This can be useful when performing a security audit.
Additional MSDN resources:
Comparing TCP and SMB connections for Windows XP Embedded-based devices
Working with Netsh in Windows XP Embedded
|
Graphics and Multimedia
|
An “X” indicates the component is related to Graphics and Multimedia.
|
User Interface (UI)
|
An “X” indicates the component is related to the user interface. Sort by this column to help you review the user interface options available.
|
Printing / Imaging
|
An “X” indicates the component is related to printing or imaging. Sort by this column to help you review printing related components.
|
Security
|
An “X” indicates the component is related to security. The component may relate to “surface attack area”, i.e. potential attack vulnerabilities. Most commonly, network related components fall under this category. The component may relate to security enhancement, such as the Windows Firewall. Sort by this column to review all the security related components.
|
Windows Platform (API)
|
An “X” indicates the component is related to the Windows Platform Application Programmer Interface (API). Sort by this column to help identify components related to the Platform API. You can choose exactly those components that you need, in order to fulfill the requirements of your specific Standard 2009 runtime application.
|
Storage
|
An “X” indicates the component is related to storage technology. Note that Windows XP Embedded target devices are typically configured to use one of the following storage technologies as the boot device: Conventional hard disk, flash IDE storage devices, CD-ROM (via El Torito CD), and Remote Boot. Remote Boot is a means of booting a diskless system, as it uses a portion of system memory to serve as the system boot storage device.
|
Language
|
An “X” indicates the component is related to language, internationalization or MUI functionality. Note that you also may need to install corresponding MUI packs in order to achieve full functionality of these components. Sort by this column in order to review and choose Language related components.
Additional MSDN resources:
Windows XP Embedded Language Support Overview
Language Support
Adding Multiple Language Support in a Windows XP Embedded Image
|
App Compatibility
|
An “X” indicates the component is related to Application Compatibility. Application Compatibility refers to the ability of the operating system to remain compatible with legacy applications. You may need to include certain Application Compatibility components if you intend to use older applications that were originally developed for use in earlier operating system versions.
|
Embedded Enabling (EEF)
|
An “X” indicates the component is a feature that is unique to Standard 2009, i.e. not available in conventional Windows XP Professional. Sort by this column to review these components to determine which ones are useful to you.
|
WMI / Instrumentation
|
An “X” indicates the component is related to Windows Management Instrumentation, or other instrumentation such as Event Tracing, system monitoring tools, etc.
|
Debug / Development Tools
|
An “X” indicates the component is related to debugging and/or development. Sort by this column to review and choose all the development and debugging tool features. When it is time to produce a production image, you can review these components to identify which ones should not be included for the production image.
|
Service (executable name)
|
If the component is part of a Windows Service, this column contains the name of the service, and, in parentheses, the corresponding binary DLL or EXE of the service. Sort by this column to pick and choose Windows Services. After you deploy your image, you can run the Services control panel applet (services.msc) to confirm that the services are installed, and you can inspect the status of each service.
|
Development Environment Audit Objective
To help you configure and maintain an appropriate development environment for developing your XPe image.
Audit checklist
|
Item
|
|
For suggestions regarding the configuration of your development system, review these on-line resources:
Installing Windows XP Embedded with Service Pack 2
Release Notes for Windows XP Embedded Service Pack 2 Feature Pack 2007
Development Process
Building and deploying XP Embedded Images
Configuring a Windows XP Embedded Thin Client
Dual-Booting Tips for XP Embedded
Building a Diskless Automation Controller Using Windows XP Embedded
Rapid Prototyping with Windows XP Embedded
Developing an Embedded Run-Time Image from Start to Finish
Tutorial: Building and Deploying a Run-Time Image
|
|
Establish and deploy a regiment of regularly backing up your Target Designer development system, in particular the following:
Component database or databases (your repository folders and *.MDF, *.LDF)
Working with SQL Server to Manage Your Windows Embedded Standard Database
Configuration files (.SLX)
Custom components (.SLD) that you created and manage.
|
|
If you are maintaining and servicing XPe images that were developed using SP1 or SP2, do not install SP3 on top of your SP1 or SP2 database; instead retain the older databases in order to continue servicing older deployed images.
For more information:
Installing Windows XP Embedded with Service Pack 2
|
|
If your development systems are part of a corporate network, ensure that your SQL Server database and your folders are adequately protected, by configuring them with restricted permissions.
|
|
If you do not intend to share your Component Database for use with other developers in your company who use Target Designer, configure SQL Server so that it does not accept network clients, using the svrnetcn.exe tool to disable all network services.
|
|
Become familiar with third party tools to facilitate Windows XP Embedded development:
Useful Tools for Creating Components and Troubleshooting Configurations
Third-Party Tools for Windows XP Embedded
|
|
Review the Component Help system:
Finding Information in Help
| Functional Audit Objective
Ensure that your XPe image contains all the functionality it needs to fulfill the needs of your limited functionality runtime.
Audit checklist
|
Item
|
|
If using Minlogon instead of Winlogon, review these resources:
Introduction to Minlogon
|
|
Review these links to establish their applicability to your project. Then use the applicable ideas.
Building Your First Windows Embedded Standard Test Image
Development Process
Design a Run-time Image
Building and deploying XP Embedded Images
Configuring a Windows XP Embedded Thin Client
Dual-Booting Tips for XP Embedded
Building a Diskless Automation Controller Using Windows XP Embedded
Rapid Prototyping with Windows XP Embedded (using Virtual PC)
Developing an Embedded Run-Time Image from Start to Finish
Tutorial: Building and Deploying a Run-Time Image
Finding information in Help
|
|
Review and choose Embedded Enabling Features (EEFs) – these are components that are only available in Windows XP Embedded.
Embedded Enabling Features
Chapter 4. Embedded Enabling Features
|
|
If considering using the Enhanced Write Filter (EWF) component, review the EWF section in Chapter 4. Embedded Enabling Features, as well as these on-line MSDN resources:
Programmatically Dismounting Volumes
Dismounting Volumes in a Hibernate Once/Resume Many Configuration
Controlling EWF by Using the EWF APIs
Using CompactFlash (CF) with the Enhanced Write Filter (EWF)
Configuring the CompactFlash Device
Using the Enhanced Write Filter (EWF) in Windows XP Embedded
|
|
Configuring the User Interface (shell)
Review this on-line MSDN resource regarding user interface shell options:
Different Shells for Different Users
|
|
Within Excel, use the Data->Sort feature to sort the spreadsheet by the column titled “Unique customizable component settings”. For each component that is in your build that contains customizable settings, review each setting to ensure that it is correctly set for your production image.
|
|
Finish developing all custom components that you need.
Basic Componentization
Componentizing Applications (Standard 2009) (formerly published as a blog at: Componentizing Apps (Winamp project))
Creating custom components for Windows XP Embedded
Author Components and Customize Shells
Tutorial: Creating a Custom Component
How to Componentize an Application
Component Designer: Pulling It All Together
|
|
Finish developing all custom driver components that you need.
Review this content: Creating Driver Components
|
|
If you have further problems componentizing a third party driver or application, particularly if the driver or application is being installed via a third party installer package, follow these steps.
Use an installation monitoring tool found here Third party installation monitoring tools to determine what binaries and what registry entries have been added to your image by the driver installer program. Run the driver installer on an XP Professional SP2 system (not your XPe SP2 system) via while running the installation monitoring tool which monitors all files and registry keys added to the image.
Analyze each file that is being installed by the installer, using the DEPENDS.EXE tool (available in the Windows SDK or a version can be found here: http://www.dependencywalker.com/ - this site is also not formally endorsed by Microsoft). Verify that the binary dependencies required by the driver binaries are included in your XPe image.
If further analysis is needed, you can monitor file access using FILEMON and monitor registry access using REGMON. These third party tools are available at this site:
Windows Sysinternals
|
|
Ensure that the status of each of your custom component(s) are set to “Released”. Otherwise your components will not be properly versioned and you will get "unreleased" warnings when building.
|
|
Ensure that any custom components are backed up (along with your component database and repositories).
|
Serviceability Audit Objective
Ensure that your image is serviceable after it has been deployed to the end user. This includes having in place a fully-tested process for updating the image or applying hotfixes.
Background
You, as the OEM, must maintain 100% “ownership” of your deployed Windows Embedded Standard 2009 (Standard 2009) image. Every Standard 2009 image is a “sub-platform” of Windows XP Pro. As such, it has been custom tailored to fulfill exactly one target device scenario. In contrast, Windows XP Professional serves as an operating system platform designed to accommodate any third party application that adheres to MSDN XP Platform development guidelines.
Please review Chapter 6. Servicing for details.
Licensing considerations
Windows XPe cannot be used on a PC as a Windows XP Professional replacement. To be clearer, Standard 2009 can only be licensed to run line-of-business applications on fixed function devices. You can have an unlimited number of applications running locally, if the line-of-business application requires them locally. For example, a device that has a retail management application may have a local spreadsheet for the store manager to create daily reports. Running Microsoft Office is usually outside the scope of this definition.
Serviceability Audit checklist
|
Item
|
|
Most Important
Review Chapter 6. Servicing
|
|
Planning Ahead
Think about servicing when you design your devices. Servicing should not be an afterthought. Will your devices be able to connect to the Internet and communicate with a server? Will your devices use modem access? How many servers do you need to handle the load of servicing?
|
|
Servicing Experience
Invest the time required to design a clear and consistent user experience for servicing. For example, a set top box periodically downloads a program guide. It can also download updates, which simplifies its design and makes the user experience clear and consistent.
|
|
Testing Your Servicing Solution
Test your servicing solution thoroughly so that you are sure that it works correctly. By the time you have deployed your devices in the field, it is too late to fix major bugs. If you thoroughly plan your testing and then test against your plan, you can potentially save time and money. Include scalability testing (tests that ensure that servicing scenarios work the same way, regardless of the number of devices) and corner cases (tests that introduce small deviations in sets of devices).
|
|
Having a Back-Up Plan
Make sure that you create a back-up plan in case your primary servicing solution fails. If you typically service devices by using a broadband connection, you might want to be able to dial up by using a modem, also. You might want to be able to service devices through a CD-ROM or a universal serial bus (USB) storage device (via USB Boot if needed), and plan to replace media and devices in case of failures.
|
|
Ensure image contains the Servicing tools you need
Include useful maintenance tools in your image such as Registry Editor, Administration Support Tools, Misc. Command Line Tools, Net.exe Utility, etc. See Addenda 1. Table of built-in Windows XP utilities.
|
For additional information
Comparison of Servicing Solutions
Supporting Windows XP Embedded-based Devices
Servicing Windows XP Embedded with Service Pack 2
Manage and service a run-time image
Building Serviceable Devices
Security Audit Objective
To produce a secure solution, based on considerations such as the environment in which your device will be deployed.
Select components carefully, in order to minimize surface exposure area
You can optimize the security of your image by including only those components that you need to support your embedded limited functionality runtime application.
Consider removing components that may contain feature functionality that carry a possible risk of exposing the system to viruses or malicious intruders.
Consider adding components that serve as security protection or security control.
Since malicious intruders commonly use the network as the principal access conduit, you should also review all Network related components when conducting a Security review.
Security audit checklist
|
Item
|
|
Most important
Review and deploy the section named Security Considerations in Chapter 6. Servicing
|
|
Within Excel, use the Data->Sort feature to sort the spreadsheet by the column titled “Security”. Review those components related to security. Pick and choose those security related components that are applicable to your image.
|
|
Administrator Account component: Depending on your device scenario, consider specifying a secure password (cmiUserPassword). Also consider using the User Account component to add one or more user accounts with restricted user access settings.
|
|
In order to reduce surface attack area, i.e. reduce exposure to malicious intruder software, consider excluding components from your configuration that are not required for your configuration to function – especially components that are networking or UI related.
|
|
Consider including in your consideration, all components that enhance or support system security, such as Windows Firewall/Internet Connection Sharing.
|
|
Consider the inclusion of Antivirus software.
Runtimes and Antivirus Software
|
|
Design the image so it can be updated with Microsoft security updates. Develop a servicing strategy for accomplishing this.
Deploying Microsoft security updates
|
MSDN Links
Security Considerations for Your Image
Security Considerations for Windows XP Embedded Developers
Add Security Features to a Run-Time Image
Creating a Component for the Custom Security Template
Microsoft Security Home Page
API Audit
You should review components that typically contain APIs (Application Program Interfaces) which are intended for public use.
Audit checklist
|
Item
|
|
Within Excel, use the Data->Sort feature to sort the spreadsheet by the column titled “API”. Then review those specific components.
|
|
In order to minimize image footprint and increase image security, consider deleting components in your image, exposing APIs that are not required by your runtime image.
|
Reliability Audit Objective
To eliminate or reduce potential points of hardware or software failure. This includes but is not limited to prevention or elimination of software bugs.
Audit checklist
|
Item
|
|
Ensure you use SP2 or greater for all new development!
List of fixes included in Windows XP Service Pack 2
|
|
Reliability in Windows Embedded Standard
|
|
Building a Reliable Windows XP Embedded Platform
|
|
Ensure you have in place a test procedure that covers all known code paths for your (limited functionality) runtime, and that you perform a complete test pass before deployment.
|
Objective
This section offers guidelines regarding building configuration files and satisfying dependencies, in order to produce the smallest possible disk image footprint.
In order to produce a fully functioning device in the shortest time, the first time you build your image you should not worry about minimizing the size of the image.
Footprint minimization should occur after proving that your (non-minimized) image is 100% functional. To minimize footprint, rebuild the image from scratch, using a minimal set of hardware components. This way, if any problems develop while building the minimal configuration, you will know the problems are due to inadvertent removal of necessary components.
Ultimately if you want to minimize image footprint, you should build from scratch with the set of known components you need. This is because whenever you add a component to your configuration, all its dependency requirements get pulled in, but when you remove that component later, its dependency requirements are not typically removed at the same time, causing image bloat.
Rebuilding the image from scratch will help ensure that you do not have unnecessary components that were introduced while you were developing, experimenting and testing your original configuration.
Make sure you can view file, registry, and other resources of the components in your .slx file by navigating to and then enabling the option. In Target Designer, click View on the toolbar, and then click to select the Resources check box. You may also need to lower the default visibility in Target Designer to 100 to see most of the components in your database and in your .slx configuration.
Dependency analysis
You can start with a known set of components that you need, then turn automatic dependency resolution off (a Target Designer option). You will see task items for every dependency resolution issue. This will let you see who is dependent on Outlook for example. The Macro components (those components that are shown in bold) are nothing but components containing lists of dependency needs. You might want to review what macro components you are using because they can bloat your footprint quickly. After completing Dependency Checker, you can delete or disable the macro component, because it will already have done its job of pulling in its list of dependent components.
Analyzing the size of the components in your runtime
Review the Build.log file that is generated when you build your image. The footprints of each component are given at the end of the log. Inspect the largest components first and determine whether they may be deleted from your runtime.
Audit checklist
|
Item
|
|
Review this MSDN content:
Footprint
|
|
Delete unneeded hardware components (originally obtained via TAP) in order to reduce the total disk and memory “footprint”. If you used Tap.exe to generate the hardware configuration, see the Disabling Software Enumerated Devices Picked up by TAP.exe tip. The hardware configuration list generated by Tap.exe and imported into your design can have a significant impact on your footprint if you are not careful.
|
|
Rebuild a new configuration using the reduced hardware component configuration.
|
|
Add only the feature components that you know your image requires.
|
|
Do not attempt to minimize footprint by failing to let Target Designer resolve all the component dependencies. This is likely to result in a non-functioning device, or even worse, feature failure that is discovered only after the device has been deployed.
|
|
Disable paging file support. If you have enough RAM to support the services you expect the user to run, you may not need the paging file. Note that paging file is disabled by default.
|
|
Consider removing the Indexing Service component.
Typically, you can safely remove the Indexing Service component to reduce footprint.
The Indexing Service component installs the "Fast Find" indexing that the Windows XP Professional Search functionality uses. This service is not enabled by default in Windows XP Professional and in Standard 2009, so in many cases, it can safely be removed with little to no impact in most runtime images.
The Indexing Service component itself adds approximately 15 MB to most runtime images, so you reduce the overall run-time footprint if you do not need this service.
|
|
Convert the partition on your target embedded device to NTFS, and then compress the volume (the compression feature requires NTFS file system). This can reduce the footprint by up to 40 percent. This requires that you add the NTFS component to the runtime.
|
|
Review the Additional Footprint Links below.
|
Advanced Run-Time Image Techniques
Footprint
Finding and eradicating big footprint
Support WebCast: Microsoft Windows XP Embedded: Reducing the footprint
Footprint Reduction: Remove Indexing Service
Tips for Reducing Footprint Size of a Windows XP Embedded Runtime
File Sharing vs Footprint
Winlogon vs. Minlogon
Adding MMC without the Overhead of IE
Using BOOTPREP
Kaspersky Anti Virus sample component for XPe
|