Windows XP and Surprise Removal of Hardware
This article describes changes made in the Microsoft Windows XP operating system to provide improved support for surprise removal of hardware.
|
On This Page
 | Background on Windows and Surprise Removal |
| Changes in Windows XP Beta 2 |
| Summary |
| Call to Action |
Background on Windows and Surprise Removal
Surprise removal of hardware is a common end-user scenario that has always been a challenge for Windows. During the development and testing of Windows 95 and Windows 98, surprise removal of hardware was often found to result in system instability or even hardware damage. System instability was still seen in Windows test labs early in the Windows 2000 product cycle, although hardware damage resulting from surprise removal has become much less common in recent years because hardware vendors have taken steps to prevent this problem. Late in the Windows 2000 development process and in the current Windows XP development process, Windows testers are encountering only minimal problems associated with surprise removal.
Microsoft has generally viewed surprise removal of hardware as an issue that can only be solved by hardware vendors. Therefore, Windows development has progressed under the assumption that hardware vendors would address this issue. As technologies like PC Card, CardBus, and docking increased in popularity, Microsoft encouraged system and device manufacturers (OEMs and IHVs) to include physical interlocks in slots and connectors to prevent surprise removal of these devices. However, the hardware community has consistently expressed concerns about this approach because of the additional cost of locking mechanisms.
Because surprise removal resulted in system instability or other problems, and because the hardware community could not integrate physical locking mechanisms due to cost constraints, Microsoft added a mitigating feature in Windows to warn users with a pop-up message anytime surprise removal of hardware occurred. Although this was obviously a minor step, because the design philosophy was that hardware vendors had to address the problem, the Windows team did not go further than adding this UI message.
However, late in Windows 2000 development and early in the Windows XP development process, the Windows team began to reevaluate this approach. Because the hardware community had not designed locks to prevent surprise removal, and because users prefer surprise removal over controlled removals, it became obvious that the operating system had to address the problem and provide support for these scenarios. Although providing robust surprise-removal support is a long-term and challenging prospect that will involve work on the part of Microsoft and hardware vendors, there is some positive movement toward this goal in the Windows XP timeframe:
| • | Windows testing shows that, since Windows 95, hardware vendors have significantly decreased the likelihood of hardware damage related to surprise removal. In Windows XP test labs, we see no hardware damage in surprise removal scenarios, because hardware vendors have been addressing electrical issues in their designs. |
| • | Testing also shows that bug fixes in Windows 2000 and Windows XP have made the operating system much more resilient to surprise removal. In most surprise-removal scenarios, the user does not experience any problems. |
However, both Microsoft and the industry as a whole need to increase testing of these scenarios, while encouraging driver writers and application developers to ensure that their code accommodates surprise removal of hardware and handles it gracefully.
Changes in Windows XP Beta 2
Refinements to Caching Policy for Consumer Storage
Essentially, anything a user can physically remove from a machine could be removed from a running system without prior warning to the operating system - for example, any kind of device on CardBus, PC Card, USB, IEEE 1394, and so on. However, the area of greatest concern is storage devices, because of the possibility of data loss or corruption when surprise removal of these devices occurs.
To mitigate the likelihood of data loss in these scenarios, Windows XP has a refined caching policy for removable storage. As of Windows XP Beta 2, for consumer-oriented removable storage (USB, Flash, Zip, and so on), write caching is disabled by default.
Disabling write caching means that, instead of saving up changes for a file on a removable storage device and then doing a bulk write, Windows XP writes changes to the file as the changes are made. This keeps data on removable storage devices more current, mitigating the likelihood of data loss. However, disabling write caching also has a performance impact. Therefore, for IEEE 1394 hard disk drives, Windows applies a special case for the default caching policy by not disabling write caching for these devices.
The basic way to think of write caching policy is:
| • | If write caching is disabled by default, the storage device in question is optimized for safe surprise removal. This is the appropriate action for slower, consumer-oriented storage devices such as flash-type memory. |
| • | If write caching is enabled by default, the storage device in question is optimized for performance. This is the appropriate action for high-performance storage such as SCSI and IEEE 1394 hard disk drives. |
Note that caching policy defaults for a given device can be changed in Device Manager.
Optimizing the Default Caching Policy
As noted earlier, in Windows XP Beta 2, IEEE 1394 hard disk drives have write caching enabled by default, to optimize for performance rather than for safe surprise removal. This also means users should first stop IEEE 1394 hard disk drives using the hotplug applet before removing them. However, the Beta 2 mechanism for special-casing IEEE 1394 hard disk drives requires additional refinement.
In Beta 2, Windows XP applied the special case based on a list of known device IDs for IEEE 1394 hard disk drives. Therefore, any IEEE 1394 hard disk drive unknown to Windows XP Beta 2 will not be special cased. To improve this implementation after Beta 2, the Windows team is working with the IEEE 1394 and USB standards bodies to develop a mechanism for vendors to communicate to the operating system the preferred caching policy for a given storage device. There is also a method for vendors to enable write caching via an INF file.
No More "Surprise Remove" Pop-ups
A bit can be set that tells Windows whether a device can be safely removed without first warning the operating system. For example, this "Surprise Remove OK" bit could be set for something like a USB mouse or keyboard. Before the Beta 2 UI change, if a user removed any device that did not have the "Surprise Remove OK" bit set without first warning the operating system, then the following message appeared from the system tray.
Users received a similar message when they first inserted the device, reminding them to go to the hotplug applet to stop the device before removing it. Users also received a "surprise undock" message if they removed the mobile unit from a docking without first requesting "Undock PC" from the Start menu.
All of these pop-up messages were removed for Windows XP Beta 2.
However, note that for any device that does not have the "Surprise Remove OK" bit set, the hotplug applet still appears in the system tray. So, users who choose to stop a device before removing it still have a mechanism for doing so. For example, it is advisable for users to rely on the hotplug applet when removing high-performance storage devices such as IEEE 1394 hard disk drives, because these devices have write caching enabled by default.
Summary
The following changes were made in Windows XP Beta 2 to improve support for surprise removal of hardware:
| • | Windows XP has a refined default caching policy for removable storage devices - write caching is disabled by default for many removable storage devices. This will mitigate the likelihood of data loss in storage surprise-removal scenarios, but will also have a performance impact. |
| • | Windows will no longer show end-users a popup message upon surprise removal of hardware devices or docking units. |
Call to Action
For device and system manufacturers:
| • | Ensure that surprise removal is included in all standard test passes for removable hardware. | ||||
| • | Encourage your partners to test these scenarios and fix their bugs. | ||||
| • | When you find problems in surprise-removal scenarios, determine the source of the problem and address it, rather than assuming that the scenario is simply not supported. | ||||
| • | Primary areas where hardware vendors need to design for surprise remove scenarios are:
|
For IEEE 1394 hard drive vendors:
| • |
Ensure that Microsoft has the identification numbers required to identify all your current and soon-to-be-released hard drives. |
For software developers:
| • | Test your application or other software in surprise removal scenarios, and file and fix bugs when problems occur. |
| • | Integrate surprise removal testing into your standard software test passes. |