Ask the Windows 2000 Dev Team

Every other week we put your How-Come-You-Did-That questions to the Windows 2000 development team. Submit your questions here.

Reliability Concerns: Dealing with Drivers, Memory Problems

Q: How does Windows 2000 handle the effects that drivers have on operating-system reliability?

A: You bring up a good point: Hardware drivers can affect reliability. The Windows 2000 Drivers Initiative urges widespread development of drivers for Windows 2000 that support Plug and Play, Advanced Configuration and Power Interface (ACPI), and hardware-management capabilities. The Windows 2000 team encourages developers to take advantage of the Driver Verifier and improved Driver Test Tools, which was made available for download in the Windows 2000 Device Driver Kit (DDK) for Release Candidate 1. There is a wealth of information about hardware and driver development at the Windows Driver and Hardware Development site. Well-tested, reliable drivers contribute to overall system reliability.

Q: What does it mean to get a driver digitally signed?

A: Once the development of your driver is complete, you can submit it to the Microsoft Windows Hardware Quality Labs (WHQL) for testing. If the driver passes the tests, Microsoft can digitally sign it to certify that the driver being installed on a system is identical to the one Microsoft tested. No change is made to the driver's binary file itself. Instead, a catalog file (CAT or *.cat) is created for each driver package and that CAT file is signed with a Microsoft digital signature. The relationship between the driver package and its CAT file is referenced in the driver's information file (INF or *.inf) and is maintained by the system after the driver is installed. Users can be assured that the drivers they're installing won't destabilize their systems.

Q: What if I'm not writing drivers? What else does Windows 2000 do to protect against, for example, memory-management problems in applications of all kinds?

A: Indeed, one of the most common problems is memory heap corruption, which can deteriorate system reliability. To help developers detect problems early on, the PageHeap feature in Windows 2000 heap manager can be enabled during application development. When the PageHeap feature is enabled, all heap allocations — including heap allocations from all DLLs (dynamic-link libraries) in that process — are placed in memory such that the end of the heap allocation is aligned with the end of a virtual page of memory. The page of virtual memory following the allocation is set to NO_ACCESS. Any memory reads or writes beyond the end of the heap allocation will cause an immediate access violation in the application, which a debugger will catch and show the developer which exact line of code is causing heap corruption. Similarly, for freed heap allocations, the PageHeap manager changes the freed allocation's virtual page protection to NO_ACCESS so that an access violation will occur if the application attempts to read or write memory in the freed heap block.