Greetings one and all! Been heads down on some work around here and haven’t been able to post an update in a while.
A couple of real good case studies have come up recently with regards to driver stability and effective testing of those drivers. So I want to call out some processes we’ve been presenting in our talks and slide decks to you folks for a while, but they are things we do internally as well.
One of the things we are always using in office and test labs are the Object Tracking and Reference History tracking features in UMDF. Cleaning up and maintaining proper lifetime scope of UMDF objects is a real must. Plus we like to make sure the documentation for those DDIs and objects calls out that you need to release a reference once you’ve finished using the object. And we really like to have those trackers on when running negative path testing. Hitting functional code blocks is nice, but we also want to make sure we’re hitting those negative cases as hard, and ideally, harder. It’s never what you expect to work that kills your driver’s resource management. 😉
One easy way to get that extra coverage for negative path testing is to use Application Verifier with its fault injection engine running. I’ve been able to find quite a few fun bugs in code using that little trick. Another bonus you get from Application Verifier is the object leak mechanisms. We’ve all been prone to forgetting to delete objects (mostly handles *g*) and having these caught at incident time makes them easier to track down and in the end, that makes everybody happier.
I know there are some good questions out there, so please feel free to speak up! I love hearing from you all with good case studies or blog fodder.
Now Playing – Charlie Parker Easy to Love