email article printer friendly

Researching a Path to Fewer Bugs
by Patrick Meader

February 2003 Issue

Patrick Meader Editor in Chief

Would you like to see tools such as SLAM and SDV make their way into Visual Studio? Discuss this in the Talk to the Editors of Visual Studio Magazine forum on our Web site. Use this Locator+ code: VS0302EN_D

The process of writing computer software and applications tends to range from highly complex to exponentially more complex. One obvious consequence of this complexity: bugs. They plague developers at all levels of the development spectrum, whether you create database front ends, build back-end commerce sites, or write device drivers.

Bugs have been a particular source of concern for Microsoft itself, which has been chastised frequently for lax security and a seemingly unending stream of bug fixes and service packs. In the past year, Microsoft has emphasized its commitment to creating both more secure and more reliable applications. A white paper on its site details Microsoft's Trustworthy Computing initiative: "If computing is to become truly ubiquitous—and fulfill the immense promise of technology—we will have to make the computing ecosystem sufficiently trustworthy that people don't worry about its fallibility or unreliability the way they do today."

With this in mind, I sat down recently with Jim Larus, a senior researcher at Microsoft Research who leads the Software Productivity Tools research group (). We spoke about the tools Microsoft Research is working on that will help the company to reduce bugs in its products.

One of the primary goals of Larus' group is to develop tools that analyze projects to locate bugs as an application is compiled. Microsoft has been researching a model checking approach that it adapted from the hardware world that verifies state machines for software. The Software, Languages, Analysis, and Model checking project (SLAM) analyzes software as a complicated state machine, ensuring that a particular rule is followed, no matter what path a user might navigate in an application. For example, assume you want to make sure that a certain event never takes place before another event. This approach can take exponentially large state machines and check them for particular rules completely.

You can exploit this tool by creating a set of rules that govern a given application. Programs can travel many paths, and it's hard to check them all, especially in little used paths, which tend to be the source of many difficult-to-trace bugs. This approach lets you test a particular condition for any possible state. It can tell you when and where a rule is violated; sometimes, of course, the violation doesn't indicate a bug, but rather that the rule itself is flawed.

Larus noted that Microsoft has adapted this SLAM project to create the Static Driver Verifier (SDV). His team worked with the group in Microsoft responsible for creating device drivers to come up with a large list of rules. Device drivers are extremely complicated and the source of many crashes that end users experience. SDV enables you to write a single set of rules you can apply to the literally thousands of drivers that exist for various flavors of Windows. Larus indicated that Microsoft tests third-party device drivers with this tool as well. This is important because when a third-party device driver fails, it looks like it's the OS that has bombed. In a sense, it has, but the code that brought it crashing down isn't code that Microsoft created. Running SDV on third-party device drivers should have a significant practical effect for all those who use Microsoft toolsets.

It's all well and good that Microsoft has such tools at its disposal internally—no one is going to complain about more reliable development tools, servers, and operating systems. But one can't help but wonder when, if ever, rank-and-file developers might be able to get their hands on these kinds of tools in their own work. Larus indicated that there's no timeframe for delivering such tools to Visual Studio users—the tools in their present state are useful, but also rough around the edges and require a lot of handholding. That said, he noted: "Obviously, as a researcher, I'd love rank-and-file programmers to be able to take our tools and be able to use them in their everyday jobs. It's gratifying to think that the work you do as a researcher can make people's lives easier."

Here's to hoping such tools make the transition to consumer products or are eventually included as part of Visual Studio .NET.