| ||||||
| Search Microsoft.com for: |
 |
Removable Devices and WindowsUpdated: December 4, 2001 
On This Page
Beginning with the introduction of Plug and Play-capable PC Card devices under the Microsoft® Windows® 95 operating system, users have come to understand that some devices can be inserted into a PC when the system is fully powered on, and that some devices can be removed and swapped for other devices while the PC is active. Users gain this same "hot plugging" Plug and Play support in Windows 2000 and later operating systems. Click here for information about Windows XP. To the end user, this capability is like the familiar operation of a VCR, where tapes can be inserted and removed while the VCR and television are on. However, PC users frequently experienced unfortunate consequences -- including system stalls and loss of data -- when removing hot-pluggable devices if removal is not controlled by operating system software. The problem is that for many device designs, surprise removals usually do not provide notification to the operating system to ensure that data transactions are complete before the user is allowed to remove the device. The only method that ensures the best -- and expected -- user experience for surprise removal of hot-pluggable devices is a locking mechanism that ensures devices are removed only under operating system control or during sleep or off states. However, many IHVs and OEMs have been reluctant to invest in the mechanisms that can both ensure a good user experience and prevent support calls related to system failures and data loss. This paper summarizes the appropriate support mechanisms for hot-pluggable devices under the Windows 95, Windows 98, and Windows 2000 operating systems. This paper also provides some guidelines for improving the user experience when locking mechanisms are not implemented for hot-pluggable devices. Hot Plugging Support under WindowsHot plugging support is provided for USB and PC Card (including CardBus) under Windows 95, with support expanded for PCI and IEEE 1394 under the Windows 98 operating system for implementations that follow the ACPI Specification, Revision 1.0 or higher. Hot plugging for devices on any of these buses is available under Windows 2000 as part of the implementation of Plug and Play support. For device-driver implementation details related to this new support, see the latest version of the Windows DDK. The following capabilities for managing hot plugging of devices are requirements in the current PC System Design Guide; they are also highly recommended design practices.
Managing Surprise Removal under Windows 98 and Windows 2000Surprise removal occurs when the user removes a hot-pluggable card, either purposefully or accidentally, without first using the user interface that controls removal of the card. Surprise removal cannot be guaranteed to work without causing a system failure for devices on PC Card, PCI, ISA, and IEEE 1394 buses. This is because removing a device in the middle of a bus phase is likely to lock the bus, even if the drivers are made to be robust. It is possible that device removal in the middle of a bus phase could cause undetected memory corruption. Although surprise removal of devices on USB will not stall the system, for many devices it is still rude behavior and could cause device-side data corruption. For example, before a disk is removed, the operating system needs to be notified in order to flush the cache to the disk. In all events and for all bus types, at the operating system level, paged I/O (PIO) that can't occur because of a surprise removal will fail. In the current PC System Design Guide it is highly recommended that designers ensure that surprise removal of any swappable device should not cause a system failure such as a spontaneous reboot, system stall, or blue screen. At a minimum, the device driver should ensure that the PC system does not fail if the user accidentally pulls the device out of its socket. In all cases, for any failure that might occur, the PC system as a whole should be able to recover gracefully and report the condition to the end user. However, even if the driver has checks added to ensure more robust support, safe support for surprise removal cannot be guaranteed. Adding thorough "sanity checking" code to every code path would result in bloated, slow drivers. Furthermore, testing all possible drivers on Windows to ensure that they can cope with surprise removal in all cases is an impossible task. Again, the only absolute way to ensure against system failure is to prevent surprise removals by including a locking mechanism, which is strongly recommended. However, with that caveat, there are methods that the device driver can use to partially protect the system from failing if a surprise removal occurs. One method of protection is to have the driver check whether its device is present when it receives certain interrupts. For example, CardBus cards share the same PCI interrupt as their socket controller, so interrupt handlers for both the card driver and socket driver are chained to the same PCI interrupt request. To prevent a system fault after surprise removal of a CardBus card, its driver must check whether its device is still present whenever it reads a value such as 0xFFh in its status register, and then it must be able to recover gracefully when this occurs. Another case, where PCI device drivers should anticipate surprise removal, is for PCI devices in a docking bar that has no locking mechanism. In this system configuration, when undocking, the PCI devices in the docking bar are treated as surprise removals. This applies only for a docking bar, not a complete VCR-style docking station. Surprise Removal and PC Card Drivers. For PC Card and CardBus drivers, the driver must not erroneously claim an interrupt that is not generated by its device, especially when the device can share interrupts. To meet this capability, the following specific coding practices are important:
For example, Windows 2000 drivers must not call routines that access pageable data while holding a spin lock. For more information, see the topics "Using Spin Locks" and "Handling Removable Media" in the current version of the Windows DDK. Logging with WMI. Under Windows 2000 and Windows 98, if the driver does suspect a hardware removal after performing a check, this should be logged using Windows Management Instrumentation (WMI) APIs. For information about these new APIs, see the documentation of WMI and the Windows Driver Model (WDM) in the current version of the Windows 2000 DDK. See also the web site for manageability, which includes the WMI specification and Win32 extensions schema, available at http://msdn.microsoft.com/downloads/default.asp?URL=/code/sample.asp?url=/msdn-files/027/001/566/msdncompositedoc.xml. Conclusion: Use Hardware Locking. The designer of a system that does not include a locking mechanism should always provide strong and obvious reminders to the end user, cautioning that use of the user interface for device removal is absolutely necessary to protect data and system integrity when devices are removed. Ultimately, to guarantee that surprise removal works properly without data lost for devices on any bus, the system design must ensure that removal of all devices is under the control of the operating system. This means allowing the user to remove a device only by using a software interface that provides operating system notification before unlocking the device, or using a locking mechanical switch that provides electronic notification to the operating system. For more information about the controlling mechanisms provided under ACPI, see Section 5.6.3 of the ACPI Specification, Version 1.0. |
