Testing Driver, Filter, and Services Applications on Microsoft Windows 2000

Noel Nyman
Windows NT Applications Test

May 1998

Summary: While testing applications on prerelease builds of Microsoft® Windows® 2000, we've found categories of applications that share similar problems (bugs). We refer to the applications as "driver applications" because they have one or more of these characteristics:

Antivirus, remote control, backup, disk defragmenter and redirector applications are typical driver applications.

This article discusses the types of bugs the Windows NT Applications Test team found and the testing methods that expose them. The test methods described here may help you identify bugs exposed in your applications on Windows 2000. Our goal is to release Windows 2000 with as many applications as possible running bug free on the operating system.

Verify the tests discussed here against your existing application test plans to ensure that the bugs found by these methods are also exposed by your regular tests. We use applications on pre-release builds of Windows NT to find Windows NT bugs. We cannot test applications exhaustively. The tests described in this paper are not meant to be comprehensive for any application.

Bluescreens

The most disturbing bugs a user sees when running Windows NT result in a "bluescreen," the character mode screen with a blue background and cryptic lists of driver names with addresses in hexadecimal. The bluescreen is known colloquially as "the bluescreen of death" because it means Windows NT has crashed, as far as the user is concerned. The only recourse is to manually reset or power cycle the computer. Often, data not saved to disk is lost in the process.

User-mode applications rarely cause bluescreens. Windows NT usually isolates user processes from the operating system to prevent such problems. Driver applications can cause bluescreens because they are more closely linked to the operating system than user applications.

Bluescreens During Startup and Log On

We've seen several driver applications that bluescreen immediately when the computer is rebooted after installation or when the user first logs on. In most cases, these bluescreens are consistent and, if they happen with your application, you've probably already seen them if you've tested it on a Windows 2000 beta build.

Some of the startup and log on bluescreens are not consistent. They may appear intermittently, or on some test systems and not on others. To find inconsistent or infrequent bluescreens, try these test scenarios:

Bluescreens During Regular Operation of Your Application

Tests in these categories can help you find bluescreen problems that occur after startup and log on.

File access tests

Driver applications are often intimately involved with file access. Here are some of the tests we use that expose bluescreen bugs:

Local drives

We see bluescreen bugs exposed by tests on some types of drives, but not on others. Try to include one example of each of these in your local drive test scenarios:

Mount points

The drive that hosts a mount point must be a Windows 2000 NTFS drive, but the mounted share can be any type. If your application makes the assumption that all folders will be Windows 2000 NTFS, you may see bugs when the application processes these mount point types:

Built-in defragmentation

Windows 2000 is scheduled to release with limited feature defragmentation. The defragmenter is available on prerelease builds as a preview. Test your application both before and after the defragmenter is used on local drives.

Network drives

If your application works with network or mapped shares, test each of these:

Test Your Application while Other Applications Run

Occasionally your application tests bug free, but other applications will have problems because of changes you've made in the operating system. While your application is running, install and test some of these types of applications:

Use your application on "typical desktops" for several days of user activity. For applications that run on servers, use load and stress tests. Beta testing is also a good source of "typical desktops" user bugs.

Failure to Initialize

We've seen several applications that fail to start a real-time monitor function, but don't warn the user that the function isn't working. Antivirus program users, for example, may assume they're protected against viruses when opening files from a floppy disk or network share, even in the absence of a real-time monitor icon on the taskbar, unless your application specifically warns them about a failure to initialize this feature. The best solution is to make sure the feature properly starts on Windows 2000. However, if the feature fails, check that one of these events happens:

If your application displays an icon on the Windows NT 4.0 taskbar, make sure it appears on Windows 2000 when the functionality is active. Use a separate "disabled" icon when the functionality is not available, rather than just removing your icon from the taskbar.

Other Driver Application Bugs

The bugs in this section seldom result in bluescreens and they may not cause serious problems, such as data loss. But they are obvious to the user and we have found each of them in more than one application. When testing your application on Windows 2000 be sure to check the following:

Migration Issues

We want users to be able to migrate from a Windows 95 or a Windows NT 4.0 installation directly to Windows 2000 with all preferences, privileges, and applications working after migration. Microsoft has provided the Migration DLL feature so that vendors can make changes necessary to allow Windows 95 applications to run successfully on Windows 2000 after migration. Application migration from Windows NT 4.0 to Windows 2000 should not require special code. Test migration for your application by installing on Windows 95 and/or Windows NT 4.0, then installing Windows 2000 in the same %systemroot% folder. Run your full regression test suite after Windows 2000 migration, paying particular attention to the special issues raised in this article.