Robustness Testing of the Microsoft Win32 API Charles P. Shelton Philip Koopman Kobey DeVale ECE Department & ICES ECE Department ECE Department Carnegie Mellon University Carnegie Mellon University Carnegie Mellon University Pittsburgh, PA, USA Pittsburgh, PA, USA Pittsburgh, PA, USA [email protected] [email protected] [email protected] Abstract Unfortunately, Windows operating systems have ac- quired a general reputation of being less dependable than Although Microsoft Windows is being deployed in Unix-based operating systems. In particular, the infamous mission-critical applications, little quantitative data has "Blue Screen Of Death" that is displayed as a result of Win- been published about its robustness. We present the results dows system crashes is perceived by many as being far of executing over two million Ballista-generated exception handling tests across 237 functions and system calls more prevalent than the equivalent kernel panics of Unix involving six Windows variants, as well as similar tests operating systems. Additionally, it is a common (although conducted on the Linux operating system. Windows 95, meagerly documented) experience that Windows systems Windows 98, and Windows CE were found to be vulnerable need to be rebooted more often than Unix systems. How- to complete system crashes caused by very simple C ever, there is little if any quantitative data published on the programs for several different functions. No system dependability of Windows, and no objective way to predict crashes were observed on Windows NT, Windows 2000, whether the impending move to Windows 2000 will actu- and Linux. Linux was significantly more graceful at ally improve dependability over either Windows 98 or Win- handling exceptions from system calls in a dows NT. program-recoverable manner than Windows NT and Windows 2000, but those Windows variants were more Beyond the dependability of Windows itself, the com- robust than Linux (with glibc) at handling C library parative dependability of Windows and Unix-based sys- exceptions. While the choice of operating systems cannot tems such as Linux has become a recurring theme of be made solely on the basis of one set of tests, it is hoped discussion in the media and Internet forums. While the that such results will form a starting point for comparing most that can usually be quantified is mean time between dependability across heterogeneous platforms. reboots (anecdotally, Unix systems are generally said to op- erate longer between reboots than Windows NT), issues 1. Introduction such as system administration, machine usage, the behavior of application programs, and even the stability of underly- ing hardware typically make such comparisons problem- Different versions of the Microsoft Windows operating atic. It would be useful to have a comparison of reliability system (OS) are becoming popular for mission- and between Windows and Unix systems based on direct, re- safety-critical applications. The Windows 95/98 OS family producible measurements on a reasonably level playing is the dominant OS used in personal computer systems, and field. Windows NT 4.0 has become increasingly popular in busi- The success of many critical systems requires depend- ness applications. The United States Navy has adopted able operation, and a significant component of system de- Windows NT as the official OS to be incorporated into pendability can be a robust operating system. (Robustness onboard computer systems [15]. Windows CE and Win- is formally defined as the degree to which a software com- dows NT Embedded are new alternatives for embedded op- ponent functions correctly in the presence of exceptional erating systems. Thus, there is considerable market and inputs or stressful environmental conditions [6].) Of partic- economic pressure to adopt Windows systems for critical ular concern is the behavior of the system when confronted applications. with exceptional operating conditions and consequent ex- This is a reprint plus appendices of a paper appearing in the International Conference on Dependable Systems and Net- works, June 25-28, 2000. © 2000 IEEE. Personal use of this material is permitted. However,permission to reprint/repub- lish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works must be obtained from the IEEE. 1 ceptional data values. Because these instances are by defi- separate pool defined for each data type being tested. nition not within the scope of designed operation, it is These pools of values contain exceptional as well as crucial that the system as a whole, and the OS in particular, non-exceptional cases to avoid successful exception han- react gracefully to prevent compromising critical operating dling on one parameter from masking the potential effects requirements. (Some systems, such as clustered web serv- of unsuccessful exception handling on some other parame- ers, can be architected to withstand single-node failures; ter value. Each test case (the execution of a single MuT however there are many critical systems in the embedded with a single test value selected for each required parameter computing world and mission-critical systems on desktops in the call) is executed as a separate task to minimize the oc- which cannot afford such redundancy, and which require currence of cross-test interference. A single Ballista test highly dependable individual nodes.) case involves selecting a set of test values, executing con- This paper presents a quantitative comparison of the structors associated with those test values to initialize es- vulnerability of six different versions of the Windows sential system state, executing a call to the MuT with the Win32 Application Programming Interface (API) to ro- selected test values in its parameter list, measuring whether bustness failures caused by exceptional function or system the MuT behaves in a robust manner in that situation, and call parameter values. These results are compared to the re- cleaning up any lingering system state in preparation for the sults of similarly testing Linux for exception handling ro- next test (including freeing memory and deleting tempo- bustness. rary files). Exception handling tests are performed using the Ballista testing looks only for non-robust responses Ballista robustness testing harness [1] for both Windows from software, and does not test for correct functionality. and Linux. In order to perform a reasonable This, combined with a data type-based testing strategy, Windows-to-Linux comparison, 237 calls were selected for rather than a functional testing strategy, results in a highly testing from the Win32 API, and matched with 183 calls of scalable testing approach in which the effort spent on test comparable functionality from the Linux API. Of these development tends to grow sub-linearly with the number of calls, 94 were C library functions that were tested with MuTs to be tested. An additional property of Ballista test- identical test cases in both APIs, with the balance of calls ing results is that in practice they have proven to be highly being system calls. Beyond C library functions, the calls repeatable. Virtually all test results reproduce the same ro- selected for testing were common services used by many bustness problems every time a brief single-test program application programs such as memory management, file representing a single test case is executed. and directory system management, input/output (I/O), and Ballista uses the CRASH scale [9] to measure robust or process execution/control. The results are reported in non-robust responses from MuTs. CRASH is an acronym groups rather than as individual functions to provide a for the different robustness failures that can occur. In reasonable basis for comparison in those areas where the Catastrophic failures, the most severe robustness failure APIs differ in the number and type of calls provided. type, the application causes a complete system crash that requires an OS reboot for recovery. In Restart failures, the 2. Background application enters a state where it "hangs" and will not con- tinue normal operation, requiring an application restart for The Ballista software testing methodology has been de- recovery. Abort failures are an abnormal termination of an scribed in detail elsewhere [3], [9] and is publicly available application task as the result of a signal or thrown exception as an Internet-based testing service [1] involving a central that is not specific enough to constitute a recoverable error testing server and a portable testing client that was ported to condition unless the task elects (or is forced by default) to Windows NT and Windows CE for this research. Thus, terminate and restart. Silent failures occur when a function only a brief summary of Ballista testing operation will be or call is performed with invalid parameter values, but the given. system reports that it was completed successfully instead of The Ballista testing methodology is a combination of returning an error indication. Finally, Hindering failures software testing and fault injection approaches. Spe- report an incorrect error indication such as the wrong error cifically selected exceptional values (selected via typical reporting code. Ballista can automatically detect Cata- software testing strategies) are used to inject faults into a strophic, Restart, and Abort failures; Silent failures and system via