Professional Windows® Embedded Compact 7

DEBUGGING OVERVIEW

Having implemented a stream driver and resolved any compile and build issues, the next task is to fully test the driver. This determines that the driver functions correctly, that it can perform under load, and that it is “a good citizen” in the system. If the driver functions correctly, it can load and unload as required and perform all IO functions that it is designed to do. (For the strings buffer example for the driver to perform correctly, it should properly store a string written to it and return the same string when the stream is read from.) A driver should continue to perform correctly when under load. This would be of more significance when the driver implements threads and interrupts or is designed for multiple simultaneous accesses to a stream. The driver must handle all calls to it, and all its interrupts must be captured by the driver and passed up the software stack to applications using the driver. Being a good citizen in the system means that it must not corrupt or degrade the operating system in any way. It must not hog any shared system resources. It must not generate memory leaks.

To test a software entity, you can simply put print statements in the code to report that it gets to certain points in the code and to report values of variables at those points. Although that is simple enough to implement with an application, a driver normally won’t have a visible output context to display such messages. They may be captured by a debug window but ...