Reliability in Windows Embedded Standard 2009
Built on the Microsoft Windows 2000 code base, Windows XP provides many improvements over earlier versions of Windows. Expanded safeguards against errant applications, faulty device drivers, and a focus on reliability makes Windows Embedded Standard a dependable operating system to build an embedded system on. This article discusses overall reliability of Windows and focuses on development tips for building a reliable Windows Embedded Standard image
This section discusses system reliability by examining non-responsive system statistics, and provides details about improvements in application and driver compatibility.
For more information about reliability, see this Microsoft Web site.
Windows 2000 and Windows XP Statistics
Systems can stop responding for many reasons, ranging from defective device drivers to unresponsive applications. The following illustrations show the causes of non-responsive systems for both Windows 2000 and Windows XP.
|This information is from Windows XP SP1. The statistics from Windows XP SP2 may be significantly different because of all the security work that was done for that release.|
Figure 1. Windows 2000 results
The Windows 2000 results show that third-party device drivers and filter drivers caused many systems to stop responding. However, such core Windows components as the Microsoft Win32 kernel, networking and file systems were also a significant cause of non-responsive systems. One of the focus areas in developing Windows XP was in improving these core Windows components. The book, Windows Internals, by Mark Russinovich, discusses how the kernel works in detail. This includes feature improvements over previous Windows operating systems, such as truly independent address and I/O space so user mode processes cannot affect one another.
For more information about Windows Internals, see this Microsoft Web site.
Figure 2. Windows XP results
The results for Windows XP show a significant improvement in the reliability of the core Windows kernel and other services, such as networking and file systems. Third-party device drivers, by a wide margin, are the most significant cause of non-responsive Windows XP systems.
Application Compatibility Improvements
Windows XP includes a compatibility mode that emulates the environment of earlier versions of Windows and therefore supports applications built for earlier versions of Windows. These compatibility modes increase reliability by preventing application errors. In addition, Windows XP includes a side-by-side execution of assemblies, dynamic-link libraries (DLLs), components, and other shared resources. This enables different applications to access different versions of the same resource file at the same time. In earlier versions of Windows, DLL versioning conflicts could cause the system to stop responding. Side-by-side sharing also extends backward compatibility for applications and reduces the risk of a non-responsive system.
When you create a system with Windows Embedded Standard you can use any Windows 32-bit application with the assurance that it will run reliably without having to port or recompile the application. However, we recommend that applications that were tested on Windows XP be retested on your Windows Embedded Standard run-time image, because the application may look for component dependencies that may not have been included in your Windows Embedded Standard image.
Device Driver Compatibility Improvements
Drivers can occupy a significant part of kernel space, and a defective driver decreases the reliability of a system. Therefore, improved driver handling was a focus of Windows XP. In addition, you can use new and improved tools to develop and test device drivers for your embedded targets.
Windows XP includes the following improvements to the Driver Verifier, which is used to monitor kernel-mode drivers:
Driver deadlock monitoring
Asynchronous I/O checking
User-mode buffer overwrite checking
Surrogate I/O request packet (IRP) checking
In addition, the Driver Verifier includes improvements to memory pool tracking. This enables easier detection and diagnosis of memory leaks. Such leaks might be the result of memory allocations made by device drivers. If these allocations are not freed, system performance can decrease, and possibly cause the system to stop responding. Catching these memory leaks is very important to a system's performance. With Windows Embedded Standard, these memory leaks can be easily detected.
The Windows Software Trace Preprocessor (WPP) simplifies the tracking of kernel-mode drivers and user-mode applications. On a running system, WPP monitors drivers in real time and logs debug messages to trace potential problems. By using only a minimal CPU load, WPP assists in device driver development.
Developers can use the following software engineering design best practices to improve reliability.
Choosing Hardware and Software
A major advantage of Windows Embedded Standard is that developers can use off-the-shelf x86 based hardware for their client devices. This saves time and money. However, developers must understand that device hardware is a key component of device reliability. Windows XP is only as reliable as the most weakly designed device driver in the system. Microsoft cannot manage or control the reliability of drivers that we did not write. Therefore, if a customer is absolutely intent on guaranteeing the most reliable OS possible, they should carefully manage what drivers are installed, make sure that they are reputable, driver signed, the latest version, and so on. Driver Verifier is a valuable tool in assessing drivers for use on your embedded operating system.
When you select hardware, you should evaluate:
Does the vendor hardware meet or exceed the target system requirements? Those requirements are, Intel Pentium II or a later version CPU, ACPI PnP BIOS support, PCI 2.0 or a later version support, 5 MB of storage media, 64 MB of RAM.
Does the hardware vendor have a focus on quality? What is their quality process? Are they involved with the Microsoft Windows Hardware Quality Lab (WHQL) program?
When you select application and driver software to run on an embedded device, developers should evaluate the following:
Do the software vendors warranty their software drivers or applications?
Do the vendors offer responsive technical support?
If a specialized piece of hardware or software has only one vendor and a technical issue arises, how responsive will the vendor be?
Embedded Development Process
Following “Best Practices” when developing your Windows Embedded Standard image will contribute to the overall reliability of the device:
Write a requirements document for the device
This document should outline what functions the device is required to perform, what is the expected performance and image size, how an end user will have to configure and interact with the device, how the device will be manufactured and images deployed to it, and how the device will be updated or serviced when it is deployed in the field. These areas all determine what components are needed in developing the image, and how these components and features should be configured.
Load Windows XP Professional and your software applications on the target hardware
The best investment of time that a developer can make, to guarantee a reliable build, is to first install Windows XP Professional (the desktop operating system) on his x86 target embedded device hardware. Getting Windows XP Professional and the specified applications installed and running provides a benchmark on the reliability of the hardware, drivers, and applications. This benchmarking exercise will let a developer eliminate the hardware, driver binaries, and applications, as possible sources of Windows Embedded Standard build errors.
Back up the Embedded Database
Regularly backing up your embedded database or saving copies of different versions of the database will guarantee that you can always duplicate the same image repeatedly. This is important for servicing or troubleshooting images.
Understand Target Analyzer
Target Analyzer's two programs, Target Analyzer Pro (Tap.exe) and Target Analyzer (Ta.exe), complement one another. Target Analyzer Pro is a Microsoft Win32 application that requires either Windows 2000 or Windows XP be installed on the target device. If the developer cannot use Target Analyzer Pro, there is the option of running Target Analyzer, which runs in a MS-DOS environment. Target Analyzer detects the presence only, instead of the presence and device, of ACPI, USB, 1394, SCSI, PCMCIA and ISA. In addition, Target Analyzer produces a best guess for the hardware abstraction layer (HAL) and does not detect software-enumerated devices. When you use Target Analyzer, you may need additional sources for documenting the target device architecture.
Dependency Checking in Target Designer
As a Windows Embedded Standard build is configured, Target Designer continually examines long dependency chains. Each component has its own needs and dependencies. Target Designer automatically resolves dependency issues between components if the Auto-resolve dependencies check box is selected. The downside to this automation is that the build may become larger than a developer wants without providing visibility into what components were added to satisfy dependencies. A developer must understand the tradeoff between speeding the build process and using Automated Dependency checking and minimizing the size of the image.
Clone the OS Image
Cloning guarantees all images deployed to devices are identical and there will not be issues down the road from manually configuring individual devices. Cloning also saves time in deploying an image to the hardware.
Test the Image
It cannot be stressed enough how important it is for the image to be thoroughly tested, both the original image, and any later updates that are made to the image. In addition to focused application and OS testing, end-to-end user scenarios and servicing scenarios should also be tested. These scenarios can be derived for the requirements document. Several utilities are available that can help with Windows Embedded Standard testing, debugging and troubleshooting, such as Process Monitor, InCtrl5 or similar monitoring tools, Dependency Walker, and Kernel Debugger.
For more information about Process Monitor, see this Microsoft Web site.
For more information about InCtrl5, see this Web site.
For more information about Dependency Walker, see this Web site.
For more information about Kernel Debugger, see this Microsoft Web site.
Use the embedded community resources
Microsoft supports a very strong developer community for Windows Embedded Standard at the Windows Embedded Developer Center on MSDN. Using community resources for research is a quick way to obtain guidance. It is likely that other developers have encountered similar issues and solutions are already published. Developers can take advantage of newsgroups and forums, technical and knowledge base articles, chat sessions, blogs, and more.
For more information about Windows Embedded Developer Center, see this Microsoft Web site.
Windows Embedded Standard includes all the changes that were made for Windows XP Service Pack 3 (SP3). SP3 included many fixes to make sure that it was more secure and reliable. For a list of these fixes see this Microsoft Web site.
Service packs are cumulative and roll any previous fixes into the latest service pack so that any fixes for Windows XP Service Pack 2 (SP2) were included in SP3. For a list of SP2 fixes see this Microsoft Web site.
Finally, the subject of reliability is closely tied to security with regard to surface attack reduction, services and networking and so on. For more information about security, see this Microsoft Web site.