About Test Manager

Test Manager is a 32-bit Windows application designed to run the compatibility tests and to provide a quick summary of test results.

Test Manager is the test shell that runs tests and collects results for Windows Hardware Quality Labs (WHQL) Hardware Compatibility Tests (HCT). Test Manager consists of several test groups that correspond to common hardware categories.

You start the hardware device and system HCT kit from the Test Manager.


Installing the HCT

You must install the Hardware Compatibility Test (HCT) kit on the system used for testing.

Note: If you are testing communication devices, you must install the HCT on both the client and server systems.

To install the HCT

  12. Insert the AVFSF Test kit CD into the CD-ROM.
  13. Open the HCT folder, and then double-click the HWTest.exe file.
  14. At the Microsoft Windows Hardware Compatibility Tests window, click System/Device Hardware Compatibility Tests.
  15. At the Startup window, enter the appropriate destination location for your HCT file (for example, C:\HCT)into the Install To text box, and then click OK.

The correct default paths appear in the Test Binaries Loc text box, and the Update Binaries Loc text.

  16. In the product Identification dialog box, enter the Product Name with the name of your test device or system, as you want it to appear on the HCL, and then click Continue.
  17. At the Tester Type window, select the appropriate test device category, select the specific test device name, and then click Continue.
  18. In the System Configuration dialog box, click the following buttons to complete the required information, and then click Continue. For more information about completing the system configuration dialog boxes, see Completing the System Configuration window.
  • System
  • Processors
  • Video
  • I/O
  • Network
  • MultiMedia

After you complete the installation, the system displays the Test Manager window.


Completing the System Configuration window

The System Configuration window is where you record information about your system configuration, including: the processor, video adapter, I/O card, and network adapter. This information can be used by Submission Assistant later, so completing it in now saves time when making a submission. This information is only required for system submissions.

Note: It is important that to provide all requested information completely and accurately. Microsoft reserves the right to refuse test results if the requested information is not accurate. Complete the items marked by a "*" in the System Configuration dialog boxes or the test results may rejected.

Example of system configuration information

Required system information | Example
Machine ID — ID that you assign | Testbed001
Marketed System Model Name — the system name that your company advertises and wants to appear on the HCL | Desktop ExecPro 4000/133
Processor Model and Speed | Pentium 133
System Bus Type(s) | ISA/PCI
System BIOS Version and Sub-version | Phoenix 4.05 m6-p14
Motherboard Manufacturer and Model | Intel Zappa
I/O Adapter Manufacturer and Model or Chipset — HCT only recognizes the installed driver and requires that you identify the actual I/O adapter or chipset. | Adaptec 2940 or CMD 640B Dual Channel IDE Controller
I/O Controller Embedded or Adapter | Check the box in the I/O configuration dialog
Video Adapter Manufacturer and Model | Diamond Stealth 64 DRAM
Video Chipset and Model | S3-768
Video BIOS Information | Stealth DRAM version 2.02
Video Controller Embedded or Adapter | Check the box in the video configuration dialog

You can also change the Machine ID and Product Name in the System Configuration window.

If you do not have all of the necessary information and must exit the System Configuration window, click the Close button in the upper right corner of the window.

To enter System Configuration information

  19. From the System Configuration window, click each of the following buttons, and complete the information in each dialog box:
  • System

Enter general system configuration information.

  • Processor

Enter details about the system’s processors. Multiprocessor support in Windows requires that all processors in the system be of exactly the same revision level. If there is more than one, specify the number of processors.

  • Video

Enter information about the video subsystem that the computer uses.

  • I/O

Enter information about all of the host bus adapters and hard disks in the computer. Use the list boxes to make your selections. You can enter up to eight adapters and up to eight hard disks.

  • Network

Enter details about the model of the network interface card.

Use the TAB key to move within the dialog box, and complete all items marked with an asterisk.

  20. From each System Configuration dialog box, click Done to return to the System Configuration window.
  21. After you complete all dialog boxes, click Continue to open the Test Manager window.
  22. To modify system configuration from Test Manager, on the View menu, click System Configuration.


Starting Test Manager

Installing Test Manager creates a Test Manager program group on the Start menu, as well as a Test Manager icon.

To start Test Manager from the Start menu

  1. Start Windows.
  2. On the Start menu, select Programs, and select HCT.
  3. Double-click the Test Manager icon to start the testing program.

To start the Test Manager from the keyboard

Note: The following procedure assumes that Test Manager is installed on the test system’s C: drive. If Test Manager is installed at another location, enter the path to that location in step two below.

  4. On the Start menu, choose Run.
  5. Type C:\Temp\testmgr.exe.

C represents the drive that HCT copied files to.


Selecting tests in Test Manager

Use Test Manager to:

  • Add tests to the list of tests to run.
  • Remove tests from the list of tests to run.
  • Start running tests from the list of tests to run.

Test Manager also allows modification of test parameters and viewing of test results. Test Manager uses a hierarchical listing to display system components and devices. The advantage of this method is that it allows a tester to quickly see what can be tested under the System and Device headings. A "+" next to an item indicates that there are more items to view; a "-" next to an item indicates a complete listing.

To expand the list of System and Device tests

  • From the Test Manager Available Tests pane, click "+".

– Or –

  • From the keyboard, use the Left Arrow and Right Arrow keys.

Test Manager contains these boxes:

  • Available Tests: This pane lists System and Device tests. When you select and add a test, it moves to the Selected Tests pane.
  • Selected Tests: When you select and add a test, it moves from the Available Tests pane to this pane. The Selected Tests pane lists tests in the order you select them. This is also the order in which they will execute.

To select only the tests necessary for system certification

  • Select System, and then click the Add button.

To run a set of tests from the Test Manager window

  6. Select the tests you want to run, and then click Start.

When the tests are completed, the Test Results box appears.

  7. Select a test, and then click Details.
  8. When finished viewing test result details, click OK to return to Test Manager.

To select all available tests

  • In the Available Test pane, select the appropriate test device category, click Add Selection, and then click Start.

This moves all available tests to the Selected Tests pane.

To select one or more available tests

  • In the Available Tests pane, click the "+" test listing, and then double-click each test.

– Or –

  • In the Available Tests pane, select each test or test group by clicking once, and then click Add Selection to move the tests to the Selected Tests pane.

To remove a selected test

  • In the Selected Tests pane, select the test, and then click Remove Selection.

To remove all selected tests

  • Click Remove All Items.

You can run the tests individually or in groups, rather than running the entire set in a single session. If you select the manual tests first, you can then run the automated tests unattended.

If you are using the HCTs to include systems on the HCL, you only need to run the system compatibility tests.


Using Test Manager commands

This table gives you a reference to the commands you can use in Test Manager:

Test Manager Menu Commands

Command | Function
Test Menu
Exit | Use to exit Test Manger.
View Menu
Test Results | Use to view test results.
System Configuration | Use to view and change the system and install configuration.
Change Initial Run Settings | Use to change initial test run settings.
Rescan Test Devices | Use to refresh your system and device listings.
Test Group Menu
Load Test Group File | Use when you want to run a saved series of system and device tests.
Save Test Group File | Use to save a listing of system and device tests.
Load Last Running Group | Use to run a listing of system and device tests.
Return Test Results Menu
Return System Test Results | Use to prepare test results to send to Microsoft
Check Test Results Menu
Check System Test Results | Provides a list of the required tests that must still be passed for this system.
Help Menu
Index | Opens WHQL Test Procedures.
About Test Manager | Provides information about the version of Test Manager that you are using.


Using test group files

Use the Test Group menu to save and load groups of frequently used tests, and also reload the last group of tests used.

To use the Test Group menu

  9. Select a group of tests, and do one of the following:
  • Click Save Test Group File

The Save As window appears so you can save this group of tests onto your computer.

  • Click Load Test Group File

The Load Test Group File window appears so you can navigate to a group of tests you want to run.

  • Click Load Last-Running Group

Reloads the last group of tests run in Test Manager so you can run them again.

  10. Complete the groups of tests, click the View menu, and then select Test Results.

To start the HCTs

  • In Test Manager, click Start.

The tests run one-at-a-time and in the order they are listed in the Selected Tests list.

For manual tests, read the test description first, and then carefully follow the on-screen instructions. If the test fails, Test Manager logs a Fail result and runs the next test in the Selected Tests list.

Note: With the exception of the System Stress test, tests can be stopped when they are running. To do this, in the Test Manager window, click Abort.


Viewing test results

The Test Results window appears when a test run finishes or is aborted. This window lists every selected test and its status — Pass, Fail, or Not Run. From this window, you can verify that all tests ran and passed.

If a test failed, you can check the detailed results.

To view test results

  11. Select the test name in the Test Results window, and then click Details.

This displays the test log file.

  12. When you are finished viewing the test log file, click OK to return to the Test Manager window.

There is a separate log file for each test. The system always saves the log file from the last run of each test. If you rerun a test, the new log file has a number appended to it (for example, acpicmb2.log), and the original test log is saved.

Note: If the test system crashes during a test run, look at the log file called LASTRUN.LOG in the \HCT directory. It contains a list of the tests that ran up to the point of the crash. This shows you which test was running when the system failed. If you are running a kernel debugger, the debug machine also displays the name of the test that was running when the test system failed.


Examining and copying test log files

After you complete the HCT tests, you must examine your test log files, copy the test log files, and then send the test log files to WHQL with your test submission.

To view test results

  1. At the Test Manager window, click View Results.

The middle column displays a Pass, Fail, or Not Run status.

  2. Select one or more tests from the list displayed, and then click Details.

You can view the content of each log file. Use the navigation buttons to search for warnings, failures, or specific text.

  3. Examine your test logs for failures, and then do one of the following:
  • If tests appear in the Warning: Incomplete Test Results dialog box, solve the problems indicated in the test log before submitting the log file to WHQL.
  • If no tests appear in the Warning: Incomplete Test Results dialog box, continue with the following procedure.

To copy the HCT test completion logs

  1. When you complete each test, at the Test Manager window, click Return Test Results.
  2. Insert a disk into the appropriate drive, enter the appropriate disk location into the text box provided, and then click Copy Logs.

WHQL recommends using Iomega® Zip®, or CD-R.

  3. This step is optional: If you are returning results for multiple operating systems on one disk, type in the name of the operating system for which you are returning results in the Directory text box.
  4. Submit test logs to WHQL with each test submission.


File System Filter Logo Requirements for Microsoft Windows 2000 Anti-virus Applications – Draft 0.5


Introduction to the AVFSF Logo Program

Real-time anti-virus applications are driver dependant applications consisting of a user mode application as well as one or more kernel mode file system filter drivers. The Application Specification for Windows 2000 provides clear concise guidelines for desktop and server applications. Software that complies with this specification is eligible to carry the "Certified for Windows" Logo. In addition, this document describes new and more detailed requirements for a specific class of kernel-mode drivers, namely file system filters. Windows Hardware Quality Labs (WHQL) provide generic interface and stress tests for all file system filters as well as specific scenario tests for anti-virus applications. The anti-virus file system filter kit (AV/FSF Kit) containing these tests, is the first among file system filters kits provided by WHQL. Currently, the test kit is applicable only to anti-virus file system filters, but WHQL will expand the scope in the future to test other file system filters.

The Anti-Virus File System Filter kit (AV/FSF kit) provided by WHQL provides an additional level of testing for anti-virus driver dependant applications, to ensure that they operate under the Windows 2000 operating system as "good citizens" and appropriately interact with other file system filters and the operating system. The kit does not test the functionality of the AV product. The key benefits of having your AV application undergo WHQL testing is as follows:

  • The kernel mode drivers on passing WHQL testing, are eligible for the Microsoft Designed for Windows Logo program.
  • The interaction of an anti-virus application with the operating system is extremely complex during normal pass through operation as well as scenarios of virus detection, user-alert and dis-infection. The filter is rigorously tested for good citizenship under Windows 2000 operating system, so that it does not bugcheck the system under any of these circumstances, thereby, guaranteeing a robust application.
  • Subtle problems in file system filters can result in deadlock when multiple filters operate simultaneously. The anti-virus filter is tested for co-existence with other file system filter drivers. End users are expected to run multiple filter drivers simultaneously, such as anti-virus and encryption filters or multiple anti-virus products.
  • A significant percentage (12%) of NT4 system crashes were attributed to anti-virus applications. This number is expected to decrease dramatically with passing WHQL testing, resulting in a better end user experience.


Application Testing versus WHQL Testing

As mentioned earlier, in order to meet the Certified for Windows logo, applications are tested rigorously to ensure that they comply with the Windows 2000 Application Specifications by Veritest, an independent Microsoft Windows Logo Program Testing Laboratory. These tests ensure that the application meets windows fundamentals, install/uninstall, component sharing, data and settings management, user interface, OnNow/ACPI support, and application migration requirements. In addition server applications must meet active directory requirements, security requirements, and cluster service requirements (for advanced server and datacenter server only). Kernel mode drivers must also pass validation triggered by the Windows 2000 Driver Verifier Manager tool (Verifier.exe located in the \system32 directory). With the release of the AV/FSF kit, anti-virus applications with kernel mode filter drivers must self-test with the WHQL provided AV/FSF kit. The objective is to subject kernel mode drivers to the following additional requirements:


AV/FSF Logo Requirements

The following logo requirements for anti-virus file system filters must be met by all AV/FSF applications. The anti-virus application must be tested on both single and dual-CPU machines running Windows 2000 Server, Service Pack 1. If the AV product is designed specifically for Windows 2000 Professional only, then it must be tested on single and dual-CPU system running Windows 2000 Professional, SP1.

  1. Transparency during normal mode of operation: The AV application must preserve File System API semantics and behave as a transparent file system filter for non-infected files under normal and stress environment.
  2. Transparency under virus infected conditions: The AV application should not have any adverse effects on the operating system while performing detection, user alert, and dis-infection of a virus from a range of file types on local drives.
  3. Good Kernel mode practices: The AV application must pass stringent IRP processing checked by the Windows 2000 Driver Verifier Manager tool (verifier.exe located in the \system32 directory).
  4. Support Plug and Play Drives: The AV application must support plug and play drives such as removable USB/1394 drives.
  5. Support OnNow/ACPI: The AV application must intelligently support OnNow/ACPI requirements as specified in the Application Specification for Windows 2000 and the filter driver should not register for power IRPs.
  6. Support Removable Media Drives: The AV application must support both fixed and removable media unless the product is designed not to work on either of these and clearly indicates the nature of the limitation. In particular, AV applications that scan floppy drives must pass the floppy I/O test while actively scanning the floppy drive.
  7. Resilience to invalid data: The AV application must be able to handle out-of-band IOCTL/FSCTL control codes without crashing the system.

In addition, the AV/FSF drivers must meet the following additional requirements:

  1. The virus signature update policy (auto update) on AV applications must indicate if any kernel mode components have changed. If a kernel mode component change is required the auto-update policy must display a pop up for user to accept or reject update, since acceptance of any kernel mode driver update will invalidate the logo (as well as the digital signature resulting in the kernel mode drivers being unsigned).
  2. All kernel mode drivers must only use ntddk.h or ntifs.h. This implies that they must not touch any data structures that have not been exported such as ETHREAD and KTHREAD structures. In general, all kernel mode drivers must not modify operating system functions, operating system dispatch tables, or private operating system data structures.
  3. All file system filters must propagate fast IO callbacks.
  4. File system filters must be able to handle dynamic volumes that can appear or disappear.
  5. File system filters must be responsive to HSM.
  6. File sytem filters can call IODetachDevice() only in the FastIODetachDevice routine. They must not call autodetach (from Installshield) under any circumstances.
  7. The AV application must comply with the Application Specification for Windows 2000 Install/Uninstall requirements. In addition, the preferred method of installing kernel mode drivers is by Windows Installer service. As a future Whistler requirement, all kernel mode drivers must be right-click installable by an INF file.
  8. Anti-virus file system filters must be able to cope with NTFS read-only volumes. This is a future requirement for Whistler


About the AV/FSF tests

The Anti-Virus/File System Filter test suite contains 2 sets of tests:

  • Generic_file_system_filter_tests
  • Anti-virus_scenario_tests

A list of the tests is given below. You must run the Driver Verifier, Devctl, Floppy I/O, USB_Disabler, PMTE,IFSTEST-AV and IOSTRESS-AV tests and submit passing logs with your submission

Test | Description
Devctl | This test queries for the device name in native object tree format (such as \device\filespy). The Devctl test can take a maximum of 24 hours to complete.
Driver Verifier | This test verifies selected drivers. No log file is created. The Driver Verifier takes approximately 2-5 hours to complete.
Floppy I/O | This test exercises the floppy drive. The Floppy I/O test takes approximately 1 hour to complete.
USB_Disabler | This test enumerates all USB devices starting at the root, and enables and disables each device. The USB Disabler test takes approximately 5 minutes to 1 hour to complete.
IFSTEST-AV | This test checks the file system interface and tests for transparency of the filter driver The anti-virus tests activate the scanning and detection code paths of the anti-virus driver under test.
CDTest | This is a stress test that exercises the CDROM drive. No log file is created. The test runs in an infinite loop. To stop the test, close the command windows.
IOSTRESS-AV | This is a stress test that stresses the I/O subsystem, and launches the driver verifier from within the stress engine. The stress test takes approximately 72 hours to complete. The stress mix consists of the anti-virus tests in addition to other file stress tests.
PMTE | This stress test puts the system into hibernate and resumes from hibernate state periodically. This test runs in an infinite loop. The PMTE test takes approximately 24 hours to complete.


Transparency under virus infected conditions:

The AV application should not have any adverse effects on the operating system during the detection, user alert, and dis-infection of a virus from a range of file types on local drives. The goal is to exercise the functional code paths of anti-virus filters. This differs from IFSTests which normally confirm that the filter driver is not affecting functionality during pass through mode only. The AV scenario tests will be run in conjunction with IOSTRESS with the AV application loaded and actively scanning all drives. The scenario tests invoke virus detection scenarios in a number of ways. The tests confirm the following:After the anti-virus filter is invoked, the main (unnamed) data stream of the file should have changed. The tests do not attempt to understand if the change is appropriate – i.e., they do not test the functionality of the AV application.


Transparency during normal mode of operation:

The AV application must preserve File System API semantics and behave as a transparent file system filter for non-infected files under normal and stress environment. A suite of tests called the Installable File System Test, IFSTest, is used to test the compliance of installable file systems in Windows 2000 Server Operating System. The NT Native Call API interface sits below all subsystems in the OS. Since IFSTest rigorously verifies the correct operation of the file system at this level it is a generic functional test for any generic file system or file system filter. Please refer to detailed setup instructions on how to configure system before running IFSTest. In conjunction, a mix of stress tests called IOStress, that stress the file system thoroughly is to be run on all drives discussed above. IOSTRESS also contains stress tests to stress PnP functionality, ACPI sleep states, and enable/disble of removable drives to ensure that the file system filter does not in any way interfere with them. The AV application must not crash or bugcheck the system as a result of resource timeout and/or critical section timeout during a 72 hour run of IOSTRESS that stresses the system. While running IFSTest and IOStress, the AV application’s file system filter driver must be the only filter driver loaded and should be actively scanning all drives.


Good Kernel Mode Practices:

The AV application must pass stringent IRP processing checking by the Windows 2000 Driver Verifier (DV) Manager tool. Driver Verifier is a series of checks added to the Windows 2000 kernel to expose errors in kernel mode drivers. DV detects the following errors:

  • Buffer overrun and underrun by use of a special pool
  • Force IRQL checking by providing extreme memory pressure on the driver revealing paging violations
  • Memory leak detection using pool tracking
  • Low resource simulation to test the driver’s ability to react properly to low memory conditions
  • I/O verification by allocating IRPs from a special pool, monitoring the driver’s I/O handling and completing all IRPs at DPC.


Support Plug and Play Drives

The AV application must support plug and play drives such as removable USB/1394 drives. The device should have passed the USB Disable test independently and be on the Hardware Compatibility List. The AV application must be scanning the plug and play drive continuously while the USB disable test enables and disables the driveFile system filter drivers must define a dispatch routine to handle PnP IRPs.


Support OnNow/ACPI:

The AV application must intelligently support OnNow/ACPI requirements as specified in the Application Specification for Windows 2000 http://msdn.microsoft.com/certification/appspec.asp and the filter driver should not register for power IRPs. Generally, file system filter drivers do not receive IRP_MJ_POWER requests. The PMTE test suite is a stress test that puts the system in and out of sleep states S1-S4. Running PMTE along with the AV application scanning ensures that the file system filter does not in any way interact with power management. Please choose logod systems that support sleep states (available in the HCL) for testing.


Support Removable Media Drives:

The AV application must support both fixed and removable media unless the product is designed not to work on either of these and clearly indicates the nature of the limitation. In particular, AV applications that scan floppy drives must pass the floppy I/O test while actively scanning the floppy drive.


Resilience to Invalid Data

The AV application must be able to handle out-of-band IOCTL/FSCTL control codes without crashing the system.


Additional behavioral requirements for AV applications

In order to receive certification, AV applications must be able to behave as follows:

Behavior | Reason
There must be a way for the real-time scanner to detect viruses without any popups or user intervention | During the 72 hour test run, we don’t want the test runs to be blocked waiting for user input in these cases.
There must be a way to deploy the product in a way where the Administrator of the system can prevent kernel mode components being automatically updated | An administrator of a system needs a way to ensure their system only runs certified kernel drivers. This is especially important for Datacenter configurations.


Notes for Whistler certification

Note that AV applications will be required to recertify for Whistler. In addition, for Whistler, AV applications will be required to install their kernel components via an INF file, to be described in the Whistler IFSKIT documentation.


Chapter 21: Anti-virus File System Filter Test Specification

Draft Version: 0.3 — Date: November 10, 2000

This chapter describes the anti-virus file system test assertions tested.


Anti-virus File System Test Assertions

This section provides the test assertions.


Anti-virus Scenario Test (IFSTEST-Virus) Assertions

The following assertions test the File system API semantics and transparency during virus-infected mode of operation. The AV application must preserve File System API semantics and behave as a transparent file system filter under virus infected conditions. These assertions are tested by the Installable File System test (IFSTEST-Virus). Also, see "Anti-virus File System Filter Assertions Not Tested" for a list of assertions to comply with that are not to be tested.


File System API Test (IFSTEST) Assertions

The following assertions test the File system API semantics and transparency during normal mode of operation. The AV application must preserve File System API semantics and behave as a transparent file system filter for non-infected files under normal conditions These assertions are tested by the Installable File System test (IFSTEST). Also, see "Anti-virus File System Filter Assertions Not Tested" for a list of assertions to comply with that are not to be tested.


Driver Quality Assertions

  1. Good Kernel mode practices: The AV application must pass stringent IRP processing checked by the Windows 2000 Driver Verifier Manager tool (verifier.exe located in the \system32 directory).
  2. Support Plug and Play Drives: The AV application must support plug and play drives such as removable USB/1394 drives.
  3. Support OnNow/ACPI: The AV application must intelligently support OnNow/ACPI requirements as specified in the Application Specification for Windows 2000 and the filter driver should not register for power IRPs.
  4. Support Removable Media Drives: The AV application must support both fixed and removable media unless the product is designed not to work on either of these and clearly indicates the nature of the limitation. In particular, AV applications that scan floppy drives must pass the floppy I/O test while actively scanning the floppy drive.
  5. Resilience to invalid data: The AV application must be able to handle out-of-band IOCTL/FSCTL control codes without crashing the system.


Anti-virus File System Filter Assertions Not Tested

  1. The virus signature update policy (auto update) on AV applications must indicate if any kernel mode components have changed. If a kernel mode component change is required the auto-update policy must display a pop up for user to accept or reject update, since acceptance of any kernel mode driver update will invalidate the logo (as well as the digital signature resulting in the kernel mode drivers being unsigned).
  2. All kernel mode drivers must only use ntddk.h or ntifs.h. This implies that they must not touch any data structures that have not been exported such as ETHREAD and KTHREAD structures. In general, all kernel mode drivers must not modify operating system functions, operating system dispatch tables, or private operating system data structures.
  3. All file system filters must propagate fast IO callbacks.
  4. File system filters must be able to handle dynamic volumes that can appear or disappear.
  5. File system filters must be responsive to HSM.
  6. File sytem filters can call IODetachDevice() only in the FastIODetachDevice routine. They must not call autodetach (from Installshield) under any circumstances.
  7. The AV application must comply with the Application Specification for Windows 2000 Install/Uninstall requirements. In addition, the preferred method of installing kernel mode drivers is by Windows Installer service. As a future Whistler requirement, all kernel mode drivers must be right-click installable by an INF file.
  8. Anti-virus file system filters must be able to cope with NTFS read-only volumes. This is a future requirement for Whistler


OpenCreateGeneral File System Test Assertions

21.2.1 The File System must accurately create a paging file.

Reference documents: ???.
Test descriptions: "TD-21.2 OpenCreateGeneral File System Test Group – CreatePagingFileTest"

21.2.2 The File System must accurately form filenames up to the maximum filename length the file system will support.

Reference documents: ???.
Test descriptions: "TD-21.2 OpenCreateGeneral File System Test Group – FileNameLengthTest"

21.2.3 The File System must accurately parse the double backslash when used as a prefix for a filename or directory name.

Reference documents: ???.
Test descriptions: "TD-21.2 OpenCreateGeneral File System Test Group – HFHTest"

21.2.4 The File System must accurately use filenames contain Unicode characters if the Unicode on disk volume attribute flag is set.

Reference documents: ???.
Test descriptions: "TD-21.2 OpenCreateGeneral File System Test Group – UnicodeOnDiskTest"

21.2.5 The File System must accurately differentiate between filenames that differ only in case if the case sensitive search volume attribute flag is set.

Reference documents: ???.
Test descriptions: "TD-21.2 OpenCreateGeneral File System Test Group – CaseSensitiveTest"

21.2.6 The File System must accurately preserve the case of different filenames if the case preserved names volume attribute flag is set.

Reference documents: ???.
Test descriptions: "TD-21.2 OpenCreateGeneral File System Test Group – PreserveCaseTest"

21.2.7 The File System must accurately create an 8.3 representation for the long filenames if the file system supports long names.

Reference documents: ???.
Test descriptions: "TD-21.2 OpenCreateGeneral File System Test Group – ShortFileNameTest"

21.2.8 The File System must accurately use share access for files and directories.

Reference documents: ???.
Test descriptions: "TD-21.2 OpenCreateGeneral File System Test Group – ShareAccessTest"

21.2.9 The File System must accurately supports alternate data streams for files access if using NTFS file system.

Reference documents: ???.
Test descriptions: "TD-21.2 OpenCreateGeneral File System Test Group – AlternateStreamTest"

21.2.10 The File System must accurately support share access of alternate data streams.

Reference documents: ???.
Test descriptions: "TD-21.2 OpenCreateGeneral File System Test Group – StreamShareTest"

21.2.11 The File System must accurately create a Device Object in the root directory.

Reference documents: ???.
Test descriptions: "TD-21.2 OpenCreateGeneral File System Test Group – FileSystemDeviceOpenTest"

21.2.12 The File System must accurately create a file using the full path.

Reference documents: ???.
Test descriptions: "TD-21.2 OpenCreateGeneral File System Test Group – FileFullPathCreationTest"

21.2.13 The File System must accurately create a directory using the full path including the system root, volume root, and directory path.

Reference documents: ???.
Test descriptions: "TD-21.2 OpenCreateGeneral File System Test Group – DirectoryFullPathCreationTest"

21.2.14 The File System must accurately create and access files by going through the handle of an open directory.

Reference documents: ???.
Test descriptions: "TD-21.2 OpenCreateGeneral File System Test Group – FileRelativePathCreationTest"

21.2.15 The File System must accurately create and access directories by going through the handle of an open directory.

Reference documents: ???.
Test descriptions: "TD-21.2 OpenCreateGeneral File System Test Group – DirectoryRelativePathCreationTest"

21.2.16 The File System must accurately open files using the unique and persistent identifier for the file.

Reference documents: ???.
Test descriptions: "TD-21.2 OpenCreateGeneral File System Test Group – FileOpenByIDTest"

21.2.17 The File System must accurately use the non-directory file option flag by being able to open a file but not being able to open a directory if set.

Reference documents: ???.
Test descriptions: "TD-21.2 OpenCreateGeneral File System Test Group – NonDirectoryFileOpenTest"

21.2.18 The File System must accurately use the directory file flag by being able to open a file but not being able to open a directory if set.

Reference documents: ???.
Test descriptions: "TD-21.2 OpenCreateGeneral File System Test Group – NonDirectoryFileOpenTest"

21.2.19 The File System must accurately support volume or DASD opening of volumes.

Reference documents: ???.
Test descriptions: "TD-21.2 OpenCreateGeneral File System Test Group – OpenVolumeTest"


OpenCreateParameters File System Test Assertions

21.3.1 The File System must accurately use the file overwrite disposition with the file create function, existing file is truncated and attributes are ORed.

Reference documents: ???.
Test descriptions: "TD-21.3 OpenCreateParameters File System Test Group – OverwriteFileTest"

21.3.2 The File System must accurately requires an existing file when using the file overwrite disposition with the file create function.

Reference documents: ???.
Test descriptions: "TD-21.3 OpenCreateParameters File System Test Group – OverwriteFileAllocTest"

21.3.3 The File System must accurately use System and Hidden attributes when using the file overwrite disposition with the file create function.

Reference documents: ???.
Test descriptions: "TD-21.3 OpenCreateParameters File System Test Group – OverwriteFileAttrTest"

21.3.4 The File System must accurately use the file overwrite disposition with file supersede disposition, existing file is truncated and attributes are replaced with the new attributes.

Reference documents: ???.
Test descriptions: "TD-21.3 OpenCreateParameters File System Test Group – SupersedeFileTest"

21.3.5 The File System must accurately requires an existing file when using the file overwrite disposition with file supersede disposition.

Reference documents: ???.
Test descriptions: "TD-21.3 OpenCreateParameters File System Test Group – SupersedeFileAllocTest"

21.3.6 The File System must accurately use System and Hidden attributes when using the file overwrite disposition with file supersede disposition.

Reference documents: ???.
Test descriptions: "TD-21.3 OpenCreateParameters File System Test Group – SupersedeFileAttrTest"

21.3.7 The File System must accurately allow files to be opened for reading but not for writing when the read only attribute is set.

Reference documents: ???.
Test descriptions: "TD-21.3 OpenCreateParameters File System Test Group – ReadOnlyAttributeTest"

21.3.8 The File System must accurately create files with the system attribute set.

Reference documents: ???.
Test descriptions: "TD-21.3 OpenCreateParameters File System Test Group – SystemAttributeTest"

21.3.9 The File System must accurately open existing files but not be able to open files that do not exist.

Reference documents: ???.
Test descriptions: "TD-21.3 OpenCreateParameters File System Test Group – OpenFileTest"

21.3.10 The File System must accurately open existing directories but not be able to open directories that do not exist.

Reference documents: ???.
Test descriptions: "TD-21.3 OpenCreateParameters File System Test Group – OpenFileDirTest"

21.3.11 The File System must accurately create files unless the file already exists.

Reference documents: ???.
Test descriptions: "TD-21.3 OpenCreateParameters File System Test Group – CreateFileTest"

21.3.12 The File System must accurately open an existing files.

Reference documents: ???.
Test descriptions: "TD-21.3 OpenCreateParameters File System Test Group – OpenAlwaysFileTest"

21.3.13 The File System must accurately create a file when opening a nonexistent file.

Reference documents: ???.
Test descriptions: "TD-21.3 OpenCreateParameters File System Test Group – OpenAlwaysFileTest"

21.3.14 The File System must accurately create a directory when opening a nonexistent directory.

Reference documents: ???.
Test descriptions: "TD-21.3 OpenCreateParameters File System Test Group – OpenAlwaysFileDirTest"

21.3.15 The File System must accurately use the file overwrite if disposition.

Reference documents: ???.
Test descriptions: "TD-21.3 OpenCreateParameters File System Test Group – OverwriteAlwaysFileTest"

21.3.16 The File System must accurately use the file overwrite if disposition with both an existing and non-existing files.

Reference documents: ???.
Test descriptions: "TD-21.3 OpenCreateParameters File System Test Group – OverwriteAlwaysAllocTest"

21.3.17 The File System must accurately use the file overwrite if disposition on hidden system files

Reference documents: ???.
Test descriptions: "TD-21.3 OpenCreateParameters File System Test Group – OverwriteAlwaysAttrTest"

21.3.18 The File System must be able accurately set allocation sizes of files at creation time.

Reference documents: ???.
Test descriptions: "TD-21.3 OpenCreateParameters File System Test Group – FileAllocationSizeTest"

21.3.19 The File System must accurately use the file execute disposition to cause the updating of the last accessed time on a handle close.

Reference documents: ???.
Test descriptions: "TD-21.3 OpenCreateParameters File System Test Group – ExecuteAccessTest"

21.3.20 The File System must be able accurately set the hidden attribute of files at creation time.

Reference documents: ???.
Test descriptions: "TD-21.3 OpenCreateParameters File System Test Group – HiddenAttributeTest"

21.3.21 The File System must be able accurately set the normal attribute set (NOT read only, hidden, system, directory or archive) of files at creation time.

Reference documents: ???.
Test descriptions: "TD-21.3 OpenCreateParameters File System Test Group – NormalAttributeTest"

21.3.22 The File System must be able accurately set the directory attribute of files at creation time to create a directory.

Reference documents: ???.
Test descriptions: "TD-21.3 OpenCreateParameters File System Test Group – DirectoryAttributeTest"

21.3.23 The File System must accurately use the file create disposition to create directories.

Reference documents: ???.
Test descriptions: "TD-21.3 OpenCreateParameters File System Test Group – CreateFileDirTest"

21.3.24 The File System must accurately set the archive attribute of files at creation time.

Reference documents: ???.
Test descriptions: "TD-21.3 OpenCreateParameters File System Test Group – ArchiveAttributeTest"


CloseCleanupDelete File System Test Assertions

21.4.1 The File System must accurately open a volume for DASD access.

Reference documents: ???.
Test descriptions: "TD-21.4 CloseCleanupDelete File System Test Group – VolumeUnlockOnCloseTest"

21.4.2 The File System must accurately record the failed attempt to open a file on a locked volume.

Reference documents: ???.
Test descriptions: "TD-21.4 CloseCleanupDelete File System Test Group – VolumeUnlockOnCloseTest"

21.4.3 The File System must be able to accurately create and delete files in a selected directory.

Reference documents: ???.
Test descriptions: "TD-21.4 CloseCleanupDelete File System Test Group – UpdateOnCloseTest"

21.4.4 The File System must be able to accurately find a files contained a directory using a Directory Handle and obtain the File Times (creation, accessed, change, and last write times) , Attributes, End of File Pointer, and Allocation size; and that these are within appropriate ranges.

Reference documents: ???.
Test descriptions: "TD-21.4 CloseCleanupDelete File System Test Group – UpdateOnCloseTest"

21.4.5 The File System must be able to accurately create and delete a sub-directory in a selected directory.

Reference documents: ???.
Test descriptions: "TD-21.4 CloseCleanupDelete File System Test Group – UpdateOnCloseDirTest"

21.4.6 The File System must be able to accurately use a Directory Handle to find a sub-directory contained in that directory, and obtain the File Times, Attributes, End of File Pointer, and Allocation size; and that these are within appropriate ranges.

Reference documents: ???.
Test descriptions: "TD-21.4 CloseCleanupDelete File System Test Group – UpdateOnCloseDirTest"

21.4.7 The File System must be able to accurately reduce the allocation size of a file (rounded up to the nearest minimum allocation unit) when the allocation size is larger than the file size.

Reference documents: ???.
Test descriptions: "TD-21.4 CloseCleanupDelete File System Test Group – TruncateOnCloseTest"

21.4.8 The File System must be able to accurately query a directory for files using both long and short filenames.

Reference documents: ???.
Test descriptions: "TD-21.4 CloseCleanupDelete File System Test Group – TunnelingTest"

21.4.9 The File System must be able accurately delete and recreate a files using their short file name will recreate their long file name.

Reference documents: ???.
Test descriptions: "TD-21.4 CloseCleanupDelete File System Test Group – TunnelingTest"

21.4.10 The File System must be able to accurately delete files mark for delete on close via the open/create option.

Reference documents: ???.
Test descriptions: "TD-21.4 CloseCleanupDelete File System Test Group – DeleteOnLastCloseTest"

21.4.11 The File System must be able to accurately delete files marked for delete on close, via the file information.

Reference documents: ???.
Test descriptions: "TD-21.4 CloseCleanupDelete File System Test Group – DeleteOnLastCloseTest"

21.4.12 The File System must be able to accurately delete a file when the final handle to a "delete on close file" is closed.

Reference documents: ???.
Test descriptions: "TD-21.4 CloseCleanupDelete File System Test Group – DeleteOnLastCloseTest"


VolumeInformation File System Test Assertions

21.5.1 The operating system must be able to accurately query and set volume labels.

Reference documents: ???.
Test descriptions: "TD-21.5 VolumeInformation File System Test Group – VolumeLabelTest"

21.5.2 The operating system must be able to accurately query the volume for creation time, serial number, label length, support objects, and volume label.

Reference documents: ???.
Test descriptions: "TD-21.5 VolumeInformation File System Test Group – VolumeInformationTest"

21.5.3 The operating system must be able to accurately query the volume size information (total allocation units, available allocation units, sectors per allocation unit and bytes per sector).

Reference documents: ???.
Test descriptions: "TD-21.5 VolumeInformation File System Test Group – SizeInformationTest"

21.5.4 The operating system must be able to accurately query the volume device information (device type and characteristics).

Reference documents: ???.
Test descriptions: "TD-21.5 VolumeInformation File System Test Group – DeviceInformationTest"

21.5.5 The operating system must be able to accurately query for volume attribute information (file system attributes, maximum component name length, file system name length and file system name) using volume, directory and file handles.

Reference documents: ???.
Test descriptions: "TD-21.5 VolumeInformation File System Test Group – AttributeInformationTest"


FileInformation File System Test Assertions

21.6.1 The file information must be accurately read all (basic information, standard information, internal information, EA information, position information and name information) at the same time.

Reference documents: ???.
Test descriptions: "TD-21.6 FileInformation File System Test Group – AllInformationTest"

21.6.2 The file information must be accurately truncate or extend the file depending on allocation size.

The file size is different from the allocation size. The allocation size must fall on an allocation unit boundary while the file size can be any value at or before the currently allocated size.

Reference documents: ???.
Test descriptions: "TD-21.6 FileInformation File System Test Group – AllocationInformationTest"

21.6.3 The file information must accurately update allocation size for a file but must wait to update the directory file until after the handle to the directory file is closed.

The file size starts with an allocation size of zero.

Reference documents: ???.
Test descriptions: "TD-21.6 FileInformation File System Test Group – ZeroAllocationInformationTest"

21.6.4 The file information must accurately return information on the compression used if the file is compressed.

A query is performed on two files (one that is compressed and one that is not) and a check is performed to make sure that the uncompressed file size is greater than the compressed file size.

Reference documents: ???.
Test descriptions: "TD-21.6 FileInformation File System Test Group – CompressionInformationTest"

21.6.5 The file information must accurately set the Delete Pending flag and delete these flagged files on close.

Reference documents: ???.
Test descriptions: "TD-21.6 FileInformation File System Test Group – DispositionInformationTest"

21.6.6 The file information must accurately set the end of file position and it must be less than or equal to the allocation size.

Reference documents: ???.
Test descriptions: "TD-21.6 FileInformation File System Test Group – EndOfFileInformationTest"

21.6.7 The file information must be able to accurately create hard links to a file.

Reference documents: ???.
Test descriptions: "TD-21.6 FileInformation File System Test Group – LinkInformationTest"

21.6.8 The file information must be able to accurately open a file using hard links.

The data and attributes in the file opened using the link is read and compared against the original file’s data and attributes. They must be the same.

Reference documents: ???.
Test descriptions: "TD-21.6 FileInformation File System Test Group – LinkInformationTest"

21.6.9 The file information must be able to accurately rename files/directories (except the root directory) within a volume.

Reference documents: ???.
Test descriptions: "TD-21.6 FileInformation File System Test Group – SimpleRenameInformationTest"

21.6.10 The file information system must not allow the renaming of a filename to an existing filename unless the attribute, Replace If Exists, is set.

Reference documents: ???.
Test descriptions: "TD-21.6 FileInformation File System Test Group – ConflictingRenameInformationTest"

21.6.11 The file information must be able to accurately use long names to obtain their short names (8.3 format).

Reference documents: ???.
Test descriptions: "TD-21.6 FileInformation File System Test Group – AlternateNameInformationTest"

21.6.12 The file information must be accurately read all Network open information (creation time, last access time, last write time, change time, allocation size and end of file).

Reference documents: ???.
Test descriptions: "TD-21.6 FileInformation File System Test Group – FileNetworkOpenInformationTest"

21.6.13 The file information must be accurately contain stream name, size in bytes, and allocated size in bytes for both primary data stream and alternate data streams.

Reference documents: ???.
Test descriptions: "TD-21.6 FileInformation File System Test Group – StreamInformationTest"

21.6.14 The file information must accurately set number of links and delete pending flag the same for all streams in the file.

Reference documents: ???.
Test descriptions: "TD-21.6 FileInformation File System Test Group – StreamStandardInformationTest"

21.6.15 The file information must be able to be queried and accurately set basic information (creation time, last access time, last write time, and change time) and all except creation time must change when the file is changed.

Reference documents: ???.
Test descriptions: "TD-21.6 FileInformation File System Test Group – BasicInformationTest"

21.6.16 The file information must be able to be queried and accurately contain standard information (allocation size, end of file pointer, number of links, delete pending flag, and directory value).

Reference documents: ???.
Test descriptions: "TD-21.6 FileInformation File System Test Group – StandardInformationTest"

21.6.17 The file information accurately contain a unique index value of file that does not change when the file changes.

Reference documents: ???.
Test descriptions: "TD-21.6 FileInformation File System Test Group – InternalInformationTest"

21.6.18 The file information must contain an index value that can be used to open up the file (may not be supported by all file systems).

Reference documents: ???.
Test descriptions: "TD-21.6 FileInformation File System Test Group – InternalInformationTest"

21.6.19 The file information must be able to be queried and accurately contain extended attribute size of a file.

Reference documents: ???.
Test descriptions: "TD-21.6 FileInformation File System Test Group – EaInformationTest"

21.6.20 The file information must be able to be queried and accurately contain the long filename and the length of the filename.

Reference documents: ???.
Test descriptions: "TD-21.6 FileInformation File System Test Group – NameInformationTest"


EaInformation File System Test Assertions

21.7.1 The Extended Attribute information must be accurately read all three at once, both data and labels

Reference documents: ???.
Test descriptions: "TD-21.7 EaInformation File System Test Group – FullEaInformationTest"

21.7.2 The Extended Attribute information must be accurately read using a list of Extended Attribute names

Reference documents: ???.
Test descriptions: "TD-21.7 EaInformation File System Test Group – ListEaInformationTest"

21.7.3 The Extended Attribute information must be accurately read using an index value

Reference documents: ???.
Test descriptions: "TD-21.7 EaInformation File System Test Group – IndexEaInformationTest"

21.7.4 The Extended Attribute information must be accurately specified at file creation time

Reference documents: ???.
Test descriptions: "TD-21.7 EaInformation File System Test Group – CreateEaInformationTest"

21.7.5 The Extended Attribute information must also be accurately set at times other then file creation time

Reference documents: ???.
Test descriptions: "TD-21.7 EaInformation File System Test Group – SetEaInformationTest"

21.7.6 The Extended Attribute information can be accurately read back one entry at a time

Reference documents: ???.
Test descriptions: "TD-21.7 EaInformation File System Test Group – SingleEaEntryTest"


DirectoryInformation File System Test Assertions

21.8.1 The directory information must accurately record directory for access times, end of file pointers, extended attribute sizes and allocation sizes for queried files.

Reference documents: ???.
Test descriptions: "TD-21.8 DirectoryInformation File System Test Group – FullDirectoryInformationTest"

21.8.2 The directory information, file names and file name lengths, must match file parameters.

Reference documents: ???.
Test descriptions: "TD-21.8 DirectoryInformation File System Test Group – FileNameDirectoryInformationTest"

21.8.3 The directory information must insure that file directory information last access time, last write time, and change time are updated when data is written to the file.

Reference documents: ???.
Test descriptions: "TD-21.8 DirectoryInformation File System Test Group – FileDirectoryInformationTest"

21.8.4 The directory information must insure that file directory information (two directories) last access time, last write time, and change time are updated when data is written to the file.

Reference documents: ???.
Test descriptions: "TD-21.8 DirectoryInformation File System Test Group – BothDirectoryInformationTest"


FileLocking File System Test Assertions

21.9.1 The file locking system must accurately obtain an exclusive lock on a file and a second process must fail at obtaining any lock on the file.

Reference documents: ???.
Test descriptions: "TD-21.9 FileLocking File System Test Group – LockSharedExTest"

21.9.2 The file locking system must accurately obtain a shared lock on a file and a second process must fail at obtaining an exclusive lock on the file.

Reference documents: ???.
Test descriptions: "TD-21.9 FileLocking File System Test Group – LockSharedExTest"

21.9.3 The file locking system must accurately unlock exclusive and shared byte range locks.

The process that did not lock the file must fail at attempts to unlock the locked file.

Reference documents: ???.
Test descriptions: "TD-21.9 FileLocking File System Test Group – UnlockRangeTest"

21.9.4 The file locking system must accurately fail the overlapping exclusive locks attempts on locked exclusive regions.

Reference documents: ???.
Test descriptions: "TD-21.9 FileLocking File System Test Group – LockOverlapTest"

21.9.5 The file locking system must accurately allow the overlapping of shared locks on shared locked regions.

Reference documents: ???.
Test descriptions: "TD-21.9 FileLocking File System Test Group – LockOverlapTest"

21.9.6 The file locking system must be able to accurately lock an area, both exclusive and shared, and only allow proper access.

Reference documents: ???.
Test descriptions: "TD-21.9 FileLocking File System Test Group – LockRangeTest"

21.9.7 The file locking system must be able to accurately set the file locking API to fail immediate, if a lock is currently held on the region of the file.

Reference documents: ???.
Test descriptions: "TD-21.9 FileLocking File System Test Group – LockFailImmediateTest"

21.9.8 The file locking system must be able to accurately use event handles for synchronization of multiple locking processes.

Reference documents: ???.
Test descriptions: "TD-21.9 FileLocking File System Test Group – LockOverlappedTest"

21.9.9 The file locking system must be able to accurately use file handles for locking and only allow proper access.

Reference documents: ???.
Test descriptions: "TD-21.9 FileLocking File System Test Group – UnlockAllTest"

21.9.10 The file locking system must be able to accurately use threads to close handles for unlocking files.

Reference documents: ???.
Test descriptions: "TD-21.9 FileLocking File System Test Group – UnlockRangeOnCloseTest"

21.9.11 The file locking system must be able to accurately use keys access to both shared and exclusive locked files.

Reference documents: ???.
Test descriptions: "TD-21.9 FileLocking File System Test Group – LockKeyTest"


OpLocks File System Test Assertions

21.10.1 The operating system must accurately set the batch operational lock but will release it if the file system wants it closed.

Reference documents: ???.
Test descriptions: "TD-21.10 OpLocks File System Test Group – BatchOplocksTest"

21.10.2 The operating system must accurately notify of the completion a break I/O request packet (IRP) when other IRPs are queued.

Reference documents: ???.
Test descriptions: "TD-21.10 OpLocks File System Test Group – BreakNotifyTest"

21.10.3 The operating system must accurately notify of an operational lock break being initiated when the file option is set.

Reference documents: ???.
Test descriptions: "TD-21.10 OpLocks File System Test Group – CompleteImmediatelyTest"

21.10.4 The operating system must accurately break an operational lock when a write I/O request packet is received.

Reference documents: ???.
Test descriptions: "TD-21.10 OpLocks File System Test Group – OplockReadBreakItoIITest"

21.10.5 The operating system must be able to accurately request and receive Level I operational locks which are exclusive.

Reference documents: ???.
Test descriptions: "TD-21.10 OpLocks File System Test Group – OplockLevel1Test"

21.10.6 The operating system must be able to accurately break of a Level I or Level II operational lock to none with a set information I/O request packet.

Reference documents: ???.
Test descriptions: "TD-21.10 OpLocks File System Test Group – OplockSetInfoBreakTest"

21.10.7 The operating system must break operational lock held against an open file objects before byte range file locking can be completed.

Reference documents: ???.
Test descriptions: "TD-21.10 OpLocks File System Test Group – LockOplockBreakTest"

21.10.8 The operating system must be able accurately break a level I operational lock to level II when a file is opened a second time for reading or writing.

Reference documents: ???.
Test descriptions: "TD-21.10 OpLocks File System Test Group – OplockBreakItoIITest"

21.10.9 The operating system must be able accurately break a level II operational lock when the file is opened for read and write access.

Reference documents: ???.
Test descriptions: "TD-21.10 OpLocks File System Test Group – OplockIIWriteBreakingTest"

21.10.10 The operating system must be able accurately break a level II operational lock when the file is written to.

Reference documents: ???.
Test descriptions: "TD-21.10 OpLocks File System Test Group – OplockBreakIItoNoneTest"

21.10.11 The operating system must be able accurately break Level I or Level II operational locks when the file is closed.

Reference documents: ???.
Test descriptions: "TD-21.10 OpLocks File System Test Group – OplockBreakIandIIOnCloseTest"

21.10.12 The operating system must allow multiple files to maintain a level II operational locks on a file.

Reference documents: ???.
Test descriptions: "TD-21.10 OpLocks File System Test Group – OplockRequestIITest"

21.10.13 The operating system must accurately break a level II operational locks on a file with a subsequent open.

Reference documents: ???.
Test descriptions: "TD-21.10 OpLocks File System Test Group – OplockIIOpenBreakingTest"


ChangeNotification File System Test Assertions

21.11.1 The change notification must accurately cleanup attributes in 4 seconds.

Reference documents: ???.
Test descriptions: "TD-21.11 ChangeNotification File System Test Group – NotificationCleanupAttribTest"

21.11.2 The change notification must accurately report cleanup file size in 4 seconds.

Reference documents: ???.
Test descriptions: "TD-21.11 ChangeNotification File System Test Group – NotificationCleanupFileSizeTest"

21.11.3 The change notification must accurately record the events of closing a file within 4 seconds.

Reference documents: ???.
Test descriptions: "TD-21.11 ChangeNotification File System Test Group – NotificationCloseTest"

21.11.4 The change notification must accurately record the events of deleting a file within 4 seconds.

Reference documents: ???.
Test descriptions: "TD-21.11 ChangeNotification File System Test Group – NotificationDeleteTest"

21.11.5 The change notification must accurately record the events of changing a filename (rename, create, and delete) within 4 seconds.

Reference documents: ???.
Test descriptions: "TD-21.11 ChangeNotification File System Test Group – NotificationFilenameTest"

21.11.6 The change notification must accurately record the events of a flush write within 4 seconds.

Reference documents: ???.
Test descriptions: "TD-21.11 ChangeNotification File System Test Group – NotificationFlushWriteTest"

21.11.7 The change notification must accurately record the events of attempts to open a file and directory.

Reference documents: ???.
Test descriptions: "TD-21.11 ChangeNotification File System Test Group – NotificationNonDirectoryTest"

21.11.8 The change notification must accurately record the events of any changes in the security descriptors of a file within 4 seconds.

Reference documents: ???.
Test descriptions: "TD-21.11 ChangeNotification File System Test Group – NotificationSecurityTest"

21.11.9 The change notification must support the Windows NT Security Model.

Reference documents: ???.
Test descriptions: "TD-21.11 ChangeNotification File System Test Group – NotificationSecurityTest"


DeviceControl File System Test Assertions

21.12.1 The device control system must be able to accurately open a file system related device object such as a partition or floppy device.

Reference documents: ???.
Test descriptions: "TD-21.12 DeviceControl File System Test – DeviceIOControlTest"

21.12.2 The device control system must be able to accurately get the drive geometry, using an event and asynchronous procedure call, prior to timeout.

Reference documents: ???.
Test descriptions: "TD-21.12 DeviceControl File System Test – DeviceIOControlTest"


FileSystemControlVolume File System Test Assertions

21.13.1 The file system control must accurately dismounting a volume (volume must be locked) by disconnecting a volume object from its associated file system driver.

Reference documents: ???.
Test descriptions: "TD-21.13 FileSystemControlVolume File System Test Group – ControlDismountVolumeTest"

21.13.2 The file system control must accurately use the I/O Control interface to lock a non-system volume with no open handles.

Reference documents: ???.
Test descriptions: "TD-21.13 FileSystemControlVolume File System Test Group – ControlLockVolumeTest"

21.13.3 The file system control must accurately use the I/O Control interface to unlock a volume.

Reference documents: ???.
Test descriptions: "TD-21.13 FileSystemControlVolume File System Test Group – ControlUnlockVolumeTest"

21.13.4 The file system control must accurately check to see if a volume is mounted.

Reference documents: ???.
Test descriptions: "TD-21.13 FileSystemControlVolume File System Test Group – VolumeMountedTest"

21.13.5 The file system control must accurately marks a volume as permanently dirty when a corruption is detected in the meta data.

Reference documents: ???.
Test descriptions: "TD-21.13 FileSystemControlVolume File System Test Group – MountedDirtyTest"

21.13.6 The file system control must accurately search for all the volumes mounted on the same real device, and marks them all bad.

Reference documents: ???.
Test descriptions: "TD-21.13 FileSystemControlVolume File System Test Group – InvalidateVolumesTest"

21.13.7 The file system control must accurately recognize when removable media is replaced with new media or changed media.

Reference documents: ???.
Test descriptions: "TD-21.13 FileSystemControlVolume File System Test Group – MountVerifyVolumesTest"


FileSystemControlGeneral File System Test Assertions

21.14.1 The file system control must accurately use retrieval pointers for use later in when writing the crash dump paging file.

Reference documents: ???.
Test descriptions: "TD-21.14 FileSystemControlGeneral File System Test Group – QueryRetrievalPointersTest"

21.14.2 The file system control must accurately update retrieval pointers when file size changes.

Reference documents: ???.
Test descriptions: "TD-21.14 FileSystemControlGeneral File System Test Group – GetRetrievalPointersTest"

21.14.3 The file system control must accurately compress individual files.

Reference documents: ???.
Test descriptions: "TD-21.14 FileSystemControlGeneral File System Test Group – SetCompressionTest"

21.14.4 The file system control must accurately retrieve volume statistics, filesystem performance counters.

Reference documents: ???.
Test descriptions: "TD-21.14 FileSystemControlGeneral File System Test Group – GetStatisticsTest"

21.14.5 The file system control (Fat Compatible Volumes only) must accurately check a pathname for valid characters, leading backslashes, and for wildcards.

Reference documents: ???.
Test descriptions: "TD-21.14 FileSystemControlGeneral File System Test Group – PathNameValidTest"

21.14.6 The file system control must accurately exercise the FSCT, ensure volume bitmap is accurately mapping used and unused clusters.

Reference documents: ???.
Test descriptions: "TD-21.14 FileSystemControlGeneral File System Test Group – GetVolumeBitmapTest"

21.14.7 The file system control must accurately move the logical clusters used by a file to new logical clusters on the volume.

Reference documents: ???.
Test descriptions: "TD-21.14 FileSystemControlGeneral File System Test Group – MoveFileTest"

21.14.8 The file system control must not allow a DASD handle to be used to read/write beyond the end of the volume.

Reference documents: ???.
Test descriptions: "TD-21.14 FileSystemControlGeneral File System Test Group – AllowExtendedDASDTest"


ReadWrite File System Test Assertions

21.15.1 The file system must be able to accurately read from and write to files.

Reference documents: ???.
Test descriptions: "TD-21.15 ReadWrite File System Test Group – ReadWriteTest"

21.15.2 The file system must be able to accurately maintain cache coherency for open files.

Reference documents: ???.
Test descriptions: "TD-21.15 ReadWrite File System Test Group – ReadWriteCoherencyTest"

21.15.3 The file system must be able to accurately open files with write through caching.

Reference documents: ???.
Test descriptions: "TD-21.15 ReadWrite File System Test Group – WriteThroughTest"

21.15.4 The file system must be able to accurately open files with write through caching using both synchronous and asynchronous file handles.

Reference documents: ???.
Test descriptions: "TD-21.15 ReadWrite File System Test Group – WriteThroughSyncTest"

21.15.5 The file system must be able to accurately append data to an open file that was opened with the append data access flag set.

Reference documents: ???.
Test descriptions: "TD-21.15 ReadWrite File System Test Group – AppendDataTest"

21.15.6 The file system must be able to accurately specify the byte offset into the file and verified using the read function.

Reference documents: ???.
Test descriptions: "TD-21.15 ReadWrite File System Test Group – AtomicSeekReadTest"

21.15.7 The file system should not update the file offset when using a zero byte length IO operation.

Reference documents: ???.
Test descriptions: "TD-21.15 ReadWrite File System Test Group – ZeroLengthIOTest"

21.15.8 The file system must be able to accurately use the Read and Write functions that specify byte offsets and a byte lengths.

Reference documents: ???.
Test descriptions: "TD-21.15 ReadWrite File System Test Group – ReadWriteRangeTest"

21.15.9 The file system must be able to accurately perform asynchronous IO with the Read and Write functions.

Reference documents: ???.
Test descriptions: "TD-21.15 ReadWrite File System Test Group – EventAsyncIOTest"

21.15.10 The file system must be able to accurately perform asynchronous IO using APC with the Read and Write functions.

Reference documents: ???.
Test descriptions: "TD-21.15 ReadWrite File System Test Group – APCSynchRWTest"

21.15.11 The file system must be able to accurately zero the contents of files, for security purposes when the file is extended either by setting the end of file pointer through the NT set function or by writing beyond the end of the file.

Reference documents: ???.
Test descriptions: "TD-21.15 ReadWrite File System Test Group – ZeroOnExtendTest"


SectionCaching File System Test Assertions

21.16.1 The file system must be able to accurately extend files when a user mapping exists with a Set Information File and the new extended region should be initialized with 0's.

Reference documents: ???.
Test descriptions: "TD-21.16 SectionCaching File System Test Group – ExtendingWithUserMappingTest"

21.16.2 The file system must be able to accurately flush file buffers for files with the FILE_ATTRIBUTE_TEMPORARY flag set.

The number of bytes written to the block device, the end of file pointer, and the last write time should be updated from the flush.

Reference documents: ???.
Test descriptions: "TD-21.16 SectionCaching File System Test Group – FlushBuffersTest"

21.16.3 The file system must be able to accurately flush buffers of the root directory and obtain statistics

This requires Windows 2000. The statistics are the number of bytes written to the block device, the end of file pointer, the last write time for all files.

Reference documents: ???.
Test descriptions: "TD-21.16 SectionCaching File System Test Group – FlushBuffersRootTest"

21.16.4 The file system must be able to accurately flush buffers on the volume handle and obtain statistics.

The volume statistics are the number of bytes written to the block device, the end of file pointer, and last write time.

Reference documents: ???.
Test descriptions: "TD-21.16 SectionCaching File System Test Group – FlushBuffersVolumeTest"

21.16.5 The file system must be able to accurately create a user mapped section with an open file handle and still be maintained after the handle is closed.

Reference documents: ???.
Test descriptions: "TD-21.16 SectionCaching File System Test Group – MaintainSectionMappingTest"

21.16.6 The file system must be able to accurately maintain coherency between the image section and the data section.

Reference documents: ???.
Test descriptions: "TD-21.16 SectionCaching File System Test Group – DataImageCoherencyTest"

21.16.7 The file system will not supercede or overwrite files when a view on a user mapping exists.

Reference documents: ???.
Test descriptions: "TD-21.16 SectionCaching File System Test Group – ExistingUserMappingTest"

21.16.8 The file system will not truncate files when user mapping exists.

Reference documents: ???.
Test descriptions: "TD-21.16 SectionCaching File System Test Group – TruncateWithUserMappingTest"


Security File System Test Assertions

21.17.1 The NTFS file system must be able to accurately set ownership of files.

Reference documents: ???.
Test descriptions: "TD-21.17 Security File System Test Group – SetOwnerSecurityTest"

21.17.2 The NTFS file system must be able to accurately set the security DACL to only allow read operations by the Administrator.

Reference documents: ???.
Test descriptions: "TD-21.17 Security File System Test Group – SetDaclSecurityTest"

21.17.3 The NTFS file system must be able to accurately set a file’s the Group SID Security Group SID files and directories.

Reference documents: ???.
Test descriptions: "TD-21.17 Security File System Test Group – SetGroupSecurityTest"

21.17.4 The NTFS file system must be able to accurately set the SACL list to allow audit operations to be performed on files.

Reference documents: ???.
Test descriptions: "TD-21.17 Security File System Test Group – SetSaclSecurityTest"

21.17.5 The NTFS file system must be able to accurately audit the deletion of the file when set in the SACL.

Reference documents: ???.
Test descriptions: "TD-21.17 Security File System Test Group – AuditDelSecurityTest"

21.17.6 The NTFS file system must be able to accurately audit the change of security permissions (the DACL) when set in the SACL.

Reference documents: ???.
Test descriptions: "TD-21.17 Security File System Test Group – AuditPermSecurityTest"

21.17.7 The NTFS file system must be able to accurately audit the change of the owner of files when set in the SACL.

Reference documents: ???.
Test descriptions: "TD-21.17 Security File System Test Group – AuditOwnerSecurityTest"

21.17.8 The NTFS file system must be able to accurately Bypass Traverse Checking for all users on the system.

Reference documents: ???.
Test descriptions: "TD-21.17 Security File System Test Group – DirectoryTraverseTest"


ObjectID File System Test Assertions

These assertions only apply to file systems that support Object ID’s.

21.18.1 The Object IDs must be able to be used to accurately retrieve volume's Object ID.

Reference documents: ???.
Test descriptions: "TD-21.18 ObjectID File System Test Group – GetObjectIDVolumeTest"

21.18.2 The Object IDs must be able to be used to accurately retrieve the full path of a file or directory.

Reference documents: ???.
Test descriptions: "TD-21.18 ObjectID File System Test Group – NameInformationExTest"

21.18.3 The Object IDs must be able to be used to accurately open a file or directory.

Reference documents: ???.
Test descriptions: "TD-21.18 ObjectID File System Test Group – ObjectOpenByIDTest"

21.18.4 The Object IDs must be able to be accurately added to and removed from object index.

Reference documents: ???.
Test descriptions: "TD-21.18 ObjectID File System Test Group – NotificationObjectIDRemovedTest"

21.18.5 The Object IDs must be able to be accurately set (extended information portion) for a file or directory.

Reference documents: ???.
Test descriptions: "TD-21.18 ObjectID File System Test Group – SetExtendedObjectIDTest"

21.18.6 The Object IDs must be able to accurately be set on a files and directories provided that BACKUP/RESTORE privileges are enabled.

Reference documents: ???.
Test descriptions: "TD-21.18 ObjectID File System Test Group – SetObjectIDTest"

21.18.7 The Object IDs must be able to accurately be set on a volume provided that a file or directory does not already have the same Object ID.

Reference documents: ???.
Test descriptions: "TD-21.18 ObjectID File System Test Group – SetObjectIDVolumeTest"

21.18.8 The Object IDs must be able to accurately be tunneled for a file or directory.

Reference documents: ???.
Test descriptions: "TD-21.18 ObjectID File System Test Group – TunnelObjectIDTest"

21.18.9 The Object IDs must be able to accurately report on the tunneling process (object ID added, removed, and restored).

Reference documents: ???.
Test descriptions: "TD-21.18 ObjectID File System Test Group – NotificationObjectIDNotTunnelledTest"

21.18.10 The Object IDs must be unique for each file and directory on the volume and can not be reset.

Reference documents: ???.
Test descriptions: "TD-21.18 ObjectID File System Test Group – SetUniqueObjectIDNameCollisionTest"

21.18.11 The Object IDs must be unique for each file and directory (duplicate ID’s are not allowed).

Reference documents: ???.
Test descriptions: "TD-21.18 ObjectID File System Test Group – SetUniqueObjectIDDuplicateNameTest"

21.18.12 The Object IDs must be able to accurately report on the adding of to an object index.

Reference documents: ???.
Test descriptions: "TD-21.18 ObjectID File System Test Group – NotificationObjectIDAddedTest"

21.18.13 The Object IDs must be able to accurately be retrieved when existing or be generated new for a file or directory.

Reference documents: ???.
Test descriptions: "TD-21.18 ObjectID File System Test Group – CreateOrGetObjectIDTest"

21.18.14 The Object IDs must be able to accurately report on the inability to be restored from the tunnel cache for duplicate object IDs or if the destination file already has an object ID.

Reference documents: ???.
Test descriptions: "TD-21.18 ObjectID File System Test Group – NotificationObjectIDTunnelledCollisionTest"

21.18.15 The Object IDs must be able to accurately be removed from a file or directory, provided the handle is opened with RESTORE intent and WRITE access.

Reference documents: ???.
Test descriptions: "TD-21.18 ObjectID File System Test Group – DeleteObjectIDTest"

21.18.16 The Object IDs must be able to accurately report on being removed from an object index.

Reference documents: ???.
Test descriptions: "TD-21.18 ObjectID File System Test Group – NotificationObjectIDDeletedTest"

21.18.17 The Object IDs must be able to accurately be queried for volume structure.

Reference documents: ???.
Test descriptions: "TD-21.18 ObjectID File System Test Group – EnumObjectIDTest"

21.18.18 The Object IDs must be able to accurately retrieved for files and directories.

Reference documents: ???.
Test descriptions: "TD-21.18 ObjectID File System Test Group – GetObjectIDTest"


Extended Security File System Test Assertions

21.19.1 The File System must be able to accurately copy a directory that contains a name graft.

Reference documents: ???.
Test descriptions: "TD-21.19 MountPoints File System Test Group – CreateDirectoryExDirectoryTest"

21.19.2 The File System must be able to accurately create a volume mount point and then copy the directory containing the point.

Reference documents: ???.
Test descriptions: "TD-21.19 MountPoints File System Test Group – CreateDirectoryExVolumeTest"

21.19.3 The File System must be able to accurately link a lower child directory to its immediate parent and then traverse the self-referencing directory tree up to 16 times before an error status is returned

Reference documents: ???.
Test descriptions: "TD-21.19 MountPoints File System Test Group – DirectoryCycleOnReparseTest"

21.19.4 The File System must be able to accurately reparse a name on a directory and then provide access through the reparse point.

Reference documents: ???.
Test descriptions: "TD-21.19 MountPoints File System Test Group – DirectoryGraftTest"

21.19.5 The File System must be able to accurately reparse a name on a directory and show that name grafting requires an empty directory.

Reference documents: ???.
Test descriptions: "TD-21.19 MountPoints File System Test Group – DirectoryGraftEmptyFileTest"

21.19.6 The File System must not be able to perform name grafting on a directory that contains a subdirectory.

Reference documents: ???.
Test descriptions: "TD-21.19 MountPoints File System Test Group – DirectoryGraftEmptyTest"

21.19.7 The File System must not be able to perform name grafting on a directory using a handle to a named data stream on a directory.

Reference documents: ???.
Test descriptions: "TD-21.19 MountPoints File System Test Group – DirectoryGraftEmptyStreamTest"

21.19.8 The File System must not be able to perform name grafting on a file.

Reference documents: ???.
Test descriptions: "TD-21.19 MountPoints File System Test Group – FileGraftTest"

21.19.9 The File System must not be able to perform name grafting on a named data stream of a file.

Reference documents: ???.
Test descriptions: "TD-21.19 MountPoints File System Test Group – FileGraftStreamTest"

21.19.10 The File System must be able to accurately create a volume mount point and then exercise it.

Reference documents: ???.
Test descriptions: "TD-21.19 MountPoints File System Test Group – LocalMountPointTest"


ReparsePoints File System Test Assertions

21.20.1 The File System must be able to only set a reparse point on an empty directory.

Reference documents: ???.
Test descriptions: "TD-21.20 ReparsePoints File System Test Group – SetPointDirectoryNotEmptyTest"

21.20.2 The File System must be able to accurately retrieve the reparse tag for a given file or directory with a reparse point.

Reference documents: ???.
Test descriptions: "TD-21.20 ReparsePoints File System Test Group – EnumReparsePointsTest"

21.20.3 The File System must be able to accurately obtain BASIC INFORMATION from a file or directory with a reparse point.

Reference documents: ???.
Test descriptions: "TD-21.20 ReparsePoints File System Test Group – FileAttributeReparsePointTest"

21.20.4 The File System must be able to accurately get a reparse point set on files and directories while using an output buffer length argument.

Reference documents: ???.
Test descriptions: "TD-21.20 ReparsePoints File System Test Group – GetPointBufferSmallTest"

21.20.5 The File System must be able to accurately get a reparse point set on files and directories only if a prior reparse point was set.

Reference documents: ???.
Test descriptions: "TD-21.20 ReparsePoints File System Test Group – GetPointNotReparseTest"

21.20.6 The File System must be able to accurately get a reparse point set on files and directories only if the reparse buffer argument is not null.

Reference documents: ???.
Test descriptions: "TD-21.20 ReparsePoints File System Test Group – GetPointInvalidUserBufferTest"

21.20.7 The File System must be able to accurately get a reparse point set on files and directories using only valid buffer arguments.

Reference documents: ???.
Test descriptions: "TD-21.20 ReparsePoints File System Test Group – GetPointInvalidParamTest"

21.20.8 The File System must accurately report on an invalid buffer size when using a NULL reparse buffer argument.

Reference documents: ???.
Test descriptions: "TD-21.20 ReparsePoints File System Test Group – SetPointInvalidBufferSizeTest"

21.20.9 The File System must accurately report on an invalid parameter when attempting to set a reparse point on a volume or by using an output buffer argument.

Reference documents: ???.
Test descriptions: "TD-21.20 ReparsePoints File System Test Group – SetPointInvalidParamTest"

21.20.10 The File System must accurately report on an invalid IO reparse data when the input buffer length argument is greater than the max buffer size, the input buffer length argument different than the reparse data buffer length, or the GUID is equal to NULL (if ISV reparse tag).

Reference documents: ???.
Test descriptions: "TD-21.20 ReparsePoints File System Test Group – SetPointIoReparseDataInvalidTest"

21.20.11 The File System must accurately use volume index to wait for reparse point additions, when supported.

Reference documents: ???.
Test descriptions: "TD-21.20 ReparsePoints File System Test Group – ChangeNotificationReparseTest"

21.20.12 The File System must accurately open files and directories with reparse points, which inhibits reparse behavior of the file or directory.

Reference documents: ???.
Test descriptions: "TD-21.20 ReparsePoints File System Test Group – OpenReparsePointTest"

21.20.13 The File System must accurately query files and directories, with reparse points, for full attributes.

Reference documents: ???.
Test descriptions: "TD-21.20 ReparsePoints File System Test Group – QueryFullAttributesReparseTest"

21.20.14 The File System must accurately query files and directories, with reparse points, for attributes tag information.

Reference documents: ???.
Test descriptions: "TD-21.20 ReparsePoints File System Test Group – QueryFileAttributeTagInfoTest"

21.20.15 The File System must accurately set a reparse point on files and directories and check for valid behavior.

Reference documents: ???.
Test descriptions: "TD-21.20 ReparsePoints File System Test Group – SetPointIoReparseTagInvalidTest"

21.20.16 The File System must not overwrite file and directory reparse tags with different reparse tags.

Reference documents: ???.
Test descriptions: "TD-21.20 ReparsePoints File System Test Group – SetPointIoReparseTagMismatchTest"

21.20.17 The File System must not delete files and directories with a reparse point using normal deletion semantics.

Reference documents: ???.
Test descriptions: "TD-21.20 ReparsePoints File System Test Group – DeleteFileDirReparsePointTest"

21.20.18 The File System must not be able to delete reparse points from files and directories without write access.

Reference documents: ???.
Test descriptions: "TD-21.20 ReparsePoints File System Test Group – DelPointAccessDeniedTest"

21.20.19 The File System must be able to accurately delete reparse points from files and directories using Globally unique identifiers.

Reference documents: ???.
Test descriptions: "TD-21.20 ReparsePoints File System Test Group – DelPointAttributeConflictTest"

21.20.20 The File System must not be able to delete reparse points from files and directories with NULL reparse buffers.

Reference documents: ???.
Test descriptions: "TD-21.20 ReparsePoints File System Test Group – DelPointInvalidBufferSizeTest"

21.20.21 The File System must not be able to delete reparse points from files and directories with an input buffer length argument greater than reparse data buffer header size, an input buffer data length argument different than zero, or a buffer size argument different than the GUID header size (if ISV reparse tag).

Reference documents: ???.
Test descriptions: "TD-21.20 ReparsePoints File System Test Group – DelPointIoReparseDataInvalidTest"

21.20.22 The File System must not be able to delete reparse points from files and directories by using a reparse point on a volume or by using an output buffer argument.

Reference documents: ???.
Test descriptions: "TD-21.20 ReparsePoints File System Test Group – DelPointInvalidParmTest"

21.20.23 The File System must not be able to delete reparse points from files and directories by using a reparse tag equal to IO reparse tag reserved-one or IO reparse tag reserved-zero.

Reference documents: ???.
Test descriptions: "TD-21.20 ReparsePoints File System Test Group – DelPointIoReparseTagInvalidTest"

21.20.24 The File System must not be able to delete reparse points from files and directories by using a different reparse tag.

Reference documents: ???.
Test descriptions: "TD-21.20 ReparsePoints File System Test Group – DelPointIoReparseTagMismatchTest"

21.20.25 The File System must not be able to delete reparse points from files and directories which do not have prior reparse points set.

Reference documents: ???.
Test descriptions: "TD-21.20 ReparsePoints File System Test Group – DelPointNotReparseTest"

21.20.26 The File System must not be able to delete reparse points from files and directories which have extended attributes.

Reference documents: ???.
Test descriptions: "TD-21.20 ReparsePoints File System Test Group – SetPointEASNotSupportedTest"

21.20.27 The File System must not be able to set reparse points on files and directories with no WRITE access.

Reference documents: ???.
Test descriptions: "TD-21.20 ReparsePoints File System Test Group – SetPointAccessDeniedTest"

21.20.28 The File System must not be able to set reparse points from files and directories with mismatched GUID.

Reference documents: ???.
Test descriptions: "TD-21.20 ReparsePoints File System Test Group – SetPointAttributeConflictTest"


SparseFiles File System Test Assertions

21.21.1 The file system must be able to accurately move sparse files to sparse regions over an already committed LCN range.

Reference documents: ???.
Test descriptions: "TD-21.21 SparseFiles File System Test Group – SparseMoveFileTest"

21.21.2 The file system must be able to accurately have sparse and nonsparse data streams on files.

Reference documents: ???.
Test descriptions: "TD-21.21 SparseFiles File System Test Group – SparseNonSparseStreamTest"

21.21.3 The file system must be able to accurately set a range of a non-sparse files to zero.

Reference documents: ???.
Test descriptions: "TD-21.21 SparseFiles File System Test Group – NonSparseZeroDataTest"

21.21.4 The file system must accurately change a sparse file to a nonsparse file when it is a overwritten.

Reference documents: ???.
Test descriptions: "TD-21.21 SparseFiles File System Test Group – ResetSparseAttrOverwriteTest"

21.21.5 The file system must accurately use FSCTL_SET_ZERO_DATA to reduce the allocation size of sparse files.

Reference documents: ???.
Test descriptions: "TD-21.21 SparseFiles File System Test Group – SparseZeroDataAllocTest"

21.21.6 The file system must be able to accurately set zero data to a range in a sparse files.

Reference documents: ???.
Test descriptions: "TD-21.21 SparseFiles File System Test Group – SparseZeroDataTest"

21.21.7 The file system must be able to accurately change allocation size of sparse files by writing data to the data stream.

Reference documents: ???.
Test descriptions: "TD-21.21 SparseFiles File System Test Group – SparseStreamTest"

21.21.8 The file system must be able to accurately change allocation size of sparse directories by writing data to the data stream.

Reference documents: ???.
Test descriptions: "TD-21.21 SparseFiles File System Test Group – SparseStreamDirTest"

21.21.9 The file system must accurately change a sparse file to a nonsparse file when the file is superseded.

Reference documents: ???.
Test descriptions: "TD-21.21 SparseFiles File System Test Group – ResetSparseAttrSupersedeTest"

21.21.10 The file system must accurately reduce the allocation size of the sparse file by setting the data to zero.

Reference documents: ???.
Test descriptions: "TD-21.21 SparseFiles File System Test Group – SparseAllocatedRangesTest"

21.21.11 The file system must be able to accurately set the sparse attribute flag depending on a stream by stream basis.

Reference documents: ???.
Test descriptions: "TD-21.21 SparseFiles File System Test Group – FileInformationSparseAttrTest"

21.21.12 The file system must be able to accurately compress sparse files.

Reference documents: ???.
Test descriptions: "TD-21.21 SparseFiles File System Test Group – SparseCompressedStreamTest"

21.21.13 The file system must be able to accurately create a user mapped section and view on sparse files.

Reference documents: ???.
Test descriptions: "TD-21.21 SparseFiles File System Test Group – SparseUserMappedSectionTest"

21.21.14 The file system must accurately report if there is a user mapped section and view on sparse files.

Reference documents: ???.
Test descriptions: "TD-21.21 SparseFiles File System Test Group – SparseUserMapZeroTest"


ForcedDismount File System Test Assertions

21.23.1 The file system must be able to accurately dismount on an active volume, i.e., with opened file handles, unless the volume is the system drive or it is exclusive-locked.

Reference documents: ???.
Test descriptions: "TD-21.23 ForcedDismount File System Test"


Encryption File System Test Assertions

21.24.1 The encryption driver must be able to accurately encrypt a file using the NtCreateFile API with the FILE_ATTRIBUTE_ENCRYPTED flag specified.

Reference documents: ???.
Test descriptions: "TD-21.24 Encryption File System Test Group – SuperOverEncryptedTest"

21.24.2 The encryption driver must not allow an encrypt a file to be read without the correct security token and will warn user that access is denied.

Reference documents: ???.
Test descriptions: "TD-21.24 Encryption File System Test Group – SuperOverEncryptedTest"

21.24.3 The encryption driver must be able to accurately read and write raw encrypted data.

Reference documents: ???.
Test descriptions: "TD-21.24 Encryption File System Test Group – ReadWriteRawEncryptedTest"

21.24.4 The encryption driver must be able to accurately remove a specified user from a list of users that are permitted to access a specified encrypted file unless it is the last user.

Reference documents: ???.
Test descriptions: "TD-21.24 Encryption File System Test Group – RemoveUsersEncryptionTest"

21.24.5 The encryption driver must be able to accurately retrieve a list of users that are permitted to access a specified encrypted file.

Reference documents: ???.
Test descriptions: "TD-21.24 Encryption File System Test Group – QueryUsersEncryptionTest"

21.24.6 The encryption driver must be able to accurately retrieve a list of users that are permitted to recover a specified encrypted file..

Reference documents: ???.
Test descriptions: "TD-21.24 Encryption File System Test Group – QueryRecoveryAgentsTest"

21.24.7 The encryption driver must be able to accurately recover a file using a recovery agent that is not the file owner.

Reference documents: ???.
Test descriptions: "TD-21.24 Encryption File System Test Group – QueryRecoveryAgentsTest"

21.24.8 The encryption driver must be able to accurately encrypt and then decrypt a file.

Reference documents: ???.
Test descriptions: "TD-21.24 Encryption File System Test Group – EncryptDecryptFileTest"

21.24.9 The encryption driver must be able to accurately encrypt and then decrypt a directory.

Reference documents: ???.
Test descriptions: "TD-21.24 Encryption File System Test Group – EncryptDecryptDirTest"

21.24.10 The encryption driver must be able to accurately check the encryption status attributes of files and directories.

Reference documents: ???.
Test descriptions: "TD-21.24 Encryption File System Test Group – EncryptionStatusTest"

21.24.11 The encryption driver must be able to accurately uncompress a compressed and encrypted file when a call to the file is made and the attributes on the file should then show encryption only.

Reference documents: ???.
Test descriptions: "TD-21.24 Encryption File System Test Group – EncryptionDecompressionTest"

21.24.12 The encryption driver must be able to accurately encrypt a compressed file by decompressing the file, applying the encryption and then recompressing the file.

Reference documents: ???.
Test descriptions: "TD-21.24 Encryption File System Test Group – EncryptionCompressionTest"

21.24.13 The encryption driver must be able to accurately get the encryption status of a file or directory.

Reference documents: ???.
Test descriptions: "TD-21.24 Encryption File System Test Group – EncryptionAttributeTest"

21.24.14 The encryption driver must be able to accurately encrypt a non-empty directory and all the files in it.

Reference documents: ???.
Test descriptions: "TD-21.24 Encryption File System Test Group – DirectoryEncryptedSuperOverTest"

21.24.15 The encryption driver must be able to accurately encrypt files created in an encrypted directory.

Reference documents: ???.
Test descriptions: "TD-21.24 Encryption File System Test Group – DirectoryEncryptedNewFileTest"

21.24.16 The encryption driver must be able to accurately encrypt directories created in an encrypted directory.

Reference documents: ???.
Test descriptions: "TD-21.24 Encryption File System Test Group – DirectoryEncryptedNewDirTest"

21.24.17 The encryption driver must be able to accurately encrypt files that have the FILE_ATTRIBUTE_ENCRYPTED flag set.

Reference documents: ???.
Test descriptions: "TD-21.24 Encryption File System Test Group – CreateEncryptedFileTest"

21.24.18 The encryption driver must be able to accurately encrypt directories that have the FILE_ATTRIBUTE_ENCRYPTED flag set.

Reference documents: ???.
Test descriptions: "TD-21.24 Encryption File System Test Group – CreateEncryptedDirTest"

21.24.19 The encryption driver must be able to accurately add a user to the list of users that are permitted to access a specified encrypted file

Reference documents: ???.
Test descriptions: "TD-21.24 Encryption File System Test Group – CreateEncryptedDirTest"


Quotas File System Test Assertions

21.25.1 The file system must accurately track quota usage and quota enforcement.

Reference documents: ???.
Test descriptions: "TD-21.25 Quotas File System Test Group – VolumeQuotaEnforceTest"

21.25.2 The file system must be able to accurately use the FILE_VC_QUOTA_NONE flag to disable quota usage tracking.

Reference documents: ???.
Test descriptions: "TD-21.25 Quotas File System Test Group – VolumeQuotaNoneTest"

21.25.3 The file system must be able to accurately query quota settings and set to the volume quota index.

Reference documents: ???.
Test descriptions: "TD-21.25 Quotas File System Test Group – QuerySetQueryQuotaTest"

21.25.4 The file system must be able to accurately enable disk Quota tracking, whereby quota usage changes are tracked, but no quota enforcement is done.

Reference documents: ???.
Test descriptions: "TD-21.25 Quotas File System Test Group – VolumeQuotaTrackTest"

21.25.5 The file system must accurately generate the correct event when the user quota exceeds the limit.

Reference documents: ???.
Test descriptions: "TD-21.25 Quotas File System Test Group – VolumeQuotaUserLimitTest"

21.25.6 The file system must accurately ignore quota events when the FILE_VC_LOG_VOLUME_THRESHOLD flag is set.

Reference documents: ???.
Test descriptions: "TD-21.25 Quotas File System Test Group – VolumeQuotaLimitTest"

21.25.7 The file system must accurately ignore quota events when the FILE_VC_LOG_VOLUME_THRESHOLD flag is set.

Reference documents: ???.
Test descriptions: "TD-21.25 Quotas File System Test Group – VolumeQuotaThresholdTest"


LinkTracking File System Test Assertions

21.26.1 The IShellLink interface must accurately create and resolve the object of a link that has moved on the same volume.

Reference documents: ???.
Test descriptions: "TD-21.26 LinkTracking File System Test Group – IshellLinkResolveTest"

21.26.2 The IShellLink interface must accurately create and resolve the object of a link that has moved on a different volume (on the same system).

Reference documents: ???.
Test descriptions: "TD-21.26 LinkTracking File System Test Group – IShellLinkResolveVolumeTest"


ChangeJournal File System Test Assertions

21.27.1 The change journal must accurately record the event due to creating a new file and the create USN event must exist in the change log.

Reference documents: ???.
Test descriptions: "TD-21.27 ChangeJournal File System Test Group – ChangeJournalTest"

21.27.2 The change journal must accurately record the event due to writing new data at end of file and the write should complete successfully.

Reference documents: ???.
Test descriptions: "TD-21.27 ChangeJournal File System Test Group – ChangeJournalTest"

21.27.3 The change journal must accurately record the event due to setting end of file information and the truncate operation should complete successfully.

Reference documents: ???.
Test descriptions: "TD-21.27 ChangeJournal File System Test Group – ChangeJournalTest"

21.27.4 The change journal must accurately record the event due to changing extended attributes.

Reference documents: ???.
Test descriptions: "TD-21.27 ChangeJournal File System Test Group – ChangeJournalTest"

21.27.5 The change journal must accurately record the event due to setting reparse point on a file.

Reference documents: ???.
Test descriptions: "TD-21.27 ChangeJournal File System Test Group – ChangeJournalTest"

21.27.6 The change journal must be able to creating a USN event in the change log, and increase size its size.

Reference documents: ???.
Test descriptions: "TD-21.27 ChangeJournal File System Test Group – CreateChangeJournalTest"

21.27.7 The change journal must be able to reset all USN values to zero, and remove journal file from disk.

Reference documents: ???.
Test descriptions: "TD-21.27 ChangeJournal File System Test Group – DeleteChangeJournalTest"

21.27.8 The change journal must accurately create an enumeration that lists the change journal entries between two specified boundaries.

Reference documents: ???.
Test descriptions: "TD-21.27 ChangeJournal File System Test Group – EnumMftUsnDataTest"

21.27.9 The change journal be able to locate the create USN event in the change log.

Reference documents: ???.
Test descriptions: "TD-21.27 ChangeJournal File System Test Group – EnumMftUsnDataTest"

21.27.10 The change journal must accurately return information about the selected item in the USN journal.

Reference documents: ???.
Test descriptions: "TD-21.27 ChangeJournal File System Test Group – QueryChangeJournalTest"

21.27.11 The change journal be able to locate the selected USN records in the change log.

Reference documents: ???.
Test descriptions: "TD-21.27 ChangeJournal File System Test Group – ReadChangeJournalTest"

21.27.12 The change journal must accurately read and return the last file or directory USN event location in the change log.

Reference documents: ???.
Test descriptions: "TD-21.27 ChangeJournal File System Test Group – ReadFileChangeJournalTest"

21.27.13 The change journal must accurately change the size of a USN journal.

Reference documents: ???.
Test descriptions: "TD-21.27 ChangeJournal File System Test Group – ChangeJournalTrimTest"

21.27.14 The change journal must accurately report the allocation size.

Reference documents: ???.
Test descriptions: "TD-21.27 ChangeJournal File System Test Group – ChangeJournalTrimTest"

21.27.15 The change journal must accurately write a close USN record for the current file, and return its USN.

Reference documents: ???.
Test descriptions: "TD-21.27 ChangeJournal File System Test Group – WriteCloseRecordTest"


StreamEnhancements File Test Assertions

21.28.1 The named streams in a file must be able to be accurately created and queried.

Reference documents: ???.
Test descriptions: "TD-21.28 StreamEnhancements File System Test Group – StreamQueryNamesTest"

21.28.2 The named streams in a file must be able to be accurately opened and renamed.

Reference documents: ???.
Test descriptions: "TD-21.28 StreamEnhancements File System Test Group – StreamRenameTest"

21.28.3 The named streams in a file must be able to accurately notify of a file size change.

Reference documents: ???.
Test descriptions: "TD-21.28 StreamEnhancements File System Test Group – StreamNotifySizeTest"

21.28.4 The named streams in a file must be able to accurately notify of a data change.

Reference documents: ???.
Test descriptions: "TD-21.28 StreamEnhancements File System Test Group – StreamNotifyWriteTest"

21.28.5 The named streams in a file must be able to accurately notify of a change to names on a file or directory.

Reference documents: ???.
Test descriptions: "TD-21.28 StreamEnhancements File System Test Group – StreamNotifyNameTest"

21.28.6 The named streams in a file must be able to be accurately opened and marked for deletion (and deleted on cleanup).

Reference documents: ???.
Test descriptions: "TD-21.28 StreamEnhancements File System Test Group – StreamDeleteTest"


DefragEnhancements File System Test Assertions

21.29.1 The Defrag Enhancement system must be able to accurately move directories, a cluster at a time, using directory handles, retrieval pointers, and volume handles.

Reference documents: ???.
Test descriptions: "TD-21.29 DefragEnhancements File System Test Group – MoveDirTest"

21.29.2 The Defrag Enhancement system must be able to accurately record move system view (security, quota, reparse, object ID) directories, a cluster at a time, using directory handles, retrieval pointers, and volume handles.

Reference documents: ???.
Test descriptions: "TD-21.29 DefragEnhancements File System Test Group – MoveViewTest"


I/O Stress-av test

This test stresses the I/O subsystem and launches driver verifier from within the stress engine.

Note: Ensure that the anti-virus application is scanning and is set to delete, or quarantine virus files.

Run Time: 72 hours

Log file name: iostressrun-av.log

Operating system: Windows 2000, Server SP1

Test assertion: Chapter 21

Related links

Running the I/O Stress-AV test


Anti-virus File System Filter Test Descriptions

This section describes the anti-virus file system filter tests. Test descriptions include a description of each test, set up requirements, and results interpretations. Each named test is referenced by various assertions at the beginning of this chapter.


TD-21.1 Installable File Systems Test Suite

Microsoft Installable File System Test for Windows NT / 2000

The Installable File System Test, IFS Test, was designed to test the compliance of installable file systems in the Microsoft Windows NT 4.0 and Windows 2000 Operating Systems. Its intended audience include file system developers who want to verify that their drivers comply with a standard set of expected functionality. The IFS Test is run from the command line with several options specified. Each test that is run will return a test status block whether the test has passed or failed, or the test results can be viewed in NTLOG . The IFS Test was written with the following design goals in mind:

  • Subsystem Independence
  • Synthetic Operation Distinction
  • Separate Test Groups
  • Asynchronous / Synchronous Testing
  • Fault Identification
  • Coverage
  • Extensible
  • Development Guideline
  • Filter Testing

Subsystem Independence

The software layer where the tests take place is at the NT Native Call API. (user mode ntdll.dll) This provides the important advantage of Subsystem Independence. The WIN32 API is a Microsoft supplied, publicly available interface. This interface creates the WIN32 subsystem, which depends heavily upon the private Microsoft native call interface. The NT Native Call API interface sits below all subsystems in the OS. By rigorously verifying the correct operation of the file system at this level, the correct operation for other subsystems can be reasonably assumed.

Synthetic Operation Distinction

There are several WIN32 File System Operations which rely on the execution of a sequence of NT Native Call APIs. These are identified to be the first type of Synthetic File System Operations. The testing philosophy presented is to observe the use and expectations of the NT Native Call API by the Type I Synthetic Operations, track these usages and expectations, and verify that an existing Test (or combination there-of) exercises these operations. Some examples of this include the WIN32 Backup APIs (BackupRead, BackupWrite, BackupSeek), CopyFile and MoveFile.

The second type of Synthetic Operation is a File System related operation at the WIN32 level or NT Native Call API level which are satisfied by either the WIN32 or Kernel code. A good example is the NtSetInformationFile() call with the FilePositionInformation class specified. The file pointer is updated in the file object by the I/O Manager and the call is completed.

There are several reasons not to include Synthetic Operation testing directly in the Compliance test. Firstly, much of what would be tested would be in the WIN32 user mode code, kernel mode I/O Manager or Object Manager code. These are key system paths which are well tested and do not need to be re-tested by the File System Developer. Second, if a Synthetic Operation fails because of a File System problem, there would not be an easily descriptive failure analysis available to the developer without describing WIN32 or NT internal calls. In addition, if unexpected results do occur in the core Operating System components, these would not be easily traceable for the file system developer.

Separate Test Groups

A file system driver is usually written by modifying an existing file system or IFS Kit skeleton. The IFS Test can be used by developers to test portions of their driver before the entire FSD is complete. This is accomplished by separating the IFS Test into groups, each comprised of the relevant set of individual tests. This independence permits testing of specific portions of the new FSD without the interaction from other untested or unimplemented functions.

Asynchronous / Synchronous Testing

Most of the I/O operations can be performed both Asynchronously and Synchronously. The calling user mode thread may block in kernel mode when waiting for a Synchronous operation to complete. The same user mode thread may be able to continue execution while an Asynchronous operation is completed by a system/worker thread in kernel mode. It is the job of the FSD developer to implement this functionality within the file system driver. The IFS tests are generally designed to be run in both modes of operation. Special tests are created where applicable to test certain cases where only Asynchronous or Synchronous operations are allowed.

Fault Identification

The fault identification capability of the IFS Test allows a FSD developer to test different aspects of a file system and determine which operation causes a failure. The developer can better identify and isolate the problem if the exact point of failure is readily discernable. This capability is created by the separate IFS Test groups and independent tests within those groups. Each test will return a test status block indicating whether the test has passed or failed.

Coverage

The goal for the IFS test is to compare all functional aspects of a new FSD with other completed file systems. By comparing the untested driver against a group of comprehensive tests that are known to work on time tested file systems (e.g. FASTFAT or NTFS), a new driver could be considered compliant from a functional point of view. This is a black box approach to the problem. Given the same input, any file system put in the box should behave in the same way. This approach, in conjunction with a stress test, will result in a robust test of the new FSD.

The native calls interact directly with the I/O manager and sometimes make direct calls into the FSD through these two interfaces. The level of control in the native calls allows for specific operations to be tested on the file system; enabling fault identification. The native calls also make the test extensible since new calls can replace outdated calls, and additional calls can be added to support new IRPs or Fast I/O paths.

There is a relationship between the native calls and the IRPs and Fast I/O paths. Not all native calls are considered in the IFS Test, but all IRPs and Fast I/O paths must be addressed for complete coverage. Note that all native calls that use the file system interface were considered.

Extensible

The IFS Test can be added to when new capabilities are added to the file system model. The grouping of tests lends itself to this capability. Individual tests can be added and removed from the groups without affecting surrounding tests.

Backward compatibility can be checked by applying a selection of tests that were verified on previous versions of the Operating System and FSD.

Development Guideline

Many questions on file system development are what is the minimum set of requirements for a compliant FSD. There are few complete file systems available for NT (NTFS being the most advanced). This lends to the confusion. The IFS Test helps establish a minimum set of capabilities that a file system driver should support. The tests can be used as a designer’s guide by demonstrating the expected capabilities of their system. Notes in the documentation of the test will help describe what is expected and what capabilities the FSD must have to be compliant.

Filter Testing

The IFS Test can be used to diagnose filter problems. Appendix A in this on-line help file describes two properties of filters, transparency and co-existence. It details how the IFS Test can be used to verify these properties and determine if a filter is impacting an NT system in an undesirable way.


TD-21.2 OpenCreateGeneral File System Test Group

OpenCreateGeneral Test Group Introduction

FileSystemDeviceOpenTest

FileFullPathCreationTest

DirectoryFullPathCreationTest

FileRelativePathCreationTest

DirectoryRelativePathCreationTest

FileOpenByIDTest

NonDirectoryFileOpenTest

OpenVolumeTest

CreatePagingFileTest

FileNameLengthTest

HFHTest

UnicodeOnDiskTest

CaseSensitiveTest

PreserveCaseTest

ShortFileNameTest

ShareAccessTest

AlternateStreamTest

StreamShareTest

CreatePagingFileTest

The create paging file function can be used to create a paging file. Paging file creation is tested using a combination of file opens on the paging file and registry queries. The create paging file function is used to create a new paging file and verified to return a success. The create file function is called with the file open disposition on the paging file. All share access rights and a desired access of just synchronize are used in the open. This should fail since the file open for paging does not allow even a minimal amount of access.

FileNameLengthTest

Each file system supports different length filenames. This is file system dependent and determined by internal representations. The maximum component name length obtained from attribute information test is used to determine the maximum filename length the file system will support. This value is used to form filenames less than, equal, and greater than the maximum. The create file function is used to test the different filenames. When the filenames specified go beyond the maximum length, an error should be returned by the create file function, object name invalid. The created files are verified by calling the create file function. A successful open verifies the creation and reference of the file by names of proper length. The test is repeated for directory names. The directory file option flag is specified to the create file function.

HFHTest

This tests the parsing of the double backslash when used as a prefix for a filename or directory name. The backslash is converted to a single backslash in this case. A file is created in the root directory of the volume under test. The file is opened with a call to the create file function. The double backslash is used for the open access. The open should succeed on the file.

A directory is created in the root directory of the volume under test. The directory is opened with a call to the create file function. The double backslash is used for the open access. The open should succeed on the directory.

UnicodeOnDiskTest

The Unicode on disk volume attribute flag can be obtained using the query volume information function. This flag indicates that the file system will store the Unicode representation of the filename on the disk. Several files are created using the create file function call. These filenames contain Unicode characters. Several valid and invalid Unicode characters are used in the filename. The directory is then queried. The long names are checked to see if the Unicode representation has been preserved. The code page is then changed. The returned filenames are checked to see if the Unicode representation has been stored. All invalid Unicode characters in the code page should be returned as a ‘?’.

CaseSensitiveTest

The case sensitive search volume attribute flag can be obtained using the query volume information function. This flag indicates that the file system will differentiate between filenames that differ only in case. That is when two filenames are identical except for case, they are considered different files. This is verified by using the create file function with several filenames that differ only in case. Each file is filled with different data. The files are then opened with the filenames and the unique data they contain is verified with by reading the files. The files are then queried for the unique IDs. These IDs are verified to be different for the cases where the filenames differ only by case.

PreserveCaseTest

The case preserved names volume attribute flag can be obtained using the query volume information function. This flag indicates that the file system will preserve the case of different filenames. That is when a file is created with a mixed case filename, the directory contents when queried return filenames that reflect the original mixed case. This is verified by using the create file function call with several filenames that have mixed case. The directory is then queried. The returned filenames are checked to see if the case has been preserved from create time.

ShortFileNameTest

This test is performed if the file system supports long names. Short names are the MSDOS compatible 8.3 format. Long names are defined as any filenames that do not fit in the 8.3 format but are otherwise legal names in the file system. The file system should always create an 8.3 representation for the long filename. The 8.3 representation may be created when extended characters are used in the filename. This short name representation can be used to access the file just as with the long filename. This capability is verified by using the create file function with several long filenames and several filenames that use extended characters. The directory is then queried. The returned short and long filenames are checked to see if the short names have been properly created for the files. The file is then accessed using the short name. This should be successful.

ShareAccessTest

The share access of a handle can be specified at create file time. This access determines if subsequent opens on the same file are allowed to succeed. A file is first created with read attributes desired access and no share parameters set. This will only allow query type operations.

The file is created with the create file function. Four subsequent opens are attempted on the file. The create file function is used to open the file with the following desired access parameters: read data, write data. The two calls are made separately. These should both fail since sharing is not allowed for these options. A third call specifies zero for the access parameters, but specifies delete on close create option, this too should fail with access denied error. The last call is made with a zero for the access parameters and read attributes for the create options. This should succeed as queries are allowed. This test is verified by specifying the share parameters separately. The pass/fail result of the create file function verifies the correct operation of the share control. These tests are repeated for directories and DASD handles, the same results apply.

AlternateStreamTest

NTFS supports alternate data streams. By specifying the filename as in the normal open/create tests but following the name with a colon ‘:’ and the name of the alternate stream, the alternate streams can be opened/created. A test file is created using the create file function and data is written to the file. The test filename is appended with the string ":stream1 and the alternate data stream is opened using the create file function. Data is written to the alternate data stream. Two more streams are opened and written to with different data. All open file handles are closed. The alternate data streams and primary data stream is open for reading. The data is verified. An attempt is then made to open data streams, which do not exist in the file. The proper status should be returned from the call to the create file function.

StreamShareTest

Share access of a handle of an alternate data stream should follow the same rules as the opening of another handle on the same file. A single stream in a file containing multiple streams is first opened with the read attributes desired access and no share parameters set. This will only allow query type operations.

The stream is opened with the create file function. Four subsequent opens are attempted on the handle. The create file function is used to open a different stream with the following desired access parameters: read data, write data. The two calls are made separately. These should both fail since sharing is not allowed. A third call specifies zero for the access parameters, but specifies delete on close create option. This should also fail. The last call is made with a zero for the access parameters and read attributes for the create options. This should succeed as queries are allowed. This test is verified by specifying the share parameters separately. The pass/fail result of the create file function verifies the correct operation of the share control.

FileSystemDeviceOpenTest

The FSD should create a Device Object in the root directory of the Windows NT object namespace (e.g. \Fat, \Ntfs). This tests the opening (and thereby verification of existence) of this Device Object. The user supplies an Object Namespace path as input. The file open disposition is used with the desired access of ReadAttributes. The successful return on the operation is required to pass the test.

FileFullPathCreationTest

A fully qualified filename is one that consists of the full path to a file in the Windows NT object namespace. For this test, the system path to the volume is used as a prefix to the filename. The filename that is appended to this path is formed within the upper bound of the maximum component name length. The non-existence of the file is verified by a call to the create file function with the file open disposition. This should fail with an object name not found error. The file is then created with a call to the create file function with the file create disposition. ReadOnly volumes should return a write protection error at this point. The file handle is closed. The existence of the file is verified with a call to the create file function with the file open disposition. This should succeed.

DirectoryFullPathCreationTest

A fully qualified directory-name is one in which a full path including the system root, volume root, and directory path is supplied as a prefix to the directory name. The TESTVOL and TESTROOT strings are used as prefixes to the directory name in this test. The directory name is appended to the path and formed within the upper bound of the maximum component name length.

The failure of the create when the temporary attribute is specified is tested. The creation of a directory in a path that exists and does not exist is tested. The nonexistence of the directory is verified by a call to the create file function with the file open disposition and the file directory option flag. This option flag instructs the file system to open a directory rather than a file. This should fail.

The directory is then created with a call to the create file function using the file create disposition with the directory file option flag. This is also tested with the temporary attribute set in the call to the create file function. This should fail with an access denied error. The directory handle is then closed.

The existence of the directory is verified by another call to the create file function with the file open disposition and the directory file option flag set. This operation should succeed. The handle to the directory is then closed. A file is then created inside of the newly created directory using the create file function and the fully qualified path and filename. The call to the create file function should have the file create disposition. The handle is then closed.

A subsequent open on the fully qualified directory path and filename using the create file function and the file open disposition will verify the file is created in the directory path. The handle is then closed. The above directory creation is tested with a path specified with TESTVOL\TESTROOT\faketestdir\testdir. This should fail since faketestdir does not exist. The above directory creation is tested with a path that does exists (realtestdir instead of faketestdir). This should succeed.

FileRelativePathCreationTest

Files can be accessed by going through the handle of an open directory. This is considered a relative path access since the file is created relative to a specific open directory. The handle to the test directory is used in the object attributes parameter to the create file function. The filename is created within the upper bound of the maximum component length. Only the filename is passed into the create file function since no qualifying path is necessary.

A handle to a test directory is opened. The non-existence of the file is verified by a call to the create file function with the file open disposition, this should fail with an object name not found error. The existence of the file is verified by another call to the create file function with the file open disposition. This operation should succeed. The file handle and test directory handles are then closed. The above test file creation attempt is repeated, but the file name specified is modified to have a leading backslash. This operation should fail with an object name invalid error.

DirectoryRelativePathCreationTest

Directories can also be opened or created relative to an open directory. This is considered a relative access. The handle to a test directory, is used in the object attributes parameter to the create file function. The directory name is created within the upper bound of the maximum component name length. There is also a test for failure on leading backslash.

A handle to the test directory is opened. The nonexistence of the directory is verified by a call to the create file function with the file open disposition and the directory file option flag set. This create option instructs the file system to create a directory not a file. This should fail since the operation is attempting to open a directory that does not exist. The directory is then created with a call to the create file function using the file create disposition and the directory file create option. This should succeed. The directory handle is then closed. The existence of the directory is verified by another call to the create file function with the file open disposition and with the directory file option flag. This operation should succeed.

A file is then created inside of the newly created directory using the create file function with the file create disposition. The handle to the recently created directory should be passed in as an object attribute for the relative path information. The handle is then closed. A subsequent open using the create file function call with the file open disposition on the created directory handle verifies the file is created in the new directory. The handles to the file, directory and test directory are closed. The above test directory creation attempt is repeated, but the directory name specified is modified to have a leading backslash, this should fail with object name invalid error.

FileOpenByIDTest

The unique and persistent identifier for a file can be queried. This identifier can be used to open the file on supported file systems. A test file is created in the TESTVOL\TESTROOT path. The query information file function is called to obtain the unique index value. The 8 bytes are passed into a call to the create file function in place of the filename. A handle to the test root path is passed into the call through the object attributes root directory parameter. The file open disposition is used. The contents and attributes of the opened file are compared against the test file.

NonDirectoryFileOpenTest

The non-directory file option flag can be specified in a call to the create file function. The operation should fail if the object being opened is a directory and the flag is set. The directory file option flag can be specified in a call to the create file function. This operation should fail if the object being opened is a file and the flag is set.

A test directory is created in the TESTVOL\TESTROOT path. An open is attempted on the directory with the non-directory file. This operation should fail with the not a directory error. An open is attempted on the directory without the non-directory file disposition being set. This operation should succeed. The same operation should be performed with the directory file flag set. This should succeed in the same way the first attempt succeeded.

A test file is created in the TESTVOL\TESTROOT path. An open is attempted on the file with the directory file flag set. This operation should fail with object name invalid error. An open is attempted on the file without the directory file being set. This operation should succeed. The same operation should be performed with the non-directory file flag set. This should succeed in the same way the first attempt succeeded.

OpenVolumeTest

The file system driver should support volume or DASD opening. This allows for an opening of the "\DosDevices\?: volume device; where ?: is the name of the drive letter mapped to the volume under test. Once the volume device is opened, it can be written in a direct byte access method as opposed to a file and directory hierarchy. Automatic volume locking is also tested.

First we create a new file on the volume. We are not concerned over the desired access. This will be to maintain an open handle. Next an attempt is made to open the volume. Since the share access is 0, there can be no open handles on the volume. We check to see that the sharing violation error came back. Next we try to open the volume for reading. Even though we only have one handle open and that is a read only handle, we should fail with a sharing violation error. Next we try to open the volume with the file share read disposition on the share access. Since there is only one handle open and this is a read only handle, we should have a success. Next, two DASD opens are attempted, the first should succeed and the second should fail with an access denied error.


TD-21.3 OpenCreateParameters File System Test Group

OpenCreateParameters Test Group Introduction

OpenFileTest

OpenFileDirTest

CreateFileTest

CreateFileDirTest

OpenAlwaysFileTest

OpenAlwaysFileDirTest

OverwriteFileTest

OverwriteFileAllocTest

OverwriteFileAttrTest

OverwriteAlwaysFileTest

OverwriteAlwaysAllocTest

OverwriteAlwaysAttrTest

SupersedeFileTest

SupersedeFileAllocTest

SupersedeFileAttrTest

FileAllocationSizeTest

ExecuteAccessTest

ReadOnlyAttributeTest

HiddenAttributeTest

SystemAttributeTest

ArchiveAttributeTest

NormalAttributeTest

DirectoryAttributeTest

OverwriteFileTest

When the file create function is used with the file overwrite disposition, an existing file is required. The existing file is truncated so the end of file pointer is set to the beginning of the file. The System and Hidden attributes specified in the call to the file create function must match the attributes currently set on the existing file. New attributes are ORed into the existing attributes, that is existing attributes cannot be cleared, but additional attributes can be specified.

The file create function is used with the file overwrite function on a filename that does not exist, this operation should succeed. Next the file create function is used with the file overwrite function on a filename that does exist, this operation should return a file overwritten status. The file is then read, and should now be empty.

OverwriteFileAllocTest

When the file create function is used with the file overwrite disposition, an existing file is required. The existing file is truncated so the end of file pointer is set to the beginning of the file.

The test is performed with an allocation size specified to the file create function. The allocation size is queried and is verified to be a multiple of the minimum allocation size.

OverwriteFileAttrTest

When the file create function is used with the file overwrite disposition, an existing file is required. The System and Hidden attributes specified in the call to the file create function must match the attributes currently set on the existing file. New attributes are ORed into the existing attributes; that is, existing attributes cannot be cleared, but additional attributes can be specified.

The file create function is used with the file overwrite function on a filename that does not exist; this operation should succeed. Next the file create function is used with the file overwrite function on a filename that does exist; this operation should return a file overwritten status. The file is then read, and should now be empty.

The test is repeated again on a hidden system test file. This time when the file create function is called the status returned is a media write protected error. The test is repeated again on a read only file; now when the file create function is called the test should fail with a access denied error.

SupersedeFileTest

When the file create function is specified with the file supersede disposition, an existing file is required. The existing file is truncated so the end of file pointer is set to the beginning of the file. The system and hidden attributes specified in the call to the file create function must match the attributes currently set on the existing file. New attributes become the attributes of the file; that is existing attributes are replaced with the new attributes.

The file create function is called with the file supersede disposition and a filename that does not exist; this should succeed. Next the file create function is called with the file supersede disposition on a filename that does exist; this should return a file supersede status.

SupersedeFileAllocTest

When the file create function is specified with the file supersede disposition, an existing file is required. The existing file is truncated so the end of file pointer is set to the beginning of the file.

The test is performed with an allocation size specified to the file create function, the allocation size is then queried and it is verified to be a multiple of the minimum allocation size.

SupersedeFileAttrTest

When the file create function is specified with the file supersede disposition, an existing file is required. The system and hidden attributes specified in the call to the file create function must match the attributes currently set on the existing file. New attributes become the attributes of the file; that is existing attributes are replaced with the new attributes.

The test is performed on a hidden system file, when the file create function is called with the file supersede disposition, the media write protected error is returned. The test is repeated on a file that is read only; the call to the file create function with the file supersede disposition should fail with an access denied error.

ReadOnlyAttributeTest

The attributes of a file can be set at file creation time. If the read only attribute is set on a file, the file can be opened for reading but not writing. The file cannot subsequently be opened with the delete on close option set. The delete on close option and read only attribute are mutually exclusive. A test file with the read only attribute is opened and a write is attempted. This should fail with an invalid user buffer error. Next a read is attempted on the test file; this should pass without any errors. The file handle is then closed. The file create function with the delete on close option set, is used to open a test file; this attempt should fail with an access denied error. Next this test is performed on a test file with the delete on close and read only option set at creation time; this should fail with an access denied error.

SystemAttributeTest

The attributes of a file can be set at file creation time. If the system attribute is set on a file, the file will reflect this attribute information with the query directory file function. A file is created with the system attribute set. The query directory file function is then called to verify the existence of the flag in the returned information on the file.

OpenFileTest

An attempt is made to open a file that does not exist; this attempt should return an object not found error. Next an attempt is made to open a file that does exist; this should return a succeed.

OpenFileDirTest

An attempt is made to open a directory that does not exist; this attempt should return an object not found error. Next an attempt is made to open a directory that does exist; this should return a succeed.

CreateFileTest

The file create disposition does not allow an open on an existing file. This disposition will create a new file if the file does not exist, and returns an error if the file already exists.

The file create disposition is used to create a file that does not exist; this operation should succeed. Next the file create disposition is used to create a file that does exist; this operation should fail with an access denied error.

OpenAlwaysFileTest

The file open if disposition allows the opening of an existing or nonexistent file. If the file does not exist, the file is created. The create file function is used with the file open if disposition for a filename that does not exist; this operation should return a created status. Next the create file function is used with the file open if disposition for a file name that does exist; this operation should return an open status.

OpenAlwaysFileDirTest

The file open if disposition allows the opening of an existing or nonexistent directory. If the directory does not exist, the directory is created. The create file function is used with the file open if disposition for a directory name that does not exist; this operation should return a created status. Next the create file function is used with the file open if disposition for a directory name that does exist; this operation should return an open status.

OverwriteAlwaysFileTest

The file overwrite if disposition does not require an existing file. If the file is created, the end of file pointer is already at the beginning of the file so no overwriting is done. If the file already exists, the file is truncated. The end of file pointer is set to the beginning of the file. The system and hidden attributes specified in the call to the file create function must match the attributes currently set on the existing file. New attributes are ORed into the existing attributes; that is, existing attributes cannot be cleared, but additional attributes can be specified.

The file create function is used with the file overwrite if disposition on a filename that does not exist. The status returned should be a file created success. Next the file create function is used with the file overwrite if disposition on a filename that exists and contains data, this should return a success message, and a file overwritten status. A read is done on the file and there should be no data in it.

OverwriteAlwaysAllocTest

The file overwrite if disposition does not require an existing file. The file create function is used with the file overwrite if disposition on a filename that does not exist. The status returned should be a file created success. Next the file create function is used with the file overwrite if disposition on a filename that exists and contains data, this should return a success message, and a file overwritten status. A read is done on the file and there should be no data in it.

The test is repeated with an allocation size specified in the file create function; the allocation size is then queried and it is verified to be a multiple of the minimum allocation size.

The test is repeated on a hidden system file, when the file create function is called with the overwrite if disposition, the media write protected error is returned. The test is repeated, this time on a file that is read only; the call to the file create function with the overwrite if disposition should fail with an access denied error.

OverwriteAlwaysAttrTest

The file overwrite if disposition does not require an existing file. The file create function is used with the file overwrite if disposition on a filename that does not exist. The status returned should be a file created success. Next the file create function is used with the file overwrite if disposition on a filename that exists and contains data; this should return a success message, and a file overwritten status. A read is done on the file and there should be no data in it.

The test is repeated on a hidden system file, when the file create function is called with the overwrite if disposition, the media write protected error is returned. The test is repeated, this time on a file that is read only; the call to the file create function with the overwrite if disposition should fail with an access denied error.

FileAllocationSizeTest

The allocation size of the file can be specified at creation time. This is the amount of space the file takes up on the storage device. The actual size of the file is marked by the end-of-file pointer. The minimum allocation size varies on a file system, and volume basis. The file create function is used with a specified allocation size to reserve the storage for several files. Each file requests a different allocation size. Each file is then queried and verified for its allocation size. The size should be consistent with the specified allocation size, rounded up to the minimum allocation size allowable for the volume. Then a file is created with no allocation size specified; the default allocation size should be zero and this is verified.

ExecuteAccessTest

The file execute disposition causes the file system driver to update the last accessed time on a handle close. The last access time is read from the file and recorded. The file create function is used to open a sample executable with the file execute disposition. The handle is then closed. The last access time is then checked and verified to be updated.

HiddenAttributeTest

The attributes of a file can be set at file creation time. If the hidden attribute is set on a file, the file will reflect this attribute information with the query directory file function. A test file is created with the hidden attribute set. The query directory file is used to verify the existence of the flag in the returned information on the file.

NormalAttributeTest

The attributes of a file can be set at file creation time. If the normal attribute is set on a file, the file will reflect this attribute information with the query directory file. Normal file attributes are NOT read only, hidden, system, directory or archive. A file is created with the normal attribute set. The file is then closed. The query directory file is then called to verify the absence of the following attributes: read only, hidden, system, directory or archive.

DirectoryAttributeTest

The directory attribute designates a file as a directory. The attribute should be set by the file system when a new directory is created. If the directory attribute is set on a file, the file will reflect this attribute information with the query directory file. A test directory is created and the query directory function is called on the directory containing this test directory, to verify the existence of the flag in the returned information on the directory. A new file is then created and the query directory file function is called to verify the cleared directory attribute flag in the returned information on the file.

CreateFileDirTest

The file create disposition does not allow an open on an existing directory. This disposition will create a new directory if the directory does not exist, and returns an error if the directory is already existing.

The file create disposition is used to create a directory that does not exist, this operation should succeed. Next the file create disposition is used to create a directory that does exist; this operation should fail with an access denied error.

ArchiveAttributeTest

The attributes of a file can be set at file creation time. If the archive attribute is set on a file, the file will reflect this attribute information with the query directory file. The archive attribute should be set anytime a file is created or modified without the archive attribute specified in the call to the file create file function. A file is created with the archive attribute set. The query directory file is used to verify the existence of the flag in the returned information on the file. The test is repeated on a file without the archive attribute set, the attribute should be set after the handle to the file is closed. The test is repeated with four permutations of cached/no buffering and synchronous/asynchronous. The test file is again opened and the archive bit is cleared. The handle to the file is then closed. The file is then queried and it is verified that the archive bit is not set. The file is again opened and a few bytes are written to the file. The handle to the file is then closed. The query directory file is then called again to verify the archive bit is set.


TD-21.4 CloseCleanupDelete File System Test Group

CloseCleanupDelete Test Group Introduction

VolumeUnlockOnCloseTest

UpdateOnCloseTest

UpdateOnCloseDirTest

TruncateOnCloseTest

DeleteOnLastCloseTest

TunnelingTest

VolumeUnlockOnCloseTest

The volume can be opened directly for DASD access. I/O buffers must be subsequently sector aligned direct or buffered. The volume is auto-locked as a result of a DASD open. The semantics for the DASD open are tested in OpenVolumeTest. No additional files can be opened on the locked volume (even with minimal or no desired access).

The test opens the volume with auto-lock and attempts to perform a file open. The operation’s failure (due to the locked volume) is verified. The handle to the open volume is then closed. When the DASD handle is closed, the volume should release the volume lock. This is tested by again attempting a file open. This time the file open should succeed.

UpdateOnCloseTest

A Directory Handle can be used to find a file contained in that directory, and obtain the File Times, Attributes, End of File Pointer, and Allocation size. If there are open handles on the file, there may be a difference between changes that have been made to the file, with regards to the above file information, and the information that is read back by way of the open directory handle. The information is updated when the last open handle to the File Object is closed. This sends out an IRP_MJ_CLEANUP.

This test first creates a number of files, verifies the file information by way of a directory handle and queries. The files are then opened, written to, and read from. The file information is again queried and checked to see that it has not updated. The file handles are then closed. The file information is again queried and the updated information is verified.

The test is repeated, but then the updated (but not committed) information is changed using a IRP_MJ_SET_INFORMATION. The information that was updated by way of the set information IRP is verified when the file handles are closed. The test verified the set information overwrites any other updated information when the IRP_MJ_CLEANUP causes the file system driver to reconcile the information.

UpdateOnCloseDirTest

A Directory Handle can be used to find a sub-directory contained in that directory, and obtain the File Times, Attributes, End of File Pointer, and Allocation size of the sub-directory. The End of File Pointer and Allocation size should be returned as 0. If there are open handles on the sub-directory, there may be a difference between changes that have been made to the sub-directory, with regards to the above information, and the information that is read back by way of the open directory handle (of the directory that contains the sub-directories). The information is updated when the last open handle to the File Object (for the sub-directory) is closed. This sends out an IRP_MJ_CLEANUP.

This test first creates a number of sub-directories, verifies the file information by way of a container directory handle and queries. The sub-directories are then opened, access by listing, and modified by creating file inside of those test sub-directories. The file information is again queried and checked to see that it has not updated. The sub-directory handles are then closed. The file information is again queried and the updated information is verified.

TruncateOnCloseTest

If the allocation size is larger than the file size, the file system should reduce the allocation size to the smallest possible size rounded up to the nearest minimum allocation unit. This reduction is performed when IRP_MJ_CLEANUP is sent to the file system. This corresponds to close of the last open handle to a file object.

This is tested with a file where the allocation size is set at creation time. The file is then written with a much smaller amount of data then the allocation size. The handle is then closed. The file is again opened (allocation size not set on open) and the allocation size is checked to see that it has been reduced.

TunnelingTest

The short naming convention is in the DOS 8.3 format. Both FAT and NTFS file systems have 2 namespaces. These namespaces should map to the same files. When a file is created with a name that is not in the 8.3 format and ASCII code page, a short name representation can also be created. The short name can be used to access the file by an MS-DOS or Windows operating system. The short name can also be used by Windows NT to access the file. A problem arises when legacy applications delete files by their Short Names, and then try to re-create these files. Namely, the long names would be lost. The Tunneling Cache in the FAT and NTFS file systems takes care of this. The Cache is Process and Directory specific. When a file is deleted, and created again using it’s short name ONLY, the long name will be re-applied to the file.

This test first opens a test directory. The directory handle is then used to create several long named files in that directory. The different directory handle is then used to query for long and short name information. The handles to the files are closed. The files are then deleted.

Files are created using the directory handle and the previously queried short names. A different directory handle is then used to query the directory for file name information. The long file names are thereby verified.

DeleteOnLastCloseTest

Files are deleted on the final handle IRP_MJ_CLEANUP that have previously been marked for deletion. The are two mechanisms for marking a file for delete. The first is from open/create with the option to delete on close. The second is to set the file information to mark the file for delete on close. These two mechanisms have different semantics. The following rules should clarify the purpose of this test:

  • When a handle is opened for delete on close, that handle is now a "delete on close handle.
  • When a "delete on close handle is closed (in the IRP_MJ_CLEANUP path), the file is then (and only then) marked for deletion and becomes a "delete on close file.
  • When the file is deleted through a set information call, the file is marked for deletion and becomes a "delete on close file.
  • No additional handles can be opened on a delete on close file (i.e. a file that has been marked for deletion). Such attempts will fail with STATUS_DELETE_PENDING.
  • A query for deletion pending to a file that is a "delete on close file will return TRUE.
  • When the file information is set not to delete the file on close, the file is unmarked for deletion and is no longer a "delete on close file. The handle that received the set information call may still be a "delete on close handle, in which case the file will again become a "delete on close file when the handle is closed.
  • When the final handle to a "delete on close file is closed, the file is deleted.


TD-21.5 VolumeInformation File System Test Group

VolumeInformation Test Group Introduction

VolumeLabelTest

VolumeInformationTest

SizeInformationTest

DeviceInformationTest

AttributeInformationTest

VolumeLabelTest

Each volume maintains a label that can be queried and set. This test opens up a handle to a volume and queries the volume information. The volume handle is then closed and two handles, a directory handle and file handle are then opened. A volume information query is done on both handles and verification is done to make sure the volume information matches that which was queried with the volume handle. Next the volume label is changed and a query is done to make sure that the label did get changed. If the label did get changed then the original volume label is restored and the test has complete. The test is run 3 more times to test certain error conditions. The first error condition to test is trying to change the volume label with a directory or file handle, this attempt should return an access denied error. The second error condition to test is trying to set the volume label to a string over 32 UNICODE characters long; this should return a invalid volume label error. The third error condition to test is trying to query the volume information with a small buffer; this should return a buffer overflow error.

VolumeInformationTest

The creation time, serial number, and volume label are applied to the volume at format time. The operating system can query the volume for this information. This test is run 3 times, opening up a volume handle, directory handle and a file handle. Each handle is then queried for volume information and the following fields are all verified: volume creation time, volume serial number, volume label length, support objects, and volume label are all checked.

SizeInformationTest

The size information that can be queried gives information about the allocation units on the volume. The allocation unit is the smallest unit of space that can be allocated on a volume. For example, a file that stores 1 byte will allocate the allocation unit size on the volume. This information is verified here and is used in other tests. This test is run 3 times, opening up a volume handle, directory handle and a file handle. Each handle is then queried for volume size information and the following fields are all verified: total allocation units, available allocation units, sectors per allocation unit and bytes per sector.

DeviceInformationTest

The characteristics of a volume device can be queried along with the device type. This test is run 3 times, opening up a volume handle, directory handle and a file handle. Each handle is then queried for volume device information and the following fields are all verified: device type and characteristics.

AttributeInformationTest

The attributes are initially set during volume formatting. The attributes contain important information about the capabilities of the file system with the volume. This test is run 3 times, opening up a volume handle, directory handle and a file handle. Each handle is then queried for volume attribute information and the following fields are all verified: file system attributes, maximum component name length, file system name length and file system name.


TD-21.6 FileInformation File System Test Group

FileInformation File System Test Group

BasicInformationTest

StandardInformationTest

InternalInformationTest

EaInformationTest

NameInformationTest

AllInformationTest

AllocationInformationTest

ZeroAllocationInformationTest

CompressionInformationTest

DispositionInformationTest

EndOfFileInformationTest

LinkInformationTest

SimpleRenameInformationTest

ConflictingRenameInformationTest

AlternateNameInformationTest

FileNetworkOpenInformationTest

StreamInformationTest

StreamStandardInformationTest

AllInformationTest

The basic information, standard information, internal information, EA information, position information and name information can all be queried on a file at the same time. A file handle or directory handle is opened and the file is queried for all the information: creation time, last access time, last write time, change time, file attributes, allocation size, end of file pointer, number of links, delete pending flag, directory flag, index number, EA size, long filename, long filename length and current byte offset. All these values are compared to the known values obtained at creation time of the file or directory. If all match then the test has passed.

AllocationInformationTest

The allocation size of a file can be set to truncate or extend the file. The allocation size is the amount of space the file system reserves for use by the file. This allocation size can be initialized at create time and later changed. It is changed automatically by writing beyond the end of file. The file size is different from the allocation size. The allocation size must fall on an allocation unit boundary while the file size can be any value at or before the currently allocated size. A test file is opened with a non zero allocation size. A query is performed to make sure that the allocation size is equal to what was set at create time of the file. Then the allocation size is reduced, this should truncate the file. A query is performed to make sure the allocation size did reduce. If this passes then the allocation size is even further reduced and query is performed again to make sure the size did decrease. A separate query is performed specifically on directory files to verify the change in allocation size. Next the allocation size is increased on the file and a query is performed to verify this increase. If all these changes in allocation size are verified the test has passed.

ZeroAllocationInformationTest

A test file that has an allocation size of zero is opened. This file is then written to with 1000 bytes of data. A query is then performed to obtain the allocation size, it is expected to be a multiple of 512. If this passes, then a second query is done on the file as a directory file. This type of query should return a zero for the allocation size because the allocation size will not be updated on the directory file until the handle to the directory file is closed. If this passes the file handle is closed and a second query on the directory file is done to make sure the allocation size is a multiple of 512.

CompressionInformationTest

The compression information for the file can be queried if the file system supports file compression. This returns information on the compression used if the file is compressed. Two test files are opened (one that is compressed and one that is not). A query is performed on both files and a check is performed to make sure that the uncompressed file size is greater than the compressed file size.

DispositionInformationTest

Files are deleted on close. This deletion takes place when a flag is set in the file object. The file can also be flagged to be deleted at create time. A file handle is opened on a test file and the deletion flag is then set on the file. A query is performed to make sure the Delete Pending flag is set, then the file handle is closed. Next an attempt is made to open the deleted file, the failure of this open will verify that the file was deleted.

EndOfFileInformationTest

The end of file position can be changed. This marks the actual end of file for data reading and writing purposes. The end of file position is less than or equal to the allocation size since the granularity of allocation on the file system is usually a power of 2 sectors. First the original size on file create is checked and then the end is moved towards the beginning of the file. The allocation size is checked to make sure it reduced to the nearest possible size. Next the end of file pointer is moved toward the end of the file. The allocation size is checked to see if it is enlarged.

LinkInformationTest

Hard links can be created to an open file. This functionality is tested here. When the file is opened with the linked filename, the file should look identical to the original file with respect to data and queried information. A file with test data is opened and a link to the file is created. The file is then closed. The file is opened again, this time using the link. The data in the file is read and compared against the original data in the file, which should be the same. Next all the attributes are compared against the original attributes of the file to see if they are the same. The following data is checked: File Attributes, Creation Time, Last Access Time, Last Write Time, Change Time, Allocation Size, End Of File pointer, Number of Links, Delete Pending flag, Directory flag, Index number, EA size and Current Byte offset.

SimpleRenameInformationTest

A file/directory can be renamed only within a volume. The root directory cannot be renamed. The rename target may specify either a file or a directory. A handle to a file is opened and it is renamed to a non-existing filename. The same is done with a directory. Next a rename is attempted on a root directory, this operation should fail with an invalid parameter error. Next a rename is attempted on a file between two volumes, this should also fail with an invalid parameter error.

ConflictingRenameInformationTest

A testfile is opened and an attempt is made to rename the filename to an existing filename. If the file attribute, Replace If Exists, is set, then a file can be renamed to an existing filename, otherwise an error will be recorded. When the testfile or directory is renamed to an existing filename (Replace If Exists not set) an invalid parameter error occurs. This rename is attempted again but with the Replace If Exists flag set, this operation should succeed. Next a second testfile is opened twice (two handles are opened to the same file), a file rename is attempted on both handles, both attempts should return an access denied error.

AlternateNameInformationTest

The long name can be used to obtain the 8.3 representation with a query call. A file with a filename length of over 15 characters is opened and data is written to the file. A query is performed on the file to obtain its 8.3 representation. The handle to the file is then closed. The file is reopened using the 8.3 alternate name from the query; the data from the file is read and verified to insure that it is correct.

FileNetworkOpenInformationTest

Network open information is another file information class that can be queried. This information includes creation time, last access time, last write time, change time, allocation size and end of file. A test file is opened and the following information is queried and verified: creation time, last access time, last write time, change time, allocation size and end of file.

StreamInformationTest

A file can be queried for the file information. This information includes the stream name, size in bytes, and allocated size in bytes. A primary data stream is written with data. Alternate data streams are created with unique and varying amounts of data. The stream names are verified to be of the format ".%stream name%:DATA$. The stream sizes and allocation sizes are verified. The allocation size should have a granularity of 8 bytes.

StreamStandardInformationTest

The standard information, allocation size and end of file pointer should be unique for each stream. The number of links and delete pending information should be common for all streams in the file. A test file that contains multiple streams is opened and the following information is queried and verified: allocation size, end of file, number of links, delete pending flag and directory flag value. A single file handle is used to mark the file for deletion. A different file handle is queried and the Delete Pending flag is verified to be set. A link is made to an open stream handle, and all the open handles queried to check the Number of Links value.

BasicInformationTest

Basic information can be queried or set. This information includes the file attributes, which are initialized at create time. It also includes all the timestamps on the file including creation and various access times. This test involves opening up a file or directory handle and querying the creation time, last access time, last write time, change time and file attributes. These values are compared to the known values that were obtained at creation time. If all values are correct, then these values are changed. The file is queried again to make sure that the changes have been made.

StandardInformationTest

Standard information on a file can be queried. The allocation size is the amount of space allocated for the file. The end of file pointer points to the end of the file and must be contained in the current allocation size. This marks the actual end of the file. The number of links indicates the number of hard links on the file. The delete pending flag indicates the file is marked for deletion and the deletion occurs when all handles to the file are closed. The directory value indicates if it is a directory. This test opens up a file or directory handle and queries the standard information on the file: Allocation Size, End Of File pointer, Number of Links, Delete Pending and the Directory value. All of these values are then compared to the known values.

InternalInformationTest

The index of the file is a unique and persistent 64 bit integer. The index value of the file can be used to open up a file (may not be supported by all file systems). A file handle or directory handle is opened and the Internal information of the file is queried (the query returns the Index Number of the file). The file handle is then closed. The file is again opened and the Index Number is queried. A verification is done to make sure that the two Index Numbers match. If they match, the test is passed.

EaInformationTest

The extended attribute size on the file can be queried. This is the size of the extended attribute information stored along with the file. A file handle is opened and the EA information is then queried. The EA size is compared to the known EA size; if they match then the test is passed.

NameInformationTest

The name of the file can be queried. This is the long filename and the length of the filename. A file handle or directory handle is opened and a query is performed to obtain the long filename and the filename length. The long filename is compared to the filename that was used to open the handle; if they match the test is passed. The test is repeated with a small buffer to query the filename data, this is done to see if a buffer overflow error is returned by the query.


TD-21.7 EaInformation File System Test Group

EaInformation Test Group Introduction

CreateEaInformationTest

SetEaInformationTest

SingleEaEntryTest

FullEaInformationTest

ListEaInformationTest

IndexEaInformationTest

FullEaInformationTest

All of the Extended Attribute information for a file can be accessed at once. The test file used for this test has three Extended Attributes each with 4 bytes of data. This file is opened with access privilege that permits its EA data to be read. A query is performed to read out all the EA entries associated with this file at once. The data and labels that are returned are verified.

ListEaInformationTest

The Extended Attribute information can be selectively queried based on a list of Extended Attribute names. The test file used for this test has three Extended Attributes each with 4 bytes of data. This file is opened with access privilege that permits its EA data to be read. A query list with a label to just the second entry is created and a query is performed on just the second EA entry. The data associated with the second EA entry is verified. Then the query list with a label to just the third entry is created and a query is performed on just the third EA entry. The data associated with the third EA entry is verified. The same is done for the first entry.

IndexEaInformationTest

The Extended Attribute information can be selectively queried based on an index value. The test file used for this test has three Extended Attributes each with 4 bytes of data. The file is opened with access privilege that permits its EA data to be read. A query is performed specifically indexing just the second EA entry. The data and label associated with the second entry is verified. Then a query is performed specifically indexing the third EA entry. The data and label for the third entry is verified. The same is performed to query the first EA entry.

CreateEaInformationTest

The Extended Attribute information for a file can be specified at creation time. The test file used for this test has one Extended Attribute with 4 bytes of data associated with it. This file is opened with access privilege that permits its EA data to be read. The file is then queried for its EA data. If the query is successful then the file has EA data associated with it and the CreateEaInformationTest has passed.

SetEaInformationTest

The Extended Attribute information for a file can be set after creation time. The first part of the test uses a file that has no Extended Attribute associated with it. This file is opened with access privilege that permits its EA data to be written and read. First the file is queried to check the size of the EA, since this file has no EA data the EA size is expected to be zero. Next there are two Extended Attributes each with 4 bytes of data set for the file. The file is queried one entry at a time, to verify the Extended Attributes that were just set (EA name and EA data). The first test file is then closed. The second part of the test uses a file that has one Extended Attribute with 4 bytes of data associated with it. The file is opened with access privilege that permits its EA data to be written and read. The second file is queried to check the EA size matches the size of one Extended Attribute with 4 bytes of data. Next the existing Extended Attribute is replaced with new data values but the label will still be the same. The file again is queried to check if the label matches that which is expected and to verify the data value change. Last the file is queried again to check that the EA size is that of an Extended Attribute with 4 bytes of data associated with it.

SingleEaEntryTest

The Extended Attribute information for a file can be read back one entry at a time. The test file used for this test has three Extended Attributes each with 4 bytes of data associated with it. This file is opened with access privilege that permits its EA data to be read. A query is performed from the start of the EA entries block to return just the first entry. The data and label associated with this entry are then verified. This is done two more times to verify the second and third EA entries, but this time the scan is not done from the start of the EA entries block, it is done from after the last EA entry that was queried.


TD-21.8 DirectoryInformation File System Test Group

DirectoryInformation Test Group Introduction

FileNameDirectoryInformationTest

FileDirectoryInformationTest

FullDirectoryInformationTest

BothDirectoryInformationTest

FullDirectoryInformationTest

The access times, end of file pointer, Ea size and allocation size for the files in a directory can be queried. This test is run four times on a directory with four files that have different allocation sizes. The file is opened and then some data is written to the file, this write should update the last access time, last write time and change time of the file after a close. The file is then reopened and queried for the times, allocation size, ea size and end of file pointer; these values are then checked.

FileNameDirectoryInformationTest

The file names and file name length parameters can be queried of a specific directory. Four different files are opened and the filenames and filename lengths are checked for each of these files. If the file names and file name lengths match then the test has passed.

FileDirectoryInformationTest

The access times, end of file pointer and allocation size for the files in a directory can be queried. This test is run four times on a directory with four files that have different allocation sizes. The file is opened and then data is written that should update the last access time, last write time and change time of the file after a close. The file is then reopened and queried for the times, allocation size and end of file pointer to confirm that the values have changed.

BothDirectoryInformationTest

The access times, end of file pointer and allocation size for the files in a directory can be queried. This test is run four times on a directory with four files that have different allocation sizes. The file is opened and then data is written that should update the last access time, last write time and change time of the file after a close. The file is then reopened and queried for the times, allocation size and end of file pointer to confirm that the values have changed.


TD-21.9 FileLocking File System Test Group

LockSharedExTest

UnlockRangeTest

LockOverlapTest

LockRangeTest

LockFailImmediateTest

LockOverlappedTest

UnlockAllTest

UnlockRangeOnCloseTest

LockKeyTest

LockSharedExTest

This tests the use of exclusive and shared byte range locking in multiple processes. Process A obtains some exclusive and shared locks on a file. The correct read and write accesses are tested in these locked regions. Process B then attempts to obtain locks on these same regions. These operations are checked for failure. Process B then attempts to access the areas locked by Process A. Correct access is verified.

UnlockRangeTest

Process A is used to obtain some exclusive and shared byte range locks on a file. Process A then verifies proper access to the locked regions. Some of these locked regions are then unlocked. Process B attempts access to the still locked and recently unlocked regions. Correct access is verified. Process B then attempts locks on the areas previously locked by Process A. These operations are checked for success.

LockOverlapTest

Several exclusive and shared locked ranges are obtained on a file. Overlapping exclusive locks are attempts on locked exclusive regions. Failure is verified for these locking attempts. Shared locks are then attempted on the exclusive and shared locked regions. Success is verified for these attempts.

LockRangeTest

Process A locks a whole file with exclusive and shared locks. Proper access is verified when the entire file is locked. Process A then locks a range larger than the current file. Process B attempts access to the area beyond this locked region. This should succeed. Process B then attempts access to the area locked by Process A when the file was smaller than that area. The byte range lock held by A should be verified on this range in terms of obtaining a lock on the same region.

LockFailImmediateTest

The file locking API can be set to fail immediate if a lock is currently held on the region of the file. This is tested with a synchronous file handle. The blocking of the thread by the alternate process is tested until the lock is release. The fail immediately will not block with a synchronous handle.

LockOverlappedTest

The file locking API can be used with events for synchronization. The APIs are used between two processes. Process A obtains a lock on a byte range. Process B then attempts to obtain a lock and waits on the event handle. This wait should not timeout, but the event should become signaled when the lock is released by Process A.

UnlockAllTest

Several locks are obtained on a file handle. This handle is then closed. The same locks are attempted with another file handle that is obtained before the first file handle is closed. The locks are again attempted and should be granted since they were all unlocked with the handle close.

UnlockRangeOnCloseTest

  • Start Process A.
  • First get 2 handles.
  • Obtain some locks on handle 1.
  • Try and fail to obtain same locks on handle 2.
  • Obtain some other locks on handle 2.
  • Start of thread
  • Thread will close handle 1 at t=1 seconds.
  • Thread will close handle 2 at t=2 seconds.
  • Start Process B.
  • Try and fail to obtain all locks on handle 1 and 2.
  • Wait till t=1 second and obtain locks that were on handle 1 only.
  • Wait till t=2 second and obtain locks that were on handle 2.

LockKeyTest

  • Process A gets some shared and exclusive locks.
  • Process A attempts to access this data without key and fails.
  • Process A attempts to access WITH key and succeeds.
  • Process B attempts to access this data without key and fails.
  • Process B attempts to access WITH key and succeeds.


TD-21.10 OpLocks File System Test Group

OpportunisticLocks Test Group Introduction

OplockBreakItoIITest

OplockIIWriteBreakingTest

OplockBreakIItoNoneTest

OplockBreakandIIOnCloseTest

OplockRequestIITest

OplockIIOpenBreakingTest

BatchOplocksTest

BreakNotifyTest

FilterOplockTest

CompleteImmediatelyTest

OplockReadBreakItollTest

OplockLevel1Test

OplockSetInfoBreakTest

LockOplockBreakTest

BatchOplocksTest

The batch oplock is operationally equivalent to a level 1 oplock (i.e. it is exclusive). The difference is that while a Level I oplock is always backed by a real user handle, a batch oplock may be held by a proxy agent (such as srv.sys) to indicate that it is keeping a file open in the hope that a client will need it again; but should the file system like it closed, it will close the file.

Step 1. C opens a test file for reading.

Step 2. C requests a Batch Oplock on the file using the FSCTL_REQUEST_BATCH_OPLOCK file control.

Step 3. The file should be read by C, this should succeed.

Step 4. D opens the test file for reading and writing, this should block since there will be a break pending.

Step 5. The IRP from step 2 should complete indicating that the Batch Oplock has been broken. The Information should be FILE_OPLOCK_BROKEN_TO_LEVEL_2.

Step 6. C sends the FSCTL_OPLOCK_BREAK_ACKNOWLEDGE control to the file system to acknowledge the break.

BreakNotifyTest

Additional IRPs can be queued to wait for a break to complete. These IRPs will wait for the full break to occur. That involves the completion of the original break IRP and the acknowledge cycle.

Step 1. C opens a test file for reading and writing.

Step 2. C requests a Level I oplock on the file using the FSCTL_REQUEST_OPLOCK_LEVEL_I file control.

Step 3. The file should be written to and read from by C, this should succeed

Step 4. D opens the test file for reading and writing, this should block. This is because the client holding a Level I oplock must be notified of break and the client's buffers flushed.

Step 5. The IRP from step 2 should complete.

Step 6. The FSCTL_OPLOCK_BREAK_NOTIFY control should be sent. This IRP should be queued since there is a break in progress.

Step 7. C issues the FSCTL_OPLOCK_BREAK_ACKNOWLEDGE control. This will acknowledge the break to a level II lock.

Step 8. The IRP from step 6 should now complete indicating that there is now no break in progress.

Step 9. C and D close the file.

FilterOplockTest

There is currently no description for this test.

CompleteImmediatelyTest

Normally an open to an oplocked file will block until the file's oplock is broken. There is a file option that can be specified at open time called FILE_COMPLETE_IF_OPLOCKED that changes the blocking behavior (this was added to solve several deadlock conditions within the srv.sys.) If this option is specified and the open is otherwise successful, the final status will be STATUS_OPLOCK_BREAK_IN_PROGRESS, which is an NTSUCCESS code. If the open fails for any reason, the final status will be the error code. In either case the Information value will be FILE_OPLOCK_BREAK_UNDERWAY which tells the caller that an oplock break has been initiated..

Step 1. A opens a file and requests a Level I oplock.

Step 2. B opens the same file with the FILE_COMPLETE_IF_OPLOCKED option set.

Step 3. The call should complete normally with FILE_OPLOCK_BREAK_UNDERWAY in the Information field regardless of the final Status of the create operation.

Step 4. The Oplock IRP from Step 1 should complete.

Step 5. The same open should be attempted without the option.

Step 6. The call should then block until the oplock break on the file is acknowledged.

OplockReadBreakItoIITest

This should be called OplockWriteBreakIItoNone Test. The only major IRP type that will cause a break is IRP_MJ_WRITE. That is why this test was modified to test the breaking through the "data access FSCTL.

Step 1. C opens a test file for reading and writing.

Step 2. D opens the same test file for reading and writing.

Step 3. C requests a Level II oplock on the file with the FSCTL_REQUEST_OPLOCK_LEVEL_II file control.

Step 4. The file should be read by C, this should succeed.

Step 5. D attempts to write to the file issuing the IRP_MJ_WRITE request. This will be blocked because the client holding a Level II oplock must be notified of break to None and the client's buffers flushed.

Step 6. The IRP from step 3 should complete.

OplockLevel1Test

This tests that Level I oplocks are exclusive.

Step 1. C opens a test file for reading and writing.

Step 2. D opens the same test file for reading and writing.

Step 3. C requests and receives a Level I oplock on the file with the FSCTL_REQUEST_OPLOCK_LEVEL_I file control. This should fail with STATUS_OPLOCK_NOT_GRANTED since there is another handle outstanding.

Step 4. C and D close the file.

OplockSetInfoBreakTest

The IRP_MJ_SET_INFORMATION request will cause a break of a Level I or Level II lock to none. This is because when issued by a client, there are changes to critical information that logically invalidate the oplock. These include the following types of Set Information:

FileEndOfFileInformation

FileAllocationInformation

FileRenameInformation

FileLinkInformation

The first two classes above will break any oplock to none, while the latter two will only break batch oplock to none. Note that the following test is for a single set operation. The following steps should take place 3 times, each time with a different information item being changed:

Step 1. C opens a test file for reading and writing.

Step 2. D opens the same test file for reading and writing.

Step 3. C requests a Level II oplock on the file with the

FSCTL_REQUEST_OPLOCK_LEVEL2 file control.

Step 4. The file should be read from by C, this should succeed.

Step 5. D uses the NtSetInformationFile()to set the information

file. This will be blocked because the client holding a

Level II oplock must be notified of break to none.

Step 6. The IRP from step 3 should complete.

Step 7. The set information operation from step 5 should now

become unblocked and complete successfully.

Step 8. C and D close their handles.

LockOplockBreakTest

Oplocks held against an open file object must be broken before the byte range file locking can be completed. The file system performs this break synchronously (thread requesting lock is blocked until oplock notification cycle has been completed). This ability is tested with the following steps:

Step 1. Process C requests a Level II oplock on the file and receives back STATUS_PENDING indicating that the oplock has been granted.

Step 2. The file should read from by C, this should succeed.

Step 3. Process D attempts to lock a range of the file using NtLockFile(). This thread (of Process D) should block.

Step 4. The IRP obtained in step 1 should complete with FILE_OPLOCK_BROKEN_TO_NONE.

Step 5. The NtLockFile() call from step 3 should now complete.

Step 6. Process C should attempt writing to the locked range of bytes. This operation should fail since Process D now holds a byte range lock on the file.

OplockBreakItoIITest

Only a single level I oplock can be held on a file. When the file is opened a second time for reading or writing, the level I oplock will be broken to a level II. The original owner of the file will be able to keep the level II lock until the file is written to. The file can be read from with cached reads.

1. C opens a synchronous handle to the test file for reading and writing.

2. C requests a Level I oplock on the file. This should return with STATUS_OPLOCK_NOT_GRANTED.

3. C opens an asynchronous handle to the test file for reading and writing.

4. C requests a Level I oplock on the file and receives back STATUS_PENDING indicating that the oplock has been granted. An event handle is used to signal an oplock break.

5. The file should be written to and read from by C, this should succeed. The oplock should not break.

6. D opens the test file for reading and writing, this should block. This is because the client holding a Level I oplock must be notified of break and the client’s buffers flushed.

7. The IRP from step 4 should complete and the event signaled in process C.

8. C issues the FSCTL_OPLOCK_BREAK_ACKNOWLEDGE control. This will acknowledge the break to a level II lock. This FSCTL returns STATUS_PENDING.

9. The blocked open from step 6 should now become unblocked.

10. C should be able to read from the test file without the level II oplock breaking.

11. D should also be able to read from the file without the level II oplock breaking.

12. C and D close the file.

OplockIIWriteBreakingTest

If a level II oplock is held by a file, and the file is written to, the oplock will be broken. This can only occur by a file that has opened the file for read and write access and originally obtained a level II oplock on the file. It could not occur with any but the first since subsequent opens with the write ability will cause the oplock to break on open. We just test that a write in another process will break the level II oplock, and a subsequent write operation is successful.

  1. C opens a test file for reading.
  2. C requests a Level II oplock on the file.
  3. The file should be read from by C, this should succeed.
  4. D opens the test file for reading and writing. This breaks the level II oplock.
  5. D then attempts to write to the file. This should be successful.
  6. Both files handles are closed.

OplockBreakIItoNoneTest

If a file is written to when a level II oplock is maintained on the file, the level II oplock is broken to none. The write IRP is queued until the lock is completely broken through the notify-response protocol.

Step 1. C opens an asynchronous handle to a test file for reading and writing.

Step 2. C requests a Level I oplock on the file and receives STATUS_PENDING

Step 3. The file should be written to and read from by C, this should succeed.

Step 4. D opens the test file for reading only, this should block. This is because the client holding a Level I oplock must be notified of break and the client's buffers flushed.

Step 5. The IRP from step 2 should complete with FILE_OPLOCK_BROKEN_TO_LEVEL_2.

Step 6. C issues the FSCTL_OPLOCK_BREAK_ACKNOWLEDGE control. This will acknowledge the break to a level II lock.

Step 7. The blocked open from step 4 should now become unblocked.

Step 8. D should also be able to read from the file without the level II oplock breaking. These will not be cached reads since D does not hold an Oplock.

Step 9. C should be able to read from the test file without the level II oplock breaking.

Step 10. D shoud try to write to the file. This should break the level II oplock held on the file by C with FILE_OPLOCK_BROKEN_TO_NONE.

Step 11. The IRP from step 6 should complete.

Step 12. C and D close the file.

OplockBreakIandIIOnCloseTest

When a file is closed Level I or Level II oplocks are broken. This is tested by opening a file with a level I and then level II oplock and closing the file. The breaking of the locks is verified and the correct protocol state is verified by attempting subsequent access. Normally, the break would require a response before the subsequent access would be allowed.

Step 1. C opens a test file for reading and writing.

Step 2. C requests a Level I oplock on the file.

Step 3. The file should be written to and read from by C, this should succeed.

Step 4. C closes the file.

Step 5. The IRP from step 2 should complete indicating the Level I oplock is broken. The Information will show FILE_OPLOCK_BROKEN_TO_NONE.

Step 6. D opens the same test file for reading and writing. This should not block since the oplock has been deleted from the system.

Step 7. D requests and receives a Level II oplock on the file.

Step 8. The file should be read from by D, this should succeed.

Step 9. D closes the file.

Step 10. The IRP from step 7 should complete indicating the Level II oplock is broken. The Information will show FILE_OPLOCK_BROKEN_TO_NONE.

OplockRequestIITest

Multiple files can maintain level II oplocks on a file. This allows efficient, cached access by multiple readers.

Step 1. C opens a test file for reading and writing.

Step 2. C requests a Level II oplock on the file using the FSCTL_REQUEST_OPLOCK_LEVEL_II control operation.

Step 3. The file should be read from by C, this should succeed.

Step 4. D opens a test file for reading and writing.

Step 5. D requests a Level II oplock on the file using the FSCTL_REQUEST_OPLOCK_LEVEL_II control operation.

Step 6. C should be able to do cached reads from the file.

Step 7. D should be able to do cached reads from the file.

Step 8. C and D close the file.

OplockIIOpenBreakingTest

A level II oplock can be broken with a subsequent open. If the open is for read and write access, the level II oplock will be broken to none.

Step 1. C opens a test file for reading and writing.

Step 2. C requests a Level II oplock on the file.

Step 3. The file should be read from by C, this should succeed.

Step 4. D opens the test file for reading and writing, this

should block since the file has an open oplock.

Step 5. The level II oplock obtained in step 2 will be broken.

Step 6. The blocked open from step 4 should now become unblocked.

Step 7. C and D close the file.


TD-21.11 ChangeNotification File System Test Group

ChangeNotification Test Group Introduction

There are many combinations of FILTERS, CAUSES, and ACTIONS. The notification events table is used for a coverage test of all expected notification behavior. A file handle is opened in the test directory and a thread is created that will write to the file. Meanwhile in the main thread the write is waited upon for 4 seconds, if the write does not occur a timeout will happen. When the write does occur the event is triggered and the test will make sure the correct ACTION was reported. The following tests make up this group:

NotificationCleanupAttribTest

NotificationCleanupFileSizeTest

NotificationCloseTest

NotificationDeleteTest

NotificationFilenameTest

NotificationFlushWriteTest

NotificationNonDirectoryTest

NotificationSecurityTest

NotificationCleanupAttribTest

NotificationCleanupFileSizeTest

NotificationCloseTest

When an open file handle is closed, all pending notifications should be completed. A file handle is opened in the test directory and a thread is created that will close the file handle. Meanwhile in the main thread the close of the file handle is waited upon for 4 seconds, if the file handle is not closed in the time allotted a timeout will happen. All notification events should complete.

NotificationDeleteTest

When a directory is actually deleted, or marked for deletion, all pending notifications on changes in that directory must be completed. A file handle is opened in the test directory and a thread is created that will mark the file for deletion and then close the file handle (this close should then delete the file). Meanwhile in the main thread the delete of the file is waited upon for 4 seconds, if the delete does not occur a timeout will happen. When the delete does occur the event is triggered and the test will make sure the correct ACTION was reported. This test is then repeated, but instead of deleting the file in a separate thread, it is done in the main thread. When the notification is waited upon a STATUS DELETE PENDING should come back.

NotificationFilenameTest

Any changes in the filenames in a directory or subtree can be used to trigger a notification event. This includes renames, creations and deletions. First a file handle is opened in the test directory and a thread is created that will rename the file. Meanwhile in the main thread, the renaming of the file is waited upon for 4 seconds, if the notification doesn’t happen an error has occurred. When the rename does occur the event is triggered and the test will make sure the correct ACTION was reported. This test is repeated two more times, once with a file that is created in a separate thread; and then with a file that is deleted in a separate thread.

NotificationFlushWriteTest

NotificationNonDirectoryTest

The only way a notification can occur is if a directory handle is supplied to the notification change function. A call made with any other function should return an invalid parameter error. First a file handle is opened in the test directory and a thread is created that will write to the file. Meanwhile in the main thread the write of the file is waited upon for 4 seconds, if the notification doesn’t happen an error has occurred. This test is repeated but this time a file handle is supplied to the notification function, this should return back with an invalid parameter error.

NotificationSecurityTest

Any changes in the security descriptors of a file in a directory or subtree can be used to trigger a notification event. A file handle is opened in the test directory and a thread is created that will change the security descriptors of the file. Meanwhile in the main thread, the changing of the security descriptors of the file is waited upon for 4 seconds, if the notification doesn’t happen an error has occurred. When the security descriptor change does occur the event is triggered and the test will make sure the correct ACTION was reported.


TD-21.12 DeviceControl File System Test

DeviceIOControlTest

The create file function is used to open a file system related device object such as a partition or floppy device. Device I/O commands are passed through the file system to the device driver directly. The "\DosDevices\?: device is opened where ?: is a DOS drive letter for the volume under test. This test will issue a Device I/O Control command, a successful completion of the command and inspection of the returned information for accuracy will verify the path through the file system driver to the underlying device driver. This test is repeated using APC completion to help detect file system bugs in request completion.


TD-21.13 FileSystemControlVolume File System Test Group

FileSystemControlVolume Test Group Introduction

ControlLockVolumeTest

ControlLockVolumeFlushTest

ControlUnlockVolumeTest

ControlDismountVolumeTest

VolumeMountedTest

MountedDirtyTest

InvalidateVolumesTest

MountVerifyVolumeTest

ControlDismountVolumeTest

Dismounting a volume disconnects a volume object from its associated file system driver. This can be used when converting volumes, as in the FAT to NTFS converter. The volume starts out as FAT, is dismounted, formatted for NTFS, and then remounted. When it is remounted it will attach to the NTFS driver. The test for dismounting involves being able to see a mount request to the volume. That is necessary because the first reference to the volume after it is dismounted will usually mount the volume back up. The mounting can be observed by the File System Control. Note that the volume can only be dismounted if it is locked. A test volume handle is opened and a dismount is issued to it. Next a open is attempted on a file on the test volume. This should fail with an access denied error, but this open attempt will remount the volume. So next a dismount is issued again to the test volume and this should succeed.

ControlLockVolumeTest

(NOTE: This text describes ControlLockUnlock as ONE test. Needs to be rewritten as TWO tests: ControlLockVol and ControlUnlockVol,(see below).)

The File System I/O Control interface can be used to lock the volume. The control file function call gets a handle to an opened volume as a parameter. There are two things that need to be tested. First, a volume can only be locked if there are no other open handles on the volume. This test will have to be performed on a non-system containing volume. First a volume is locked then unlocked using the control file function. Next the open volume handle is closed and a file handle is opened for a file on the test volume. An open is attempted on the test volume, but this should fail because there is an open file handle, if this succeeds the volume handle and file handles are closed. Next the volume handle is opened again and a lock is issued to the volume. Next files and directory opens are attempted on the locked volume. These attempts should fail with access denied errors. Next files and directories are opened as a relative handle, these attempts should also fail with access denied errors. The next thing that is test is the flushing of the cache before the volume is locked. This is done by getting the volume statistics (specifically the read/write counters). Then opening up a couple of files on the test volume and doing read and write operations on those files. After the read/write operations are performed the volume statistics are again checked to see if they were updated. In the next part of the test a lock is issued to an already locked volume; this attempt should fail with an access denied error. The volume is issued an unlock now and then the lock is issued again. This should return a success.

ControlUnlockVolumeTest

VolumeMountedTest

The File System Control checks to see if a volume is mounted. This can be used in conjunction with the dismount control. First the test volume handle is opened and a dismount is issued to it. Next the File System Control to check if the volume is mounted is issued, for NTFS this should come back with a success; but on FAT volumes this will return the wrong volume error.

MountedDirtyTest

This File System Control permanently marks a volume as permanently dirty. This is done when there has been a corruption detected in the meta data. First the test volume is opened and the File System Control is issued that will mark the volume dirty. This test is not complete until a reboot is performed and the chkdsk program gets initiated.

InvalidateVolumesTest

The File System control that invalidates volumes will search for all the volumes mounted on the same real device and marks them all bad. This prevents their further use in the system, as the only operations that can be done on such handles is cleanup and close. First two test files are opened on the test volume. Next the test volume itself is opened and an invalidate volumes control is issued to it. A read is performed on both test files and these attempts should return with the error invalid handle. Next the file handles are closed and then reopened again. The reads are attempted and this time they should succeed.

MountVerifyVolumesTest

Mounting is tested implicitly by many of the tests and the test groups. In this test multiple files are opened on a removable media volume. The removable media is replaced with new media. The error wrong volume will be returned when the handles to the opened files are used to access the files. The original removable media has some files modified with new file sizes. A success will be returned when the handles to the opened files are used to access untouched files. The error file invalid will be returned when the handles to the files, which had modified file sizes, are used to access the files.

ControlLockVolumeFlushTest


TD-21.14 FileSystemControlGeneral File System Test Group

FileSystemControlGeneral Test Group Introduction

QueryRetrievalPointersTest

GetRetrievalPointersTest

SetCompressionTest

GetStatisticsTest

PathNameValidTest

GetVolumeBitmapTest

MoveFileTest

AllowExtendedDASDTest

QueryRetrievalPointersTest

This is only used when a new page file is created. The retrieval pointers are queried from the file system for the file so that they can be used later in writing the crash dump to the paging file. This test has not been implemented.

GetRetrievalPointersTest

The retrieval pointers consist of a list of extents. An extent is a VCN to LCN mapping. This test first creates a file and writes data to the file. Next the retrieval pointers are obtained by using FSCTL_GET_RETRIEVAL_POINTERS. Additional data is appended to the end of the file. The retrieval pointers are again obtained using the FSCTL. The additional VCN to LCN mapping (for the added clusters) is then observed.

SetCompressionTest

The File System Control can be used to compress an individual file on the volume if the File System supports this feature. First a query is performed on the file system to see if it supports file compression. If the file system supports compression, a test file is opened and a checksum is performed on an uncompressed file. Next a File System Control is issued to the uncompressed file handle to compress it. The file size is checked to make sure it is less than the file size of the uncompressed file. Next the file handle is closed then reopened again. Now the File System Control to compress is issued again, this should uncompress the file. The file size is checked to make sure that it is the same as it was prior to the compression. The checksum is performed and the result is compared to the checksum of the file prior to compression, these values should be equal.

GetStatisticsTest

The File System Control can be used to return the filesystem performance counters for the volume referred to. This test is performed by opening up a volume handle then issuing the file system control that will get the volume statistics. The volume handle is then closed and two test files are opened on the volume. After a few read and write operations are performed on these test files, the file handles are then closed. The volume is then opened again and the statistics are retrieved. The read and write counters are then checked to see that each counter incremented by known increments.

PathNameValidTest

Note that this test is only supported on Fat Compatible Volumes. This File System Control checks a pathname for valid characters, leading backslashes, and for wildcards. It passes the string to the file system to check. This is entirely dependent on the syntax of the file system path names. A volume handle is opened and two test pathnames are checked. The first pathname is a valid pathname and the second pathname checked is an invalid pathname.

GetVolumeBitmapTest

The volume bitmap is a sequence of bytes that indicate a mapping of used and unused clusters. Each cluster is mapped to a single bit in this bitmap. This test exercises the FSCTL and does a simple test of the bitmap. The volume is opened and the bitmap is obtained. The number of allocated and unallocated clusters is counted. Next a file is opened on the volume and a significant amount of data (1Mbyte) is written to the file. The bitmap is again obtained. The allocated clusters count should increase by the amount necessary for the new file.

MoveFileTest

The File System Control move file information class will move the logical clusters used by a file to new logical clusters on the volume. A file is created and written with a known data pattern. The initial retrieval pointers are queried using FSCTL_GET_RETRIEVAL_POINTERS. Next, the file’s clusters are moved using FSCTL_MOVE_FILE. The new retrieval pointers are queried. The expected change in the retrieval pointers is verified. The data is read from the file and checked for consistency.

AllowExtendedDASDTest

The File System Control, allow extended DASD I/O, specifies whether a DASD handle can be used to read/write beyond the end of the volume. A test volume is opened and a read is performed starting the very end of the volume. This read is expected to return back with a end of file error. Next a file system control, allow extended DASD I/O is issued to the volume. A second read is performed and this time reading at the very end of the volume should return back with a success.


TD-21.15 ReadWrite File System Test Group

ReadWrite Test Group Introduction

ReadWriteTest

ReadWriteCoherencyTest

WriteThroughTest

WriteThroughSyncTest

AppendDataTest

AtomicSeekReadTest

ZeroLengthIOTest

ReadWriteRangeTest

EventAsyncIOTest

APCSynchRWTest

ZeroOnExtendTest

ReadWriteTest

This will test the reading from and writing to files managed by the file system. First a synchronous file handle is opened to the test file and a buffer full of known data is written to the test file. Next the data is read from the file and compared to the known data to see if it matches. If the data matches, the file pointer is reset to the beginning of the test file and the data is read again, this time the parameter FILE_USE_FILE_POINTER_POSITION is specified as an offset to the read function. The handle is then closed. The test file is once again opened with a synchronous file handle and the data is read and checked once again. The file handle is then closed. A synchronous file handle is once again opened to the test file. A buffer full of known data is written to the test file, with the FILE_WRITE_TO_END_OF_FILE offset being specified to the write function. This should append the data to the end of the test file. The file is read from and the data is checked. The file handle is then closed. Lastly a asynchronous file handle is opened to the test file and data is read from the file. A query is performed to make sure that the file pointer position did not change. The test is complete.

ReadWriteCoherencyTest

The system maintains cache coherency for open files. Two handles are opened for the test file used in this test, the first handle opens the file with caching disabled and the second handle opens the file with caching enabled. First some data is written out to the file using the non-caching handle, this data is read back and checked using the caching handle. Second some data is written out to the file using the caching handle, this data is read back and checked using the non-caching handle. The data checked for both should be consistent. This test is repeated for an asynchronous handle.

WriteThroughTest

A file can be opened with write through caching. Read operations are cached as normal, but write operations will update the cache and write the changed data out to the storage device before they complete. First a test file is opened with write through caching enabled. A region of the file is read from to ensure that data is cached. The same region is written to and the volume read/write stats are checked to make sure they are updated. The region is read from again and the data is verified to make sure it has been updated. The test is repeated for an asynchronous handle.

WriteThroughSyncTest

AppendDataTest

This tests the appending of data to an open file that is opened with the append data access flag set. A file is opened with the append data access flag set. Data is then appended to the file and the new end of file information and allocation size are checked to verify it has been updated in accordance with the append data. A read is performed on the file to check that the original data as well as the appended data is correct.

AtomicSeekReadTest

The byte offset into the file can be specified to the read function. This byte offset performs the equivalent to a seek before the read. To test this a known data pattern is written to the test file. The data is then verified by reading the file at several different points by specifying the byte offset to the read function.

ZeroLengthIOTest

If an IO operation is specified with a zero byte length, the file offset should not be updated. In addition zero length extending or beyond EOF should be success no-ops. A test file is opened and the current file offset is recorded. The read and write operations are performed with a new offset and a non-zero byte length. The new current file offset is recorded and checked to make sure it changed with respect to the read and write calls. The read and write operations are performed again with a new offset, but a 0 byte length. The new current file offset is recorded and made sure it didn’t change. This test is repeated with a file offset that is beyond the end of the test file.

ReadWriteRangeTest

If a read operation is specified at an offset that is beyond the end of the file, the end of file error is returned. If the IO operation starts at a valid offset within the file, but the range causes a read/write off the end of the file, a success is returned along with the number of bytes transferred. Write operations will extend the file. A test file is opened and a read is performed at an offset that is beyond the current end of file. The end of file error is expected. Next a read is performed again but with a byte offset near the end of the file and a byte length for reading that extends off the end of the file. A success is expected and the actual number of bytes read is verified. This test is repeated for the write operation. When writing with an offset near the end of file and specifying a byte length that extends off the end of file, the end of file pointer will increase.

EventAsyncIOTest

The read and write functions can perform asynchronous IO. If an operation cannot proceed immediately, the calls may return a status pending. A test file is opened with an asynchronous file handle. A read and write operation are performed on the test file and a status pending is expected to be returned. Both the read and write operations are waited upon for completion.

APCSynchRWTest

The read and write functions can perform asynchronous IO using APC. If an operation cannot proceed immediately, for example a file object cannot be locked for exclusive access because another thread has the lock, the calls will return a status pending. If an APC is specified, that call will be made when the IO completes. A test file is opened with an asynchronous file handle. A write operation is performed on the test file, with an APC routine being specified for the write. The APC will set the event when the write completes. This completion is waited upon in the main thread. This test is repeated for the read operation.

ZeroOnExtendTest

If a file is extended either by setting the end of file pointer through the NT set function or by writing beyond the end of the file, the contents of the file is zeroed for security purposes. First a test file is opened with caching enabled. The NT set function is used to set the End of File pointer to a value larger than the current file. The data from the file is read back and verified, the data from the beginning of the file to the old end of file pointer should be original data, and the data from the old end of file pointer to the new end of file pointer should all be zero. Next the write function is used to write data at an offset beyond the end of the file. The data is read back and verified, the data from the beginning to the old end of file pointer is all original data, the data from the old end of file pointer to the start of write offset should all be zero, and the data from the start of the write offset to the end of the file should all be the new data just written. This test is repeated for non-cached IO.


TD-21.16 SectionCaching File System Test Group

SectionsCaching Test Group Introduction

MaintainSectionMappingTest

DataImageCoherencyTest

ExistingUserMappingTest

TruncateWithUserMappingTest

ExtendingWithUserMappingTest

FlushBuffersTest

FlushBuffersRootTest

FlushBuffersVolumeTest

ExtendingWithUserMappingTest

A file can be extended when a user mapping exists. The new extended region should be initialized with 0's.

Step 1. A test file is opened, a user mapped section is created, and a view created.

Step 2. The file handle is closed.

Step 3. The test file is again opened with a call to NtCreateFile() with the FILE_WRITE_DATA and FILE_READ_DATA desired access specified.

Step 4. The file is extended with a Set Information File -> FileEndOfFileInformation call. The End Of File is specified to be some value larger than the current end of file.

Step 5. The Set Information File call should succeed.

Step 6. Another view is created on the extended region.

Step 7. The file contents are read. The extended region’s view should contain all 0s. The original region should have valid data.

FlushBuffersTest

This tests involves the IRP_MJ_FLUSH_BUFFERS, IRP on a file object. A file is first created with the FILE_ATTRIBUTE_TEMPORARY flag set. Data is written to the file. Statistics on the volume are obtained. The open file handle is passed in a call to NtFlushBuffersFile. The statistics are again obtained. The number of bytes written to the block device, the end of file pointer, the last write time should be updated from the flush.

FlushBuffersRootTest

This tests involves the IRP_MJ_FLUSH_BUFFERS, IRP on a root directory object. Several files, in several subdirectories, are created with the FILE_ATTRIBUTE_TEMPORARY flag set. Data is written to the files. The root directory of the volume is opened. Statistics on the volume are obtained. The open root directory handle is passed in a call to NtFlushBuffersFile. The statistics are again obtained. The number of bytes written to the block device, the end of file pointer, the last write time should be updated on all files, from the flush.

FlushBuffersVolumeTest

This test involves the IRP_MJ_FLUSH_BUFFERS, IRP on a volume object. Several files, in several subdirectories, are created with the FILE_ATTRIBUTE_TEMPORARY flag set. Data is written to the files. The volume is then directly opened. Statistics on the volume are obtained. The open volume handle is passed in a call to NtFlushBuffersFile. The statistics are again obtained. The number of bytes written to the block device, the end of file pointer, and last write time should be updated from the flush on all volumes.

MaintainSectionMappingTest

A user mapped section is created with an open file handle. The file handle can be closed and the user mapped section maintained.

Step 1. A test file is opened.

Step 2. A user mapped section/mapped view are created with the open handle.

Step 3. The handle is closed.

Step 4. A view on the section is used to verify the file contents are still accessible.

Step 5. Another attempt is made at opening the test file with 0 share access (nothing is shared).

Step 6. Write some data to the opened test file.

Step 7. Verify the written data is present in the mapped section.

Step 8. The file is closed.

DataImageCoherencyTest

The image section must be kept consistent with the data section. This test first creates a file containing an executable file. The file is then run, causing the executable image to be mapped into an image section. The cached data section should be flushed to disk before the image is faulted in.

Step 1. A known working executable is opened for reading.

Step 2. A new file is created with write access (filename = temp.exe).

Step 3. The contents of the first file are copied into the new file with NtReadFile() and NtWriteFile().

Step 4. The handle to the files are closed.

Step 5. The temp.exe executable file is run as in the WIN32 CreateProcess call.

Step 6. Proper execution of the file is verified, as well as the flush of dirty data to the disk.

ExistingUserMappingTest

A file cannot be superceded or overwritten when a view on a user mapping exists.

Step 1. A test file is opened, a user mapped section is created, and a view mapped.

Step 2. The handle to the test file is closed.

Step 3. The test file is again opened with a call to NtCreateFile(). The FILE_OVERWRITE disposition is specified.

Step 4. The open should fail with STATUS_USER_MAPPED_FILE.

Step 5. The test file is again opened with a call to NtCreateFile(). The FILE_SUPERSEDE disposition is specified.

Step 6. The open should also fail with STATUS_USER_MAPPED_FILE.

TruncateWithUserMappingTest

A file cannot be truncated when a user mapping exists.

Step 1. A test file is opened, a user mapped section is created, and a view created.

Step 2. The handle to the test file is closed.

Step 3. The test file is again opened with a call to NtCreateFile() with the FILE_WRITE_DATA access right specified.

Step 4. The file is truncated with a Set Information File -> FileEndOfFileInformation call. The EndOfFile is specified to be some value smaller than the current end of file.

Step 5. The Set Information File call should return the error STATUS_USER_MAPPED_FILE.

Step 6. The test is repeated with Set Information File -> AllocationInformation. By reducing the allocation size on the file below the current end of file, the file is truncated.


TD-21.17 Security File System Test Group

Security Test Group Introduction

SetOwnerSecurityTest

SetDaclSecurityTest

SetGroupSecurityTest

SetSaclSecurityTest

AuditDelSecurityTest

AuditPermSecurityTest

AuditOwnerSecurityTest

DirectoryTraverseTest

SetOwnerSecurityTest

This test requires that the file system being tested is NTFS; and that a test user is created with Users rights. This test user is specified at the command line when running with the /u option. The password for this user must be the same as the user name (e.g. Username: JuiceGuy Password: JuiceGuy). The first thing that is done in this test is to start another process, as the test user. This process will create the test file used in this test and ownership will belong to the test user. Next the test file is opened by the current user (the user running the test). The user SID is changed so that the current user will take ownership of the file. The file is then queried for its Owner SID to verify that the current owner did take ownership of the file.

SetDaclSecurityTest

If the file system supports security on a file and directory basis, the Object Manager will use the set security function to set the security descriptor on the file or directory. A test file is first opened and the security DACL is changed for the file to only allow read operations for the Administrator. The file is then queried for its Security DACL information; the results from this query are compared to what was set on the file. If both Security DACLs match, the original DACL is reset to allow the test file to be deleted during cleanup.

SetGroupSecurityTest

This test requires that the file system being tested is NTFS; and that a test user is created with Users rights. The test file is first opened and the Security Group SID is changed so that the Administrators group has control of this file. The file is then queried for its Security Group SID and this is compared to the Group SID that it was set to.

SetSaclSecurityTest

This test requires the file system being tested is NTFS. First the Security Privilege is enabled in order to access the SACL. A SACL list allows you to audit operations performed on a file. The test file is opened and the SACL list is set to audit all Read operations performed on the test file. Next the file is opened again and queried for its SACL information. This is compared to what the SACL was set to earlier (audit all Read operations). If both lists match the test is passed.

AuditDelSecurityTest

This test requires the file system being tested is NTFS. First the Security Privilege is enabled in order to access the SACL. The test file is then opened and the SACL is set to audit the deletion of the file; the file is closed and the security changes are now enabled. The file is then opened and marked for deletion upon close. Once the file is closed the Event Log should log the deletion of the file. The file is closed and the Event Log is opened and a search is done through the Event Log for the deletion of the test file. If this event has taken place the test has passed.

AuditPermSecurityTest

This test requires that the file system being tested is NTFS. First the Security Privilege is enabled in order to access the SACL. The test file is then opened and the SACL is set to audit the change of security permissions (the DACL), the file is closed and the security changes now are enabled. The file is then reopened and the DACL is changed; this change should cause the event to be logged in the Event Log. The Event Log is searched for this event, if it is there the test is passed and the original DACL information is reset.

AuditOwnerSecurityTest

This test requires that the file system being tested is NTFS; and that a test user is created with Users rights. This test user is specified at the command line with the /u option. The password for this user must be the same as the user name (e.g. UserName: JuiceGuy Password: JuiceGuy). The first thing that is done in this test is to start another process, as the test user. This process will create the test file used in this test and ownership will belong to the test user. Next the Security Privilege is enabled in order to access the SACL. The test file is then opened and the SACL is set to audit the change of the owner of the test file; the file is then closed and the security changes are now enabled. The file is opened and the current user takes ownership of the file. This should set an even in the Event Log. The Event Log is searched for this event, and if present, the test is passed.

DirectoryTraverseTest

The default installation of NT 4.0 enables Bypass Traverse Checking for all users on the system. This allows a user to access a directory (which maintains a legal ACL for the user) that is a subdirectory under a path that contains directories that do not maintain a legal ACL for the user. This test requires that the file system being tested is NTFS; and that a test user is created with Users rights. There are 3 directories in this test (the 2nd directory is a subdirectory of the first and the 3rd directory is a subdirectory of the 2nd). The 1st directory is opened and the DACL is changed so that only administrators can perform operation on it; the same is done with the 2nd. Next a second thread is initiated that will log in the test user and try to create a file in the 1st directory; this attempt should fail. The same is repeated with the 2nd directory. This is repeated on the 3rd directory as well, but this time a success is expected as a return if the Bypass Traverse Checking is enabled; access denied is expected if this user privilege is not enabled.


TD-21.18 ObjectID File System Test Group

ObjectID Test Group Introduction

Object IDs are used to uniquely identify files and directories on a volume. This feature allows files or directories to be referenced by a unique ID, which is preserved even if the file or directory is renamed. The file or directory may be opened by its Object ID, and its path name queried. The following tests are part of this Group:

GetObjectIDTest

SetObjectIDTest

SetUniqueObjectIDDuplicateNameTest

SetUniqueObjectIDNameCollisionTest

DeleteObjectIDTest

CreateOrGetObjectIDTest

ObjectOpenByIDTest

NameInformationExTest

SetExtendedObjectIDTest

SetObjectIDVolumeTest

GetObjectIDVolumeTest

EnumObjectIDTest

NotificationObjectIDAddedTest

NotificationObjectIDRemovedTest

NotificationObjectIDDeletedTest

NotificationObjectIDNotTunnelledTest

NotificationObjectIDTunnelledCollisionTest

TunnelObjectIDTest

GetObjectIDVolumeTest

The NtQueryVolumeInformationFile API with FileFsObjectInformation class can be used to retrieve a volume's Object ID. If the volume does not have an Object ID, the operation fails with STATUS_OBJECT_NAME_NOT_FOUND. Otherwise, the existing Object ID is retrieved and the operation succeeds.

NameInformationExTest

The NtQueryInformationFile with the FileNameInformation class can be used to retrieve the full path of a file or directory through Object IDs. This is verified by opening a file or directory by its Object ID, and querying its file name. Note that directory traverse privilege is required.

ObjectOpenByIDTest

The NtCreateFile with FILE_OPEN_BY_FILE_ID can be used to open a file or directory by Object ID. Similar to the semi-unique 64Bit file index, the Object ID is used as the file name of length sizeof(OBJECTID).

NotificationObjectIDRemovedTest

Changes to the (\$Extend\$ObjId:$O:$INDEX_ALLOCATION) object index can be observed using NtNotifyChangeDirectoryFile(). The FILE_OBJECTID_INFORMATION structure is returned. The following notifications are possible:

FILE_ACTION_ADDED an object ID has been added to the index

FILE_ACTION_REMOVED an object ID has been removed from the index via FSCTL_DELETE_OBJECT_ID

FILE_ACTION_REMOVED_BY_DELETE an object ID has been removed from the index because the file with which it was associated was deleted

FILE_ACTION_ID_NOT_TUNNELLED an object ID could not be restored from the tunnel cache because the ID was in use by another file on the volume

FILE_ACTION_TUNNELLED_ID_COLLISION an object ID could not be restored from the tunnel cache because the destination file already had an object ID

This test verifies the FILE_ACTION_REMOVED notification.

SetExtendedObjectIDTest

The FSCTL_SET_OBJECT_ID_EXTENDED is used to set the extended information portion of a file or directory's Object ID. This is verified by using the FSCTL_GET_OBJECT_ID to retrieve this extended information.

SetObjectIDTest

An object ID can be set on a file or directory with the FSCTL_SET_OBJECT_ID control code and the FILE_OBJECTID_BUFFER, provided the user attempting the operation has BACKUP/RESTORE privileges on the system. This means that SE_RESTORE_NAME privilege must be enabled on the user process and the file or directory handle must be opened with BACKUP/RESTORE intent. Otherwise, STATUS_ACCESS_DENIED is returned.

This is verified by opening a file or directory without the FILE_OPEN_FOR_BACKUP_INTENT create flag and attempting the FSCTL_SET_OBJECT_ID operation. The operation should fail with STATUS_ACCESS_DENIED.

SetObjectIDVolumeTest

The NtSetVolumeInformationFile API with FileFsObjectInformation class can be used to set an Object ID on a volume. If the volume does not have an Object ID, the new Object ID is set and the operation succeeds. If the volume already has an Object ID, the old Object ID is replaced with the new Object ID and the operation succeeds. However, if a file or directory already has the same Object ID, the operation fails with STATUS_DUPLICATE_NAME.

TunnelObjectIDTest

The Tunneling of Object IDs is the process of caching the Object ID of a file or directory. If a file or directory that has an object ID is deleted, and if another file or directory that does not have an object ID is renamed to the file or directory just deleted, the renamed file will have an object ID. It is said that the object ID has been tunnelled (from the deleted file to the renamed file).

NotificationObjectIDNotTunnelledTest

Changes to the (\$Extend\$ObjId:$O:$INDEX_ALLOCATION) object index can be observed using NtNotifyChangeDirectoryFile(). The FILE_OBJECTID_INFORMATION structure is returned. The following notifications are possible:

FILE_ACTION_ADDED an object ID has been added to the index

FILE_ACTION_REMOVED an object ID has been removed from the index via FSCTL_DELETE_OBJECT_ID

FILE_ACTION_REMOVED_BY_DELETE an object ID has been removed from the index because

the file with which it was associated was deleted

FILE_ACTION_ID_NOT_TUNNELLED an object ID could not be restored from the tunnel cache because the ID was in use by another file on the volume

FILE_ACTION_TUNNELLED_ID_COLLISION an object ID could not be restored from the tunnel cache

because the destination file already had an objectid

This test verifies the FILE_ACTION_ID_NOT_TUNNELLED notification.

SetUniqueObjectIDNameCollisionTest

The Object IDs should be unique for each file and directory on the volume. This is verified by using FSCTL_SET_OBJECT_ID to try setting an object ID on a file or directory that already has an object ID. The operation should fail with STATUS_OBJECT_NAME_COLLISION.

SetUniqueObjectIDDuplicateNameTest

The Object IDs should be unique for each file and directory on the volume. This is verified by using FSCTL_SET_OBJECT_ID to try setting an object ID that is known to already exist on the volume. The operation should fail with STATUS_DUPLICATE_NAME if the file or directory on which the operation is attempted does not have an object ID.

NotificationObjectIDAddedTest

Changes to the (\$Extend\$ObjId:$O:$INDEX_ALLOCATION) object index can be observed using NtNotifyChangeDirectoryFile(). The FILE_OBJECTID_INFORMATION structure is returned. The following notifications are possible:

FILE_ACTION_ADDED an object ID has been added to the index

FILE_ACTION_REMOVED an object ID has been removed from the index via FSCTL_DELETE_OBJECT_ID

FILE_ACTION_REMOVED_BY_DELETE an object ID has been removed from the index because the file with which it was assosiated was deleted

FILE_ACTION_ID_NOT_TUNNELLED an object ID could not be restored from the tunnel cache because the ID was in use by another file on the volume

FILE_ACTION_TUNNELLED_ID_COLLISION an object ID could not be restored from the tunnel cache because the destination file already had an object ID

This test verifies the FILE_ACTION_ADDED notification.

CreateOrGetObjectIDTest

The FSCTL_CREATE_OR_GET_OBJECT_ID can be used to return the existing ObjectID or generate a new object ID for the file or directory. This is verified by attempting the FSCTL_CREATE_OR_GET_OBJECT_ID operation on a file or directory that has a known Object ID. The operation should succeed and the known Object ID should be returned in a FILE_OBJECTID_BUFFER structure. Then, the Object ID is deleted from the file with FSCTL_DELETE_OBJECT_ID. Finally, the FSCTL_CREATE_OR_GET_OBJECT_ID attempt is made on the same file. The operation should succeed and return a newly created Object ID in the FILE_OBJECTID_BUFFER.

NotificationObjectIDTunnelledCollisionTest

Changes to the (\$Extend\$ObjId:$O:$INDEX_ALLOCATION) object index can be observed using NtNotifyChangeDirectoryFile(). The FILE_OBJECTID_INFORMATION structure is returned. The following notifications are possible:

FILE_ACTION_ADDED an object ID has been added to the index

FILE_ACTION_REMOVED an object ID has been removed from the index via FSCTL_DELETE_OBJECT_ID

FILE_ACTION_REMOVED_BY_DELETE an object ID has been removed from the index because the file with which it was associated was deleted

FILE_ACTION_ID_NOT_TUNNELLED an object ID could not be restored from the tunnel cache because the ID was in use by another file on the volume

FILE_ACTION_TUNNELLED_ID_COLLISION an object ID could not be restored from the tunnel cache because the destination file already had an object ID

This test verifies the FILE_ACTION_TUNNELLED_ID_COLLISION notification.

DeleteObjectIDTest

An existing Object ID can be removed from a file or directory using FSCTL_DELETE_OBJECT_ID, provided the handle is opened with RESTORE intent and WRITE access. This is verified by attempting to delete the Object ID of a file or directory with the handle opened without the FILE_OPEN_FOR_BACKUP_INTENT option flag nor WRITE access. The operation should fail with STATUS_ACCESS_DENIED. Then, the operation is repeated with a handle opened with the FILE_OPEN_FOR_BACKUP_INTENT option flag and WRITE access. The operation should succeed.

NotificationObjectIDDeletedTest

Changes to the (\$Extend\$ObjId:$O:$INDEX_ALLOCATION) object index can be observed using NtNotifyChangeDirectoryFile(). The FILE_OBJECTID_INFORMATION structure is returned. The following notifications are possible:

FILE_ACTION_ADDED An object ID has been added to the index

FILE_ACTION_REMOVED An object ID has been removed from the index via FSCTL_DELETE_OBJECT_ID

FILE_ACTION_REMOVED_BY_DELETE An object ID has been removed from the index because the file with which it was associated was deleted

FILE_ACTION_ID_NOT_TUNNELLED An object ID could not be restored from the tunnel cache because the ID was in use by another file on the volume

FILE_ACTION_TUNNELLED_ID_COLLISION An object ID could not be restored from the tunnel cache because the destination file already had an object ID

This test verifies the FILE_ACTION_REMOVED_BY_DELETE notification.

EnumObjectIDTest

The Object IDs on a volume can be queried with the NtQueryDirectoryFile() and FileObjectIdInformation class. A FILE_OBJECTID_INFORMATION structure is returned for each object. The name of the pseudo-directory to open is (\$Extend\$ObjId:$O:$INDEX_ALLOCATION).

GetObjectIDTest

The FSCTL_GET_OBJECT_ID and FILE_OBJECTID_BUFFER can be used to retrieve a file or directory's object ID. This is verified by setting the object ID on a file or directory, and retrieving the Object ID with the FSCTL_GET_OBJECT_ID operation. The same ID that was set should be returned.


TD-21.19 MountPoints File System Test Group

MountPoint Test Group Introduction

CreateDirectoryExDirectoryTest

CreateDirectoryExVolumeTest

DirectoryCycleOnReparseTest

DirectoryGraftTest

DirectoryGraftEmptyFileTest

DirectoryGraftEmptyTest

DirectoryGraftEmptyStreamTest

FileGraftTest

FileGraftStreamTest

LocalMountPointTest

CreateDirectoryExDirectoryTest

The purpose of this test is to copy a directory that contains a name graft. The reparse information should be copied with the special WIN32 CreateDirectoryEx call. The target directory contains a subdirectory and a file. Access to these through the copied reparse point is verified.

CreateDirectoryExVolumeTest

The purpose of this test is to create a volume mount point and then copy the directory containing the point. A special WIN32 API call CreateDirectoryEx should also copy the reparse information. A file and directory are known to exist on an alternate volume. The file and directory are opened through the copied volume mount point.

DirectoryCycleOnReparseTest

The purpose of this test is to attempt the legal operation of linking a lower child directory to its immediate parent and then traversing the self-referencing directory tree up to 16 times before an error status is returned. This limit is imposed by the I/O manager.

DirectoryGraftTest

The purpose of this test is to attempt name grafting on a directory. The target directory contains a subdirectory and a file. Access to these through the reparse point is verified.

DirectoryGraftEmptyFileTest

The purpose of this test is to attempt name grafting on a directory that contains a file. Name grafting requires an empty directory. The STATUS_DIRECTORY_NOT_EMPTY status return is verified.

DirectoryGraftEmptyTest

The purpose of this test is to attempt name grafting on a directory that contains a subdirectory. The STATUS_DIRECTORY_NOT_EMPTY status return is verified.

DirectoryGraftEmptyStreamTest

The purpose of this test is to attempt name grafting on a directory using a handle to a named data stream on a directory. Even though a named data stream on the directory was opened, this attempt returns STATUS_NOT_A_DIRECTORY.

FileGraftTest

The purpose of this test is to attempt name grafting on a file. A file is opened, and an attempt is made to set the IO_REPARSE_TAG_MOUNT_POINT reparse point with the file handle. On Windows 2000 ntfs volumes, this returns STATUS_NOT_A_DIRECTORY.

FileGraftStreamTest

The purpose of this test is to attempt name grafting on a named data stream of a file. A named data stream of file is opened, and an attempt is made to set the IO_REPARSE_TAG_MOUNT_POINT reparse point with the file handle. On Windows 2000 ntfs volumes, this returns STATUS_NOT_A_DIRECTORY.

LocalMountPointTest

The purpose of this test is to create a volume mount point and then exercise it. A file and directory are known to exist on an alternate volume. The file and directory are opened through the volume mount point.


TD-21.20 ReparsePoints File System Test Group

ReparsePoint Test Group Introduction

ChangeNotificationReparseTest

DeleteFileDirReparsePointTest

DelPointAccessDeniedTest

DelPointAttributeConflictTest

DelPointInvalidBufferSizeTest

DelPointInvalidParmTest

DelPointIoReparseDataInvalidTest

DelPointIoReparseTagInvalidTest

DelPointIoReparseTagMismatchTest

DelPointNotReparseTest

EnumReparsePointsTest

FileAttributeReparsePointTest

GetPointBufferSmallTest

GetPointInvalidParamTest

GetPointInvalidUserBufferTest

GetPointNotReparseTest

OpenReparsePointTest

QueryFileAttributeTagInfoTest

QueryFullAttributesReparseTest

SetPointAccessDeniedTest

SetPointAttributeConflictTest

SetPointDirectoryNotEmptyTest

SetPointEASNotSupportedTest

SetPointInvalidBufferSizeTest

SetPointInvalidParamTest

SetPointIoReparseDataInvalidTest

SetPointIoReparseTagInvalidTestSetPointIoReparseTagInvalidTest

SetPointIoReparseTagMismatchTest

SetPointDirectoryNotEmptyTest

This test validates the behavior of FSCTL_SET_REPARSE_POINT on a non-empty directory.

The code path that returns STATUS_DIRECTORY_NOT_EMPTY is exercised by attempting to set a reparse point on a non-empty directory. This operation is expected to fail with STATUS_DIRECTORY_NOT_EMPTY on NTFS5-compatible file systems.

EnumReparsePointsTest

This test verifies that the index (\$EXTEND\$Reparse:$R:$INDEX_ALLOCATION) can be used with NtQueryDirectoryFile() and that the FileReparsePointInformation class retrieves the reparse tag for a given file or directory with a reparse point. First, a reparse point is set on a file and directory. Then, the index is queried. The reparse tag information for the file and directory with a reparse point retrieved. This operation is expected to succeed on NTFS5-compatible file systems.

FileAttributeReparsePointTest

This test verifies that BASIC INFORMATION can be obtained from a file or directory with a reparse point. First, a reparse point is set on a file and directory. Then, the file or directory is queried for BASIC INFORMATION. The attribute field of the FILE_ATTRIBUTE_BASIC_INFORMATION structure is checked for FILE_ATTRIBUTE_REPARSE_POINT.

This operation is expected to succeed on NTFS5-compatible file systems.

GetPointBufferSmallTest

This test validates the behavior of the FSCTL_GET_REPARSE_POINT, which is used to get a reparse point set on a file or directory.

The code path that returns STATUS_BUFFER_TOO_SMALL is exercised by attempting to get a reparse point from a file or directory while using an output buffer length argument less than REPARSE_DATA_BUFFER_HEADER_SIZE. This operation is expected to fail with STATUS_BUFFER_TOO_SMALL on supported file systems.

GetPointNotReparseTest

This test validates the behavior of the FSCTL_GET_REPARSE_POINT, which is used to get a reparse point set on a file or directory.

The code path that returns STATUS_NOT_A_REPARSE_POINT is exercised by attempting to get a reparse point from a file or directory which has noprior reparse point set. This operation is expected to fail with STATUS_NOT_A_REPARSE_POINT on NTFS5-compatible file systems.

GetPointInvalidUserBufferTest

This test validates the behavior of the FSCTL_GET_REPARSE_POINT, which is used to get a reparse point set on a file or directory.

The code path that returns STATUS_INVALID_USER_BUFFER is exercised by attempting to get a reparse point from a file or directory while using NULL as a reparse buffer argument to the NtFsControlFile() API. This operation is expected to fail with STATUS_INVALID_USER_BUFFER on NTFS5-compatible file systems.

GetPointInvalidParamTest

This test validates the behavior of the FSCTL_GET_REPARSE_POINT, which is used to get a reparse point set on a file or directory.

The code path that returns STATUS_INVALID_PARAMETER is exercised by attempting to get a reparse point on a volume or by using an output buffer argument with the NtFsControlFile() API. The operation is expected to fail with STATUS_INVALID_PARAMETER n NTFS5-compatible file systems.

SetPointInvalidBufferSizeTest

This test validates the behavior of the FSCTL_SET_REPARSE_POINT, which is used to set a reparse point on a file or directory.

The code path that returns STATUS_INVALID_BUFFER_SIZE is exercised by attempting to set a reparse point on a file and directory while passing NULL as a reparse buffer argument to the NtFsControlFile() API. The operation is expected to fail with STATUS_INVALID_BUFFER_SIZE on NTFS5-compatible file systems.

SetPointInvalidParamTest

This test validates the behavior of the FSCTL_SET_REPARSE_POINT, which is used to set a reparse point on a file or directory.

The code path that returns STATUS_INVALID_PARAMETER is exercised by attempting to set a reparse point on a volume or by using an output buffer argument. The operation is expected to fail in both cases with STATUS_INVALID_PARAMETER on supported file systems.

SetPointIoReparseDataInvalidTest

This test validates the behavior of the FSCTL_SET_REPARSE_POINT, which is used to set a reparse point on a file or directory.

The code path that returns STATUS_IO_REPARSE_DATA_INVALID is exercised by using an input buffer length argument less than REPARSE_DATA_BUFFER_HEADER_SIZE, an input buffer length argument greater than MAX_REPARSE_DATA_BUFFER_SIZE, an input buffer length argument different than the reparse data buffer length, or a GUID equal to NULL (if ISV reparse tag). The operation is expected to fail in all of these cases with STATUS_IO_REPARSE_DATA_INVALID on NTFS5-compatible file systems.

ChangeNotificationReparseTest

This test verifies that the index (\$EXTEND\$Reparse:$R:$INDEX_ALLOCATION) can be used to wait for reparse point additions. First, a change notification is set on a volume index. Then, an event is created to wait for the addition of reparse points.

Next, a different thread sets a reparse point on a file to trigger the event. Meanwhile,the main thread waits for the event to occur. This operation is expected to fail with IFSTEST_TEST_PENDING_IO_TIMEOUT on NTFS5-compatible file sytems because it is not yet supported.

OpenReparsePointTest

This test verifies that a file or directory with a reparse point can be opened with the FILE_OPEN_REPARSE_POINT, which inhibits reparse behavior of the file or directory.

First, a reparse point is set on a file and directory. Then, an attempt is made to open the file and directory without using FILE_OPEN_REPARSE_POINT. The operation is expected to fail with STATUS_IO_REPARSE_TAG_NOT_HANDLED on NTFS5-compatible file systems.

Next, an attempt is made to open the file and directory while using FILE_OPEN_REPARSE_POINT. The operation is expected to succeed on NTFS5-compatible file systems.

QueryFullAttributesReparseTest

This test verifies that a file or directory with a reparse point can be queried using NtQueryFullAttributesFile() API, which returns a FILE_NETWORK_OPEN_INFORMATION structure. This operation is expected to succeed on NTFS5-compatible file systems, with the FILE_ATTRIBUTE_REPARSE_POINT attribute set in the attribute field of the returned structure.

QueryFileAttributeTagInfoTest

This test verifies that a file or directory with a reparse point can be queried for FileAttributeTagInformation. First, a reparse point is set on a file or directory. Then, the NtQueryInformationFile() API is used with theFileAttributeTagInformation class. This operation is expected to succeed on NTFS5-compatible file systems.

SetPointIoReparseTagInvalidTest

This test validates the behavior of the FSCTL_SET_REPARSE_POINT, which is used to set a reparse point on a file or directory.

The code path that returns STATUS_IO_REPARSE_TAG_INVALID is exercised by attempting to set a reparse point on a file or directory while using a reparse tag equal to IO_REPARSE_TAG_NSS, IO_REPARSE_TAG_RESERVED_ONE, IO_REPARSE_TAG_RESERVED_ZERO, or ~IO_REPARSE_TAG_VALID_VALUES. The operation is expected to fail in all of these cases with STATUS_IO_REPARSE_TAG_INVALID on NTFS5-compatible file systems.

SetPointIoReparseTagMismatchTest

The code path that returns STATUS_IO_REPARSE_TAG_MISMATCH is exercised by attempting to set a reparse point file or direcotry with a different reparse tag.

First, a reparse point is set on a file and directory with one reparse tag. Then, an attempt is made to overwrite the same file and directory while using a different reparse tag as argument.

The operation is expected to fail with STATUS_IO_REPARSE_TAG_MISMATCH on NTFS5-compatible

File systems.

DeleteFileDirReparsePointTest

This test verifies that a file or directory with a reparse point CANNOT be deleted with normal deletion semantics. First, a reparse point is set on a file and directory. Then, an attempt is made to delete the file and directory with NtDeleteFile() API. The file-delete operation should fail with STATUS_IO_REPARSE_TAG_NOT_HANDLED status on NTFS5-compatible file systems.

DelPointAccessDeniedTest

This test validates the behavior of the FSCTL_DELETE_REPARSE_POINT, which is used to delete a reparse point on a file or directory.

The code path that returns STATUS_ACCESS_DENIED is exercised by attempting to delete a reparse point on a file or directory with no WRITE access. The operation is expected to fail with STATUS_ACCESS_DENIED on NTFS5-compatible file systems.

DelPointAttributeConflictTest

This test validates the behavior of the FSCTL_DELETE_REPARSE_POINT, which is used to delete a reparse point on a file or directory.

The code path that returns STATUS_REPARSE_ATTRIBUTE_CONFLICT is exercised by attempting

First, a reparse point is set on a file and directory with one GUID. Then, an attempt to delete the reparse points on the same file and directory is made, but with a different GUID. The operation is expected to fail on NTFS5-compatible file systems with STATUS_REPARSE_ATTRIBUTE_CONFLICT.

DelPointInvalidBufferSizeTest

This test validates the behavior of the FSCTL_DELETE_REPARSE_POINT, which is used to delete a reparse point on a file or directory.

The code path that returns STATUS_INVALID_BUFFER_SIZE is exercised by attempting to delete a reparse point on a file or directory with a NULL reparse buffer.

First, a reparse point is set on a file and directory. Then, an attempt is made to delete the reparse point on the file and directory while passing NULL as a reparse buffer argument to the NtFsControlFile() API. The operation is expected to fail with STATUS_INVALID_BUFFER_SIZE on NTFS5-compatible file systems.

DelPointIoReparseDataInvalidTest

This test validates the behavior of the FSCTL_DELETE_REPARSE_POINT, which is used to delete a reparse point on a file or directory.

The code path that returns STATUS_IO_REPARSE_DATA_INVALID is exercised by using an input buffer length argument greater than REPARSE_DATA_BUFFER_HEADER_SIZE, an input buffer data length argument different than zero, or a buffer size argument different than the GUID header size (if ISV reparse tag). The operation is expected to fail in all of these cases with STATUS_IO_REPARSE_DATA_INVALID on NTFS5-compatible file systems.

DelPointInvalidParmTest

This test validates the behavior of the FSCTL_DELETE_REPARSE_POINT, which is used to delete a reparse point on a file or directory.

The code path that returns STATUS_INVALID_PARAMETER is exercised by attempting to delete a reparse point on a volume or by using an output buffer argument. The operation is expected to fail in both cases with STATUS_INVALID_PARAMETER on supported file systems.

DelPointIoReparseTagInvalidTest

This test validates the behavior of the FSCTL_DELETE_REPARSE_POINT, which is used to delete a reparse point on a file or directory.

The code path that returns STATUS_IO_REPARSE_TAG_INVALID is exercised by attempting to delete a reparse point on a file or directory while using a reparse tag equal to IO_REPARSE_TAG_RESERVED_ONE or IO_REPARSE_TAG_RESERVED_ZERO. The operation is expected to fail with STATUS_IO_REPARSE_TAG_INVALID on NTFS5-compatible file systems.

DelPointIoReparseTagMismatchTest

This test validates the behavior of the FSCTL_DELETE_REPARSE_POINT, which is used to delete a reparse point on a file or directory.

The code path that returns STATUS_IO_REPARSE_TAG_MISMATCH is exercised by attempting to delete a reparse point file or direcotry with a different reparse tag. First, a reparsepoint is set on a file and directory with one reparse tag. Then, an attempt is made to delete the same file and directory while using a different reparse tag as argument. The operation is expected to fail with STATUS_IO_REPARSE_TAG_MISMATCH on NTFS5-compatible file systems.

DelPointNotReparseTest

This test validates the behavior of the FSCTL_DELETE_REPARSE_POINT, which is used to delete a reparse point on a file or directory.

The code path that returns STATUS_NOT_A_REPARSE_POINT is exercised by attempting to delete a reparse point on a file or directory which has no prior reparse point set.The operation is expected to fail with STATUS_NOT_A_REPARSE_POINT on NTFS5-compatible file systems.

SetPointEASNotSupportedTest

This test validates the behavior of the FSCTL_DELETE_REPARSE_POINT, which is used to delete a reparse point on a file or directory.

The code path that returns STATUS_EAS_NOT_SUPPORTED is exercised by attempting to set a reparse point on a file or directory with extended attributes. The operation isexpected to fail with STATUS_EAS_NOT_SUPPORTED on NTFS5-compatible file systems because reparse points and extended attributes are mutually exclusive.

SetPointAccessDeniedTest

SetPointAttributeConflictTest


TD-21.21 SparseFiles File System Test Group

SparseFile Test Group Introduction

FileInformationSparseAttrTest

NonSparseZeroDataTest

ResetSparseAttrOverwriteTest

ResetSparseAttrSupersedeTest

SparseAllocatedRangesTest

SparseCompressedStreamTest

SparseMoveFileTest

SparseNonSparseStreamTest

SparseStreamDirTest

SparseStreamTest

SparseUserMappedSectionTest

SparseUserMapZeroTest

SparseZeroDataAllocTest

SparseZeroDataTest

SparseMoveFileTest

The defrag API call FSCTL_MOVE_FILE can be used with sparse files. If the VCN range to move is sparse, the specified LCN is not allocated. This test creates a sparse file, obtains the retrieval pointers of the file, and then attempts to move a sparse region over an already committed LCN range. The move should return success since the area takes no allocation. The attempt is then made over a sparse and nonsparse range. This should fail with STATUS_ALREADY_COMMITTED.

SparseNonSparseStreamTest

The purpose of this test is to test the ability to have sparse and nonsparse data streams on a file. This test uses allocation size to determine this. The unnamed data stream of a file is opened and made sparse. Then a byte is written at the end of the stream. A named stream is then created on the file. The same write is done on the named nonsparse data stream. The allocation size of the file is then checked. The new allocation size is checked to be less than 10% + the size for the nonsparse region of the allocation necessary.

NonSparseZeroDataTest

The purpose of this test is to ensure that FSCTL_SET_ZERO_DATA sets a range of a non-sparse file to zero. The test file is first opened. Then the file is written with 0xffs. The FSCTL is attempted on the first half of the file. The file is then read back and the first half is verified to be zeros, and the second half 0xffs.

ResetSparseAttrOverwriteTest

When a sparse file is overwritten, it becomes a nonsparse file. This is tested by way of the sparse attribute, FILE_ATTRIBUTE_SPARSE_FILE. The attribute is checked before and after the overwrite. After the overwrite, the flag is checked to be reset.

SparseZeroDataAllocTest

The purpose of this test is to ensure that FSCTL_SET_ZERO_DATA reduces the allocation size of the file. The test file is first opened and made sparse. Then the file is written with 0xffs. The allocation size is checked to see that at least 100% of the file size is allocated. The FSCTL is attempted on the first half of the file. The allocation size is again checked to verify that no more than 60% of the file size is allocated.

SparseZeroDataTest

The purpose of this test is to ensure that FSCTL_SET_ZERO_DATA sets a range of a sparse file to zero. The test file is first opened and made sparse. Then the file is written with 1s. The FSCTL is attempted on the first half of the file. The file is then read back and the first half is verified to be zeros, and the second half 0xffs.

SparseStreamTest

The purpose of this test is to test sparse streams by way of allocation size. The unnamed data stream of a file is opened and made sparse. Then a byte is written at the end of the stream. The allocation size is checked. The new allocation size is checked to be less than 10% of the allocation necessary.

SparseStreamDirTest

The purpose of this test is to test sparse streams by way of allocation size. A named data stream of a directory is created and made sparse. Then a byte is written at the end of the stream. The allocation size is checked. The new allocation size is checked to be less than 10% of the allocation necessary.

ResetSparseAttrSupersedeTest

When a sparse file is superseded, it becomes a nonsparse file. This is tested by way of the sparse attribute, FILE_ATTRIBUTE_SPARSE_FILE. The attribute is checked before and after the supersede. After the supersede, the flag is checked to be reset.

SparseAllocatedRangesTest

The purpose of this test is to ensure that FSCTL_SET_ZERO_DATA reduces the allocation size of the file. The test file is first opened and made sparse. Then the file is written with 0xffs. The allocation size is checked to see that at least 100% of the file size is allocatied. The FSCTL is attempted on the first half of the file. The allocation size is again checked to verify that no more than 60% of the file size is allocated.

FileInformationSparseAttrTest

The purpose of this test is to test the FILE_ATTRIBUTE_SPARSE_FILE attribute flag. The attributes are obtained by using NtQueryInformationFile with the basic information class. The flag represents the sparse attribute on a stream by stream basis. If one stream in a file is opened that is not sparse, the flag is clear. If a different stream in the same file is opened that is sparse, the flag is then set.

SparseCompressedStreamTest

Sparse files can be compressed using FSCTL_SET_COMPRESSION. The sparse extents are not changed after the compress. This test creates a sparse file, obtains the retrieval pointers of the file, and then attempts to compress the file. The retrieval pointers are again obtained and the sparse extent is verified to be the same. FSCTL_GET_RETRIEVAL_POINTERS is used to obtain the pointers.

SparseUserMappedSectionTest

The purpose of this test is to test the creation of a user mapped section and view on a sparse file. The test file is first opened and made sparse. Then a byte is written at the end of the file. A section and view are then created on the file.

SparseUserMapZeroTest

The purpose of this test is to ensure that FSCTL_SET_ZERO_DATA returns STATUS_USER_MAPPED_FILE when there is a user mapped section and view on a sparse file. The test file is first opened and made sparse. Then a byte is written at the end of the file. A section and view are then created on the file. The FSCTL is attempted and the expected status is verified.


TD-21.22 ExtendedSecurity File System Test

FindFilesBySidTest

The purpose of this test is to verify that FSCTL_FIND_FILES_BY_SID can be used to scan the file records and find entries owned by a specified SID. The FIND_BY_SID_DATA structure is used as input buffer to specify the SID. An output buffer aligned on a FILE_NAME_INFORMATION structure boundary is used to return the found files.


TD-21.23 ForcedDismount File System Test

ForceDismountTest

The purpose of this test is to verify that, in Windows 2000, the FSCTL_DISMOUNT_VOLUME can be issued on an active volume, i.e., with opened file handles. This operation is expected to succeed, except for two cases: i) the volume is the system drive, which cannot be dismounted. The operation fails with STATUS_ACCESS_DENIED; ii) the file system is pre-NT5 FAT, which requires exclusive-lock access to the volume before it can be dismounted. The operation fails with STATUS_NOT_LOCKED.


TD-21.24 Encryption File System Test Group

EncryptedFiles Test Group Introduction

A programmer or user may mark a directory or file as encrypted. A file so marked is encrypted by NTFS using the current encryption driver. If the file is later marked as not encrypted, it is decrypted and left in a plaintext (not encrypted, but still protected by the NT security model) state.

Directories are not themselves encrypted. Rather, by default, in an "encrypted" directory all new files in the directory are encrypted at creation. A user must specifically change the status of a new file to decrypted if the user does not want the file to be encrypted. An encrypted directory is visible.

To encrypt a file, the CreateFile function with the FILE_ATTRIBUTE_ENCRYPTED flag is used. To encrypt an existing file, the EncryptFile function can be used. All data streams in the file are encrypted. If the file is already encrypted, EncryptFile does nothing but return a nonzero value, which indicates success. If the file is compressed, EncryptFile decompresses the file before encrypting it.

To decrypt an encrypted file, the DecryptFile function is used. If the file is not encrypted, DecryptFile does nothing but return a nonzero value indicating success.

To retrieve the encryption status of a file, the FileEncryptionStatus function is used. Alternatively, the GetFileAttributes function and the FILE_ATTRIBUTE_ENCRYPTED flag is used.

Before the tests are run, the volume information should be queried to determine if Encryption is supported (FILE_SUPPORTS_ENCRYPTION). All tests are then run. The expectations of the tests should be altered depending on the determined support.

The call path from WIN32 is:

advapi.dll -> feclient.dll -rpc-> LSA

The individual tests in this group are:

AddUsersEncryptionTest

CreateEncryptedDirTest

CreateEncryptedFileTest

DirectoryEncryptedNewDirTest

DirectoryEncryptedNewFileTest

DirectoryEncryptedSuperOverTest

EncryptDecryptDirTest

EncryptDecryptFileTest

EncryptionAttributeTest

EncryptionCompressionTest

EncryptionDecompressionTest

EncryptionStatusTest

QueryRecoveryAgentsTest

QueryUsersEncryptionTest

ReadWriteRawEncryptedTest

RemoveUsersEncryptionTest

SuperOverEncryptedTest

AddUsersEncryptionTest

SuperOverEncryptedTest

A file can be encrypted by using the NtCreateFile API with the FILE_ATTRIBUTE_ENCRYPTED flag specified. The FILE_SUPERSEDE, FILE_OVERWRITE, and FILE_OVERWRITE_IF dispositions can be used on an existing file. Encryption on the files is then tested by opening the file in a different process, with a different security token. ACCESS_DENIED should be returned.

ReadWriteRawEncryptedTest

The raw encrypted data can be read and written using OpenEncryptedFileRaw, ReadEncryptedFileRaw, WriteEncryptedFileRaw, and CloseEncryptedFileRaw. These are used in off-line recovery. The operations are tested by encrypting a file then creating a new file and writing with the api's. The file size of the two files should match.

RemoveUsersEncryptionTest

The RemoveUsersFromEncryptedFile function is used to remove a specified user from a list of users that are permitted to access a specified encrypted file. This is verified by encrypting a file in an alternate user context. Then, the QueryUsersOnEncryptedFile function is called to retrieve the number of users that are allowed access to the file. This number should be at least 1: the file owner. Finally, the RemoveUsersFromEncryptedFile function is called to remove the specified user from the list; the QueryUsersOnEncryptedFile is called again. The number of users allowed to decrypt the file should be one less than before.

QueryUsersEncryptionTest

The QueryUsersOnEncryptedFile function is used to retrieve a list of users that are permitted to access a specified encrypted file. This is verified by encrypting a file in an alternate user context. Then, the QueryUsersOnEncryptedFile function is called to retrieve the number of users that are allowed access to the file. This number should be at least 1: the file owner.

QueryRecoveryAgentsTest

The QueryRecoveryAgentsOnEncryptedFile function is used to retrieve a list of users that are permitted to recover a specified encrypted file. The recovery agent can always retrieve the file if the file owner can no longer do so. This is verified by encrypting a file in an alternate user context. Then, the QueryRecoveryAgentsOnEncryptedFile function is called to retrieve the number of users that are allowed recover to the file. This number should be at least 1: the recovery agent.

EncryptDecryptFileTest

A file can be encrypted by using the EncryptFile function. Encryption on the files is tested by opening the file in a different process, with a different security token. ACCESS_DENIED should be returned. The file is then decrypted with the DecryptFile function. An attempt to open and read should be made. NO_ERROR should be returned.

EncryptDecryptDirTest

A directory can be encrypted by using the EncryptFile function. When the file/dir attributes are read back, the encyption flag should be set. Directories can be decrypted by calling the DecryptFile function. The attributes should be consistent with the encryption state.

EncryptionStatusTest

The FileEncryptionStatus call can be used to check the encryption status of a file or directory. The call is made on files and directories that are and are not encrypted. The FILE_IS_ENCRYPTED is checked for correctness.

EncryptionDecompressionTest

In Windows 2000, file based compression and encryption are mutually exclusive. When the file is compressed and a call to EncryptFile is made, the file will be uncompressed in the process. The attributes on the file should then show encryption only.

EncryptionCompressionTest

In Windows 2000, file based compression and encryption are mutually exclusive. If an attempt is made to encrypt a file that is already compressed. The file will be decompressed, then encryption will be applied. This can be verified by first compressing a directory with FSCTL_SET_COMPRESSION. Then an encrypted file and directory are created with a call to NtCreateFile while specifying the FILE_ATTRIBUTE_ENCRYPTED flag. The attribute of the file and directory are read back; only the FILE_ATTRIBUTE_ENCRYPTED flag should be observed.

EncryptionAttributeTest

GetFileAttributes can be used to check the encyrption status of a file or directory. The call is made on files and directories that are and are not encrypted. FILE_ATTRIBUTE_ENCRYPTED is observed.

DirectoryEncryptedSuperOverTest

An existing non-empty directory can be encrypted by using the EncryptFile function. The FILE_SUPERSEDE, FILE_OVERWRITE, and FILE_OVERWRITE_IF dispositions can then be used on the files in that directory. This will encrypt the files. Encryption on the files is then verified by opening the file in a different process, with a different security token. ACCESS_DENIED should be returned.

DirectoryEncryptedNewFileTest

A directory can be encrypted by using the NtCreateFile API with the FILE_ATTRIBUTE_ENCRYPTED flag specified. A new file created under the encrypted directory should be encrypted by default. Encryption on the file is tested by opening the file in a different process,with a different security token. ACCESS_DENIED should be returned.

DirectoryEncryptedNewDirTest

A directory can be encrypted by using the NtCreateFile API with the FILE_ATTRIBUTE_ENCRYPTED flag specified. A new directory created under the encrypted directory should be encrypted by default. Encryption on the directory is tested by opening the directory and verifying that FILE_ATTRIBUTE_ENCRYPTED is set.

CreateEncryptedFileTest

A file can be encrypted by using the CreateFile function with the FILE_ATTRIBUTE_ENCRYPTED flag specified. The CREATE_NEW disposition must be used. Encryption on the file is tested by opening the file in a different process, with a different security token. ACCESS_DENIED should be returned.

CreateEncryptedDirTest

A directory can be encrypted by using the NtCreateFile API with the FILE_ATTRIBUTE_ENCRYPTED flag specified. When the file/dir attributes are read back, the encyption flag should be set.AddUsersEncryptionTest The AddUsersToEncryptedFile function can be used to share encrypted files, i.e.,allow other users to decrypt an encrypted file. This is verified by encrypting a file in an alternate user context. The QueryUsersOnEncryptedFile function is used to verify that the number of users allowed to access the file is 1. Then, the AddUsersOnEncryptedFile function is used to add another user to the encrypted file. The QueryUsersOnEncryptedFile function should now report that 2 userss are allowed access to the encrypted file.


TD-21.25 Quotas File System Test Group

Quotas Test Group Introduction

Quotas are used to limit the amount of data a user is allowed to save on a volume. The tests in this group are:

QuerySetQueryQuotaTest

VolumeQuotaEnforceTest

VolumeQuotaLimitTest

VolumeQuotaNoneTest

VolumeQuotaThresholdTest

VolumeQuotaTrackTest

VolumeQuotaUserLimitTest

VolumeQuotaUserThresholdTest

VolumeQuotaEnforceTest

Quota usage changes are tracked and quota enforcement is done. This uses the FILE_VC_QUOTA_ENFORCE flag with NtSetVolumeInformation(), FileFsControlInformation. Attempts to exceed the quota should fail (DISK_FULL) and be logged in the event log if event logging is enabled.

VolumeQuotaNoneTest

This test uses the FILE_VC_QUOTA_NONE flag, with NtSetVolumeInformation() and FileFsControlInformation class to disable quota usage tracking. Although quota usage changes are not tracked, the quota limits are not removed. This is the default for an NTFS volume.

QuerySetQueryQuotaTest

NtQueryQuotaInformationFile() and NtSetQuotaInformationFile() allow sids (and their respective quota settings) to be queried and set to the volume quota index. NtQueryQuotaInformationFile() and NtSetQuotaInformationFile() use FILE_GET_QUOTA_INFORMATION to specify a SID. FILE_QUOTA_INFORMATION is used to set and get. It contains limits, thresholds, and a SID.

VolumeQuotaTrackTest

This test uses the FILE_VC_QUOTA_TRACK flag, with NtSetVolumeInformation() and FileFsControlInformation class to enable disk Quota tracking, whereby Quota usage changes are tracked, but no quota enforcement is done. This means that no filesystem operation are failed for disk Quota violations and no disk quota violations events are generated if disk logging is disabled.

VolumeQuotaUserLimitTest

We test the limit logging of user quotas with FILE_VC_LOG_QUOTA_LIMIT. This is applied with NtSetVolumeInformation, FileFsControlInformation. When the user quota exceeds the limit, the correct event should be generated.

VolumeQuotaUserThresholdTest

We test logging of user quotas with FILE_VC_LOG_QUOTA_THRESHOLD. This is applied with NtSetVolumeInformation, FileFsControlInformation. When the user quota exceeds the threshold, the correct events should be generated.

VolumeQuotaLimitTest

We test that the FILE_VC_LOG_VOLUME_LIMIT flag has no effect on disk Quotas. This is applied with NtSetVolumeInformation, FileFsControlInformation. When the user quota exceeds the limit, no disk Quota events are generated.

VolumeQuotaThresholdTest

We test that the FILE_VC_LOG_VOLUME_THRESHOLD flag has no effect on disk Quotas. This is applied with NtSetVolumeInformation, FileFsControlInformation. When the user quota exceeds the limit, no disk Quota events are generated.


TD-21.26 LinkTracking File System Test Group

LinkTracking Test Group

The Object IDs of files, directories and volumes allow IShellLink::Resolve broken links on the same volume and across volumes. This is tested by creating files/directories with and without Object IDs. The file/directories are moved, and the Resolve method is then invoked.Resolve has two approaches to finding target objects. The first is the distributed link tracking service. If the service is available, it can find an object that was on an NTFS version 5.0 volume and was moved to another location on that volume. It can also find an object that was moved to another NTFS version 5.0 volume, including volumes on other computers. To suppress the use of this service, set the SLR_NOTRACK flag.

The tests in this group are:

IshellLinkResolveTest

IShellLinkResolveVolumeTest

IshellLinkResolveTest

The IShellLink interface can be used to create and resolve the object of a link that has moved on the same volume. This test creates two files. The ObjectId is deleted on one of the files with FSCTL_DELETE_OBJECT_ID. Two links are created with the IShellLink interface, one to each file. The target files are moved to a different directory. An attempt is made to resolve the links using IShellLink::Resolve. The test is repeated for target directories.

IShellLinkResolveVolumeTest

The IShellLink interface can be used to create and resolve the object of a link that has been moved onto a different volume (on the same system). This test creates two files. The ObjectId is deleted on one of the files with FSCTL_DELETE_OBJECT_ID. Two links are created with the IShellLink interface, one to each file. The target files are moved to a different volume. An attempt is made to resolve the links using IShellLink::Resolve. The test is repeated for target directories.


TD-21.27 ChangeJournal File System Test Group

ChangeJournal Test Group Introduction

ChangeJournalTest

ChangeJournalTrimTest

CreateChangeJournalTest

DeleteChangeJournalTest

EnumMftUsnDataTest

QueryChangeJournalTest

ReadChangeJournalTest

ReadFileChangeJournalTest

WriteCloseRecordTest

ChangeJournalTest

There are many events which are recorded in the change journal. The reasons can be tested by performing an operation that would cause the change to be recorded, and then reading the change journal.

CREATE Create a new file. USN_REASON_FILE_CREATE

WRITE Write new data at end of file USN_REASON_DATA_EXTEND

SET_INFORMATION Set end of file USN_REASON_DATA_TRUNCATION

SET_EA Set or Replace EA. USN_REASON_EA_CHANGE

FSCTL SetReparsePoint USN_REASON_REPARSE_POINT_CHANGE

CreateChangeJournalTest

FSCTL_CREATE_USN_JOURNAL creates a USN journal the first time it's called. Otherwise it will either increase the size of the existing journal or have no effect.

DeleteChangeJournalTest

FSCTL_DELETE_USN_JOURNAL is used when the user want to delete the current USN journal. This will initiate the work to scan the Mft and reset all USN values to zero and remove the UsnJournal file from the disk. This operation is tested with the help of FSCTL_QUERY_USN_JOURNAL.

EnumMftUsnDataTest

The FSCTL_ENUM_USN_DATA operation creates an enumeration that lists the change journal entries between two specified boundaries. The FSCTL can be called multiple times on the same range by specifing an ordinal MFT_ENUM_DATA->StartFileReferenceNumber value. This test establishes a known set of USN records. The records are then read through FSCTL_ENUM_USN_DATA.

QueryChangeJournalTest

FSCTL_QUERY_USN_JOURNAL returns the information about the current instance of the USN journal in USN_JOURNAL_DATA.

ReadChangeJournalTest

FSCTL_READ_USN_JOURNAL has input READ_USN_JOURNAL_DATA and output USN_RECORD. This FSCTL returns the USN records from a specific starting USN. This test establishes a known set of USN records. The records are then read through a call to FSCTL_READ_USN_JOURNAL. The contents of the USN record are verified against the expected values.

ReadFileChangeJournalTest

FSCTL_READ_FILE_USN_DATA is used with a file or directory handle. It returns the last USN_RECORD for the open handle.

ChangeJournalTrimTest

The FSCTL_CREATE_USN_JOURNAL control can change the size of a USN journal. CREATE_USN_JOURNAL_DATA->MaximumSize. The allocation size should be returned to the free pool on the volume.

WriteCloseRecordTest

FSCTL_WRITE_USN_CLOSE_RECORD writes a close USN record for the current file, and returns its USN.


TD-21.28 StreamEnhancements File System Test Group

StreamEnhancements Test Group Introduction

Named streams have been enhanced to support renaming, deleting, querying. In addition, change notification events on name, size and write changes are also supported. The tests in this group are:

StreamDeleteTest

StreamNotifyNameTest

StreamNotifySizeTest

StreamNotifyWriteTest

StreamQueryNamesTest

StreamRenameTest

StreamQueryNamesTest

The named streams in a file can now be queried using NtQueryInformationFile() with the FileStreamInformation class.

StreamRenameTest

Streams can now be opened and renamed with the NtSetInformationFile() and FileRenameInformation class.

StreamNotifySizeTest

NtNotifyChangeDirectoryFile() can be used with the FILE_NOTIFY_CHANGE_STREAM_SIZE filter. The file size of a stream is changed to cause this notification.

StreamNotifyWriteTest

NtNotifyChangeDirectoryFile() can be used with the FILE_NOTIFY_CHANGE_STREAM_WRITE filter. Notification Actions: FILE_ACTION_MODIFIED_STREAM -- Modify :stream1

StreamNotifyNameTest

NtNotifyChangeDirectoryFile() can be used with the FILE_NOTIFY_CHANGE_STREAM_NAME filter to monitor changes to stream names on a file or directory. The pair FILE_NOTIFY_CHANGE_STREAM_NAME, FILE_ACTION_ADDED_STREAM is observed when streams are added to a file. The pair FILE_NOTIFY_CHANGE_STREAM_NAME, FILE_ACTION_REMOVED_STREAM are added when a file containing named streams is overwritten or superseded.

StreamDeleteTest

Named streams can now be opened and marked for deletion (and deleted on cleanup). This feature is tested here.


TD-21.29 DefragEnhancements File System Test Group

DefragEnhancements Test Group Introduction

MoveDirTest

MoveViewTest

MoveDirTest

Directories can now be de-fragmented using FSCTL_GET_RETRIEVAL_POINTERS and FSCTL_MOVE_FILE. This test creates many files in a directory. Then, the retrieval pointers are obtained using a directory handle. The clusters are then moved using the directory handle, the retrieval pointers, and a volume handle.

MoveViewTest

System view (security, quota, reparse, object ID) directories can now be de-fragmented using FSCTL_GET_RETRIEVAL_POINTERS and FSCTL_MOVE_FILE. First, "\$Extend\$Reparse:$R:$INDEX_ALLOCATION" is opened as a directory. The clusters are then moved using the directory handle, the retrieval pointers, and a volume handle.


TD-21.30 I/O Stress Test Description

Overview

The File system Stress Kit (FSK, or IoStress) test suite contains tools and tests to thoroughly stress the file system of the Windows 2000 operating system.

Section 4 explains how to launch the suite. In order to take full advantage of the tests in the kit, install a kernel debugger to the computer prior to running the stress tests.

Section 6 describes the tests included in this Stress Kit. Section 7 briefly describes the log files generated during a stress run.

IO Stress Test Descriptions

Mountpts

Enumerate all the volumes on the system, create a volume mount point and write the GUID path into a file in the root of the volume. Verify that the file at the root contains the correct GUID, both through the volume mount point and through ordinary means (drive letter, where this is possible).

Rptags

The Rptags test stresses FSCTL’s associated with Reparse Points. This test is Windows 2000 specific

Usnstres

The Usnstres test stresses FSCTL’s associated with USN journal. This test is Windows 2000 specific.

Grow_shrink

The Grow_shrink test stresses file expansion and shrinking.

Memfile and Unbuffio

The Memfile and unbuffio tests aim to perform a number of memory and fileio operations simultaneously.

Fs_compression and Cmpstress

TheFs_compression and Cmpstress tests stress file compression and decompression

Cancelio

The Cancelio test stresses the Cancelio API in conjunction with asynchronous ReadFile, WriteFile, and LockFileEx calls.

Cmptest

The Cmptest creates a compressed file, uncompresses it, verifies, compresses and verifies it again. The test varies the type of I/O, the type of access, and the type of data written into the file.

Compstrs

The Compstrs test creates a file and then writes to the file the loaded images of the Kernel32.dll and Ntdll.dll in an infinite loop. It then compresses the file, sleeps for 0.5 seconds, and then uncompresses the file.

File_notify

The File_notify stress test sets up several notification handlers for directories in the stress tree and then waits for notifications from the system.

Fscmprsn

The Fscmprsn stress test has the parent thread create a file and spawn other child threads. The child threads constantly toggle the compression state of the file. While the children are toggling the state of the file, the parent proceeds with several writes to the file until the file grows to a particular size. The parent stops all the child threads, verifies the contents of the file and toggles the state of the file, and then repeats the process.

Dismount

The Dismount test dismounts the drives every four hours.

Objidstrs

The Objidstrs test stresses FSCTL’s associated with an Object ID. This test is Windows 2000 specific.

Fragment

The Fragment stress test creates a high degree of fragmentation on the current stress partition.

Locktest

The Locktest test stresses the file lock APIs.

Sparsef

The Sparsef test stresses the Windows 2000 specific sparse file APIs.

Mktropcl, Lots_files, Allfs_strs

The Mktropcl, Lots_files, and Allfs_strs tests create a large tree of directories and files.

Ntfs_acl

The Ntfs_acl test stresses setting up security attributes and DACLs.

Syscache

The Syscache test stresses the system cache.

Tunnel

The Tunnel test stresses tunneling and link tracking behavior.

Siss

Stress tests for Single Instance Storage functionality.

Memory_stress and Resource_consumer

These are a mixture of test cases to stress memory, heap allocation, and so forth. These tests consist of the following components.

Consume

The Consume stress test is a universal resource consumer. Depending on the command line, it can consume all physical memory, page file, CPU time, disk space, or kernel pool. It should be run it in parallel with other stress tests to put pressure on those components and force them to deal with low resource conditions.

Lookaside

The Lookaside stress test exercises heap manager code paths for small block allocations (below 1,024 bytes). For these small blocks, the heap manager uses a different manager (lookaside manager). The scenario executed is multi-threaded random alloc/free operations.

Race

The Race stress test exercises several scenarios that might expose race conditions. It executes multiple threads of same or similar operations concurrently. It also uses a worker thread that calls a system API passing a buffer as a parameter and a breaker thread that tries to change protection on the buffer passed to the system.

Witness

The Witness stress test exercises the memory manager functionality by randomly executing alloc/free scenarios. The test keeps a simplistic model of the virtual space. Therefore, it can detect minor inconsistencies.

Vmstress

The Vmstress stress test allocates and touches pages from multiple threads. In the process, it checks that the fill patterns are maintained and that we do not get pages from other processes.

Pages

The Pages stress test forces several trashing patterns (large amounts of paging). This exercises the memory manager code paths involved in servicing page faults.

Heaptest

The Heaptest stress test exercises the heap manager code paths. It runs from several threads a random alloc/free scenario. It is more effective in testing the code paths dealing with big heap blocks (above 16K). For small blocks, see the Lookaside test.

Lockmem

The Lockmem test acquires chunks of memory from RAM and the Pagefile. It uses VirtualAlloc and VirtualLock to ensure that memory is allocated in RAM. In addition, it sleeps for a user defined time, unlocks the Memory, and releases it.

Setup

User Controls - Steps to Run the I/O Stress Test Suite

Launch

Invoking the Iostress.cmd script in the root directory starts the IoStress engine.

Initialization File Format

[Driver1]
This is the name of the driver. This name should match the registry entry under
- HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services where the Filter Driver is installed as a service.
StartType = value
The valid values are: Boot, Auto, Demand, and Disabled.
DriverType = value
The valid value for the DriverType are FileSystem and Kernel.
BinPath =<string to driver path>
An example is c:\Winnt\system32\drivers\driver1.sys.
NeedsReboot = Value
You can specify Yes or No here. This is an optional field. By default, it is assumed that no driver needs a reboot when it is loaded.
GroupName=Value
You can specify a name for the load order group. If this field is missing, the group name is then termed the same name as the DriverName.
[Driver2]
...
...
Any line beginning with ; is considered a comment.

User Interface

The utility parses the initialization file provided, queries the status of all the drivers installed, and puts it in the two list boxes. Most of the buttons are self-explanatory. Selecting them and pressing the Install button can install drivers in the Additional Available list. This moves them to the Currently Installed list.
Move Up: You can move drivers up and down. All the drivers are reconfigured with a dependency requirement on the drivers below them.
Apply: Your changes take effect when you click the apply button.
Similar to the Driver Verifier, making configuration changes in the filter driver utility may require a reboot. Again, the utility prompts you that in order to incorporate those changes, a reboot is required. This is just informational. IOStress automatically reboots the system at an appropriate juncture.

Munger – System Settings Tab

The Munger sets up the environment for stress. For example, it puts debug flags in Boot.ini and changes registry settings for Resource timeout and Critical section timeout. Select Preferred Stress Settings. Any changes made require a reboot.

Running Tests on Various Drives – Run Information Tab

Prior to a stress run, the utility installs UDF and CDFS drivers on your machine and maps two free drives on your system to these drivers. After the stress run is over, these drives are automatically deleted. These drivers are pseudo drivers to enable you to run Stress even if you do not have them installed on your system.
The utility then enumerates all the drives on the system. This includes the UDF and CDFS drives that were recently installed on your system. By default, this utility selects one drive of each type such as FAT, NTFS, FAT32, CDFS, and a remote drive. If there is no remote drive on your machine, this utility maps a loop back share on your machine.
The Run Information tab contains information about the temporary directory where stress will be run. If you are running Windows 2000 NTFS, you can choose encryption and compression as well.
In addition, you can also specify the duration of the stress run. The date should be specified in mm/dd/yyyy and time in HH:MM formats.
You can skip to run stress on your primary partition and choose all other options. The loop back redirected drive will appear in this section as a remote drive.

Selecting Tests to Run – Test Selection Tab

The Test Selection tab has two list boxes: Currently selected tests and an Additional set. You can move the tests from one list box to another by selecting the tests and clicking the corresponding Add or Remove buttons. The Add and Remove buttons activate once you make your selection.
The default selection of the tests is random
Always select the test IOInit to run. This script launches all other tests.
The name of the tests appearing in the two list boxes have the drive letter appended to the name of the actual test. The drive letter indicates the drive on which the test will run. For example, the test with the name sampletest appears as sampletest_c and sampletest_d. You can choose to run sampletest_c and not run sampletest_d. In this figure, allfs_strs_I is already in the Selected Tests group and the user is also in the process of adding allfs_strs_e to run.
After you have chosen all the tests, click Run. This launches all of the selected stress tests.

Stress Shutdown

You can shutdown the Stress test by clicking the Shutdown button. The Stress test reboots the system; when Windows restarts, it will perform chkdisk on all the drives and clean up the temporary stress files.
Required Hardware

Use the Stress Kit to run file system stress on the following types of drives:

  • NTFS (local and remote)
  • FAT (local and remote)
  • DFS drives
  • Removable Media
  • Floppy Drives

Results Interpretation

The stress tests generate log files, which contains pertinent information about the status of the tests. These log files are stored in the directory %SystemRoot%\stresslog. Each test makes a directory inside this location and logs its information. The name of the log file indicates the name of the test and the drive on which it is run. For example, if the test Mktropcl is run on E:, the name of the generated log file will be c:\stresslog\mktropcl\mktropcl_E.log.


Appendixes

Appendix A - Filter Testing

Appendix B - Command Line Options

Appendix C - IFS Test Status Codes

Appendix D - Using NTLOG with IFS Test

Appendix E - File System Test Groups

ChangeNotificationTest

There are many combinations of FILTERS, CAUSES, and ACTIONS. The notification events table is used for a coverage test of all expected notification behavior. A file handle is opened in the test directory and a thread is created that will write to the file. Meanwhile in the main thread the write is waited upon for 4 seconds, if the write does not occur a timeout will happen. When the write does occur the event is triggered and the test will make sure the correct ACTION was reported.

PrepCompressionTest

Some file systems support compression on individual files. This test is run as part of the SetCompressionTest.

The Installable File System Test, IFS Test, was designed to test the compliance of installable file systems in the Microsoft Windows NT 4.0 and Windows 2000 Operating Systems. Its intended audience includes file system developers who want to verify that their drivers comply with a standard set of expected functionality. The IFS Test is run from the command line with several options specified. Each test that is run will return a test status block whether the test has passed or failed, or the test results can be viewed in NTLOG. The IFS Test was written with the following design goals in mind:

  • Subsystem Independence
  • Synthetic Operation Distinction
  • Separate Test Groups
  • Asynchronous / Synchronous Testing
  • Fault Identification
  • Coverage
  • Extensible
  • Development Guideline
  • Filter Testing


Chapter 22: Driver Quality Test Specification

Draft Version: 0.1 — Date: November 10, 2000

This chapter describes Driver requirements and test tools. These requirements are specified in Microsoft Windows Logo Program System and Device Requirements.

This specification also describes the individual tests that verify the requirements for Driver Quality, under "Driver Quality Test Descriptions" later in this chapter.

Test Coverage

Test Methology


Driver Quality Test Assertions

This section contains the test assertions for drivers.


Information File Syntax Checker Assertions (IFS)

The following Information File Syntax Checker assertions are tested in the ChkINF test.

22.1.1001 This is not a valid driver INF.

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Design Guide, Chapter 3 "Creating an INF File"

Test Description: "TD-22.1 ChkINF Test"

22.1. 1002 Unable to include item.

Only system provided INFs may be specified with the INCLUDE directive.

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1. 1003 Required sections must be present…

Applies to more than just required sections. If a user-defined section is referenced, but not present, this error is flagged. (I.e. CopyFiles=Foo, but no [Foo] present)

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Summary of INF Sections

Test Description: "TD-22.1 CheckINF Test"

22.1. 1004 Provider=Microsoft illegal unless you are Microsoft

Reference Document: TBD

Test Description: "TD-22.1 CheckINF Test"

22.1. 1005 ALSOINSTALL directive is illegal

The AlsoInstall directive should only be used if the INF file is provided by a vendor, and the device is installed on Windows 98 and later versions. For Windows 2000 and later versions, use the Include and Needs directives

Reference Document: Windows DDK Help Documentation; Supporting Common Device Types, Streaming Device, Design Guide, Part 3: "Audio Drivers, Audio Miniport Drivers", Installing a Port Class Audio Adapter, Installing Core System Components for an Audio Adapter, Installing on Windows 98 and Later Versions

Test Description: "TD-22.1 CheckINF Test"

22.1. 1006 Redefining Keys is illegal

Reference Document: TBD

Test Description: "TD-22.1 CheckINF Test"

22.1. 1007 Service installation section can only have one service name

Reference Document: TBD

Test Description: "TD-22.1 CheckINF Test"

22.1. 1008 Signature= must be $Windows NT$, $Chicago$, or $Windows 95$

Signature="signature-name" can be any of $Windows NT$, $Chicago$, or $Windows 95$. The enclosing $ are required but these strings are otherwise case-insensitive. If the signature-name is none of these string values, the file is not accepted as a valid INF.

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives, INF Version Section

Test Description: "TD-22.1 CheckINF Test"

22.1. 1009 Binary must not change for a given service name.

Reference Document: TBD

Test Description: "TD-22.1 CheckINF Test"

22.1. 1010 ClassGUID= must match Class if both are present

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives, INF Version Section

Test Description: "TD-22.1 CheckINF Test"

22.1. 1011 There must only be one controlling service per driver

Reference Document: TBD

Test Description: "TD-22.1 CheckINF Test"

22.1. 1012 DriverVer must be present and in mm/dd/yyyy,w[.x[.y[.z]]] format.

The mm/dd/yyyy value specifies the date of the driver package, including the driver files and the INF. A hyphen (-) can be used as the date field separator in place of the slash (/).

The x.y.v.z specifies an optional version number. This value is for display purposes only (for example, in the Device Manager). The OS does not use this value for driver selection.

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives, INF Version Section

Test Description: "TD-22.1 CheckINF Test"

22.1. 1013 Must only be one token on the left of = sign

Reference Document: TBD

Test Description: "TD-22.1 CheckINF Test"

22.1. 1014 "Service name must not change for a given Binary.

Reference Document: TBD

Test Description: "TD-22.1 CheckINF Test"

22.1. 1015 Each segment in DriverVer optional version must be between 0 and 65535 inclusive.

Reference Document: TBD

Test Description: "TD-22.1 CheckINF Test"

22.1. 1016 There is a max of 4 version segments in DriverVer optional segment

Reference Document: TBD

Test Description: "TD-22.1 CheckINF Test"

22.1. 1017 Primary revision number must be greater than 0.

Reference Document: TBD

Test Description: "TD-22.1 CheckINF Test"

22.1. 1022 "%s should not have a value."

< [Optional] Need to explain what things should not have a value {\"unused\" (field 3) should not have a value.} >

Reference Document: TBD

Test Description: "TD-22.1 CheckINF Test"

22.1. 1025 Defined item has no value

One of the following undefined or has no value: destination-file-name, subkey, interface-install-section, install-section-name, hw-id, diskid, disk-description, ini-file, ini-section, ServiceName, ServiceInstallSection, ServiceName, etc.

Reference Document: TBD

Test Description: "TD-22.1 CheckINF Test"

22.1. 1028 All quoted lines must be closed.

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives, INF Strings Section

Test Description: "TD-22.1 CheckINF Test"

22.1. 1029 Inf must not copy another inf to \inf or subdir

The system will automatically copy the inf file, it should not be listed in a copyfiles section.

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives, INF CopyFiles Directive

Test Description: "TD-22.1 ChkINF Test"

22.1. 1030 Inf files must not copy .cat files

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1. 1031 Inf must not delete files of type inf.

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1. 1032 Inf files must nor rename files to *.inf or *.cat

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1. 1034 Catalog files should not be listed in SourceDiskFiles.

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1. 1039 Manufacturer section must have at least one entry

Any INF that installs one or more devices must have a Manufacturer section.

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives, INF Manufacturer Section

Test Description: "TD-22.1 ChkINF Test"

22.1. 1042 File_section keyword redefined.

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1. 1043 DirID value is missing.

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives, INF DestinationDirs Section

Test Description: "TD-22.1 ChkINF Test"

22.1. 1044 Wrong value for DirID.

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives, INF DestinationDirs Section

Test Description: "TD-22.1 ChkINF Test"

22.1. 1048 Strings section must have unique keys

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives, INF Strings Section

Test Description: "TD-22.1 ChkINF Test"

22.1. 1050 Runonce must use rundll32.exe

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1. 1053 Must contain a CLASS directive.

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives, INF Version Section

Test Description: "TD-22.1 ChkINF Test"

22.1. 1054 Must contain a CLASSGUID directive.

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives, INF Version Section

Test Description: "TD-22.1 ChkINF Test"

22.1.1055 ClassGUID must be in {nnnnnnn-nnnn-nnnn-nnnn-nnnnnnnnnnnn} format

Each n is a hexadecimal digit.

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives, INF Version Section

Test Description: "TD-22.1 ChkINF Test"

22.1.1057 WARN: Unrecogized directive

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives

Test Description: "TD-22.1 ChkINF Test"

22.1.1058 Sections must have certain directives…

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives

Test Description: "TD-22.1 ChkINF Test"

22.1.1059 Certain classes are reserved for system use.

This Device class is either obsolete or reserved for system use.

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1. 1061 Value for EventLogType should be 'System', 'Application', or 'Security'

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1. 1063 RegKey root values must be HKLM, HKDD, etc…

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1. 1064 Catalog file must be in 8.3 format

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1.1065 Service cannot use both SERVICE_WIN32 and SERVICE_DRIVER

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1.1066 "Bad value for %s in %s."

There is a bad composite directive value for this directive.

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1. 1067 DriverVer must be greater than current system date or greater than OS ship date, whichever is greater.

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives, INF Version Section

Test Description: "TD-22.1 ChkINF Test"

22.1. 1068 "Illegal Value for %s"

< [Optional] Need to explain more {Illegal Value for flags. (Expected null or 0)} >

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1. 1069 DriverVer must be in mm/dd/yyyy format

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives, INF Version Section

Test Description: "TD-22.1 ChkINF Test"

22.1. 1078 Description length is too long. Limit is 1024 characters.

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1. 1079 Directive: %s required (and must not be NULL) in section [%s] Provider must be present in Version section and CMDLINE directive must be present in section.

< [Optional] Need to explain more [1079 Directive: %s{Provider; CmdLine} required (and must not be NULL) in section {Version; $Section}[%s]]>

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1. 1080 "Directive: %s required (and must not be NULL) in section [%s]" DriverVer must be present in Version section and NAME directive must be present in section.

< [Optional] Need to explain more. What is difference between this and 1079 [1080 Directive: %s{DriverVer; Name} required (and must not be NULL) in section {Version; $Section}[%s]]>

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1. 1081 Catalogfile or Catalogfile.NT must be present in Version section and popluated

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1. 1085 Section directions must be one of the following:…unclear what we need to require on these

< [Optional] Need to explain more >

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1. 1086 "Bad value for %s in %s." Bad value for Day in DriverVer.

< [Optional] Need to explain more. How is this different then 1066 (Bad value for Day in DriverVer.) >

Reference Document: Windows DDK Help Documentation; Supporting Driver Installation, Reference, Chapter 1 "INF File Sections and Directives", Sections and Directives, INF Version Section

Test Description: "TD-22.1 ChkINF Test"

22.1. 1088 Certain parameters are required in certain values

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1. 1089 A disabled service canot be installed (StartType=0x4)

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1. 1092 Explicit destination dir required (defaultdestdir entry allowed)

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1. 1098 Required directive can not be set to a NULL value.

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1. 1099 Language IDs must be one of the following:

< [Optional] Need to explain more >

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1.1100 Priority value for configpriorities must be one of the following…

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1.1101 Config type for ConfigPriority must be one of the following…

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1.1102 IRQ Value for IRQConfig must be one of the following…

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1.1103 The hexadecimal integer value exceeds range.

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1.1104 IRQConfig not assigned according to DDK specification

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1.1105 IOConfig not assigned according to DDK specification

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1.1106 Invalid DMA value for DMAconfig

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1.1107 DMAConfig not assigned according to DDK specification

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1.1108 MEMConfig not assigned according to DDK specification

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1.1110 All files copied by inf must be referenced in sourcedisksfiles

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1.1112 Specific ADDREG keys don't contain specific values.

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1.1113 Certain keys must be numeric

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1.1114 Certain keys must be 0 or 1

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1.1116 DeviceUpgradeUnsupported value must be numeric

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1.1117 Incorrect format for DeviceUpgradeUnsuported directive.

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1.1118 Invalid value for SysSetupPnpFlags.

< [Optional] Need to explain more >

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1.1119 Incorrect format for SysSetupPnpFlags directive.

< [Optional] Need to explain more >

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1.1120 All entries in inf in %var% format must have corresponding entry in [Strings]

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1.1121 Commas on left of equal sign

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1.1199 Illegal Microsoft internal INFs.

< [Optional] Need to explain more >

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1. 1301 Security descriptors must be enclosed in quotation marks.

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1. 1302 Filter drivers cannot be the controlling service.

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1.xxxx Infs must only using includes= to include OS files

< [Optional] This should be an assertion. >

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1.xxxx Inf lines should not be > x chars

< [Optional] This should be an assertion. Was 1006. Should this be 4096 or 256 characters?? >

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"

22.1.xxxx Inf files are limited to 62K in size

< [Optional] This should be an assertion. Was 1034 >

Reference Document: TBD

Test Description: "TD-22.1 ChkINF Test"


Devctl Test Assertions

22.2.1 Unexpected entry points into the driver

Reference document: < WinLogo#, DDK ref, Industry spec, or DesGuide reference >
Test description: "TD-22.2 Devctl Test"

22.2.2 Query functions with buffers that are too small to contain all the data to be returned.

Reference document: < WinLogo#, DDK ref, Industry spec, or DesGuide reference >
Test description: "TD-22.2 Devctl Test"

22.2.3 IOCTL/FSCTL functions with missing buffers or buffers that are two small or contain garbage.

Reference document: < WinLogo#, DDK ref, Industry spec, or DesGuide reference >
Test description: "TD-22.2 Devctl Test"

22.2.4 IOCTL/FSCTL with direct I/O or type3 buffers with data changing asynchronously.

Reference document: < WinLogo#, DDK ref, Industry spec, or DesGuide reference >
Test description: "TD-22.2 Devctl Test"

22.2.5 IOCTL/FSCTL with bad pointers for type3 requests.

Reference document: < WinLogo#, DDK ref, Industry spec, or DesGuide reference >
Test description: "TD-22.2 Devctl Test"

22.2.6 IOCTL/FSCTL and fast path query functions where the users buffer mapping may change asynchronously. Pages become unreadable at arbitrary execution points.

Reference document: < WinLogo#, DDK ref, Industry spec, or DesGuide reference >
Test description: "TD-22.2 Devctl Test"

22.2.7 Relative opens with strange file names, Opens to strange device objects like the direct device open or file system devices.

Reference document: < WinLogo#, DDK ref, Industry spec, or DesGuide reference >
Test description: "TD-22.2 Devctl Test"

22.2.8 Issues requests both synchronously and asynchronously to the device.

Reference document: < WinLogo#, DDK ref, Industry spec, or DesGuide reference >
Test description: "TD-22.2 Devctl Test"

22.2.9 Missing length checks for buffered IOCTLs and FSCTLs

The only protection mechanism afforded to the driver writer is the bits in the IOCTL or FSCTL that require read and/or write access to the handle (FILE_WRITE_ACCESS, FILE_READ_ACCESS). FILE_ANY_ACCESS requires no specific granted access to the file object and is used by the bulk of driver IOCTLs and FSCTLs.

Reference document: Common Driver Reliability Problems < WinLogo#, DDK ref, Industry spec, or DesGuide reference >
Test description: "TD-22.2 Devctl Test"

22.2.10 Returning uninitialized data to the caller in the buffered I/O paths

Since the I/O manager presents variable-sized output buffers to drivers, care should be taken not to return uninitialized data to the caller. All data returned must be written by the driver to prevent information leakage problems.

Reference document: Common Driver Reliability Problems < WinLogo#, DDK ref, Industry spec, or DesGuide reference >
Test description: "TD-22.2 Devctl Test"

22.2.11 Missing probes for Type3 (METHOD_NEITHER) IOCTLs and FSCTLs

The I/O manager does no validation whatsoever for METHOD_NEITHER IOCTLs and FSCTLs. The driver must do probes and enclose all buffer references in try/except blocks.

Reference document: Common Driver Reliability Problems < WinLogo#, DDK ref, Industry spec, or DesGuide reference >
Test description: "TD-22.2 Devctl Test"

22.2.12 Buffered I/O requests with embedded pointers need full validation

Often drivers will embed pointers within buffered requests. These requests need to be validated carefully.

Reference document: Common Driver Reliability Problems < WinLogo#, DDK ref, Industry spec, or DesGuide reference >
Test description: "TD-22.2 Devctl Test"


PMTE Test Assertions

22.6.1 [New - v.0.5] That the OS can enable wake from real-time clock (RTC) on all supported sleep states and that it works on the target test system.

Reference document: Windows Logo Requirements Document, B1.4.5
Test description: TD-22.6 PMTE Test Description

22.6.2 [New - v.0.5] If RTC from S4 is supported that the target test system can do so.

Reference document: Windows Logo Requirements Document, B1.4.5
Test description: TD-22.6 PMTE Test Description

22.6.3 [New - v.0.5] That the OS survives cycling threw each supported sleep states repeatedly on the target test system.

Reference document: Windows Logo Requirements Document, B1.4.5
Test description: TD-22.6 PMTE Test Description

22.6.4 [New - v.0.5] That the devices still work after each S state transition.

Reference document: Windows Logo Requirements Document, B1.4.5
Test description: TD-22.6 PMTE Test Description


Driver Verifier Test Assertions

22.3. 1 [New - v.0.5] < Type or paste single-sentence assertion title here >

< [Optional] Include brief notes here, if required >

Reference document: < WinLogo#, DDK ref, Industry spec, or DesGuide reference >

Test description: "TD-22.3 [New - v.0.5] Driver Verifier"


Plug and Play (PnP) Driver Test Assertions

22.8.1 [New - v.0.5] The system must accept an upper filter on the target device stack

Reference document: Windows Logo Requirements Document, A1.1.3
Test description: TD-22.8 Plug and Play Driver Test

22.8.2 [New - v.0.5] The system must be able to restart device stack along with the query-remove/remove path of the drivers.

Reference document: Windows Logo Requirements Document, A1.1.3
Test description: TD-22.8 Plug and Play Driver Test

22.8.3 [New - v.0.5] The Plug and Play driver must allow driver updates.

Reference document: Windows Logo Requirements Document, A1.1.3
Test description: TD-22.8 Plug and Play Driver Test

22.8.4 [New - v.0.5] The Plug and Play driver must accurately uninstall devices and scan for new hardware in Device Manager

Reference document: Windows Logo Requirements Document, A1.1.3
Test description: TD-22.8 Plug and Play Driver Test

22.8.5 [New - v.0.5] The Plug and Play driver must perform a cancel-remove IRP when it fails a removal.

Reference document: Windows Logo Requirements Document, A1.1.3
Test description: TD-22.8 Plug and Play Driver Test

22.8.6 [New - v.0.5] The Plug and Play driver must be able to accurately disable and enable devices.

Reference document: Windows Logo Requirements Document, A1.1.3
Test description: TD-22.8 Plug and Play Driver Test

22.8.7 [New - v.0.5] The Plug and Play driver must be able to accurately perform a rebalance.

Reference document: Windows Logo Requirements Document, A1.1.3
Test description: TD-22.8 Plug and Play Driver Test

22.8.8 [New - v.0.5] The Plug and Play driver must be able to accurately perform multiple functions and tasks.

Reference document: Windows Logo Requirements Document, A1.1.3
Test description: TD-22.8 Plug and Play Driver Test

22.8.9 [New - v.0.5] The Plug and Play driver must be able to accurately accept a surprise removal of a device.

Reference document: Windows Logo Requirements Document, A1.1.3
Test description: TD-22.8 Plug and Play Driver Test


Driver Quality Test Descriptions

This section describes the tests provided.


TD-22.1ChkINF Test

This program is an INF File Syntax Checker. An INF file or Information file is a file created for a particular adapter that provides the operating system with information required to set up a device, such as a list of valid logical configurations for the device, the names of driver files associated with the device, and so on. An INF file is typically provided by the device manufacturer on a disk with an adapter.

ChkINF is a Perl script that checks the structure and syntax of Microsoft® Windows® 2000 device driver .inf files. Results are presented in HTML format, and include a list of the errors and warnings detected in each .inf file, with each error and warning shown next to the errant .inf file entry. Please note the Limitations section below. Note that ChkINF does not support Windows 98 .inf files.

The tool includes support for all .inf sections and directives that apply to all classes of devices. ChkINF includes specific device class support for the following device classes:

1394 Host Bus Controllers (class = 1394)

Battery Devices (class = Battery)

CD-ROM Drivers (class = CDROM)

Disk Drives (class = DiskDrive)

Display Adapters (class = Display)

Floppy Disk Controllers (class = FDC)

Floppy Disk Drives (class = FloppyDisk)

Hard Disk Controllers (class = HDC)

Human Input Devices (class = HIDClass)

Imaging Devices (class = Image)

IrDA Devices (class = Infrared)

Memory Technology Drivers (class = MTD)

Modems (class = Modem)

Monitors (class = Monitor)

Multifunction Devices (class = Multifunction)

Multi-port Serial Adapters (class = MultiportSerial)

Network Adapters (class = Net)

PCMCIA Adapters (class = PCMCIA)

Ports - COM & LPT serial ports (class = Ports)

SCSI and RAID Controllers (class = SCSIAdapter)

Smart Card Readers (class = SmartCardReader)

Storage Volumes (class = Volume)

System Devices (class = System)

USB (class = USB)

ChkINF does not check device specific INF extension for the following device classes:

Keyboards (class = Keyboard)

Medium Changers (class = MediumChanger)

Mice (class = Mouse)

Multimedia (class = Media)

Network Clients (class = NetClient)

Network Service (class = NetService)

Network Transport (class = NetTrans)

Printers (class = Printer)

Tape Drives (class = TapeDrive)

The tool has not been extensively tested. Review your results carefully.

RUNNING THE TOOL

Note: Because ChkINF is a Perl script, in order to use the tool you will need to obtain a Perl interpreter. ChkINF requires a Perl interpreter that is Version 5.003_07 or greater. ChkINF should work with any version of Perl 5.0 or greater, but has not been tested with any versions previous to 5.003_07.

ChkINF has been tested with the following Perl interpreters:

GNU Perl 5.005_02 compiled for Win32

Perl for Win32 5.003_07 from ActiveWare Internet Corp.

Microsoft neither endorses nor recommends any specific Perl interpreters.

ChkINF is located in the <DDKRoot>\Tools\Chkinf subdirectory, and should be executed from the Command Prompt.

A batch file, ChkINF.bat, is provided for smooth execution. ChkINF takes the following arguments:

Usage: ChkInf[.bat] <FileList> /L <LogFile> [/B] [/DC <Options>]

<FileList> FileName | Wildcard List | Directory Name

/L <LogFile> Write an NT Log File Named <LogFile>

/B Launch Default Browser and Display Results

/I <Dir> Look for INCLUDEd infs in <Dir> instead of current directory

/LO Verify files copied (CopyFiles) against Layout.inf

/DC <Options> Use Device Class <Options> When Checking .infs

/DC FAX Check any Fax keys present in Modem .inf files only only

Notes

"FileName" is the name of a single .inf file.

"Wildcard" List is a DOS wildcard (as in "net*.inf"). ChkINF automatically expands wildcards and checks all applicable .inf files.

ChkINF checks all .inf files located in the "DirectoryName" subdirectory.

/L creates an NT log file.

The only Device Class option currently supported by the /DC argument is the FAX option, as listed above.

Output

ChkINF produces three types of files at the end of the checking process.

Summary.htm: A single HTML file that lists all of the one or more .inf files that were checked, along with the number of errors and warnings detected in each one. The name of each .inf file is linked to the respective .htm file described below.

NameofINFfile.htm: Results file produced for each checked .inf file.

An optional NT Log file may be created (see Running the Tool).

NameofINFfile.htm includes the following:

Errors: A list of the errors found in the .inf file, along with the error message and the line in the .inf file where it was detected. Each warning includes a link to its location in the Annotated INF (see below).

Warnings: A list of the warnings detected in the .inf file, along with the warning message and the line in the .inf file where it was detected. Each warning includes a link to its location in the Annotated INF (see below).

Sections included from other infs: A list of the sections included from other .inf files. Each section listed includes a link to its location in the Sections included from other infs section (see below). This item is omitted if the .inf being checked did not include any sections from other .inf files.

Annotated INF: The complete source for the INF file, with the warning and error messages displayed adjacent to the line where the warning or error was detected.

Sections included from other infs: The complete source for the included sections, with warning and error messages displayed adjacent to the line where the warning or error was detected. This section is omitted if the INF being checked did not include any sections from other INF files.

These files are saved into the subdirectory Htm, located off the directory from which ChkINF is invoked.

LIMITATIONS

ChkINF does not support Windows 98 .inf files. ChkINF will not accurately check .inf structure and syntax that is specific to Windows 98 .inf files.

The tool does not perform device-class-specific testing for the following device classes:

Keyboards (class = Keyboard)

Medium Changers (class = MediumChanger)

Mice (class = Mouse)

Multimedia (class = Media)

Network Clients (class = NetClient)

Network Service (class = NetService)

Network Transport (class = NetTrans)

Printers (class = Printer)

Tape Drives (class = TapeDrive)

ChkINF has been tested with the following Perl interpreters:

GNU Perl 5.005_02 compiled for Win32

Perl for Win32 5.003_07 from ActiveWare Internet Corp.

ChkINF does not support Unicode. To run ChkINF on a Unicode .inf file, first save the file as an ASCII text file.

ChkINF does not automatically search the \Winnt\Inf directory or any other directory for INCLUDEd .inf files. Use the /I argument when calling ChkINF to direct the tool to look for INCLUDEd .inf files in a specific directory.

ChkINF warns for any sections that are not referenced by a directive elsewhere in the INF file. This is a change from previous versions of the tool, which reported errors for un-referenced sections.

For Display .inf files, ChkINF does not check for all relevant Registry keys. An .inf file that passes with no errors may not function correctly.


TD-22.2 Devctl Test

This program is designed to crash drivers by calling them through various user mode I/O interfaces. It does not test the functionality but rather the dis-functionality of drivers. Drivers should be resilient to bad data from user mode in exactly the same way that kernel entry points have to be. If they are not resilient then they open up denial of service attacks and in some cases a mechanism to bypass system security. This program attempts to locate drivers that don’t handle these calls gracefully:

  1. Unexpected entry points into the driver. For example file system query functions to a sound card.
  2. Query functions with buffers that are too small to contain all the data to be returned.
  3. IOCTL/FSCTL functions with missing buffers or buffers that are two small or contain garbage.
  4. IOCTL/FSCTL with direct I/O or type3 buffers with data changing asynchronously.
  5. IOCTL/FSCTL with bad pointers for type3 requests.
  6. IOCTL/FSCTL and fast path query functions where the users buffer mapping may change asynchronously. Pages become unreadable at arbitrary execution points.
  7. Relative opens with strange file names, Opens to strange device objects like the direct device open or file system devices.
  8. Issues requests both synchronously and asynchronously to the device.

Graceful behavior does not include any of the following:

  • The system crashes.
  • System memory pools are corrupted.
  • Memory is leaked.
  • IRPs are not completed correctly.

While the program runs it writes lines to the file crashn.log. After each line is written the file is flushed so that in the event of a crash the offending operation is easy to determine should the system be difficult to debug. The flush operation makes this operation expensive so in some places only one portion of a block of operations is logged. For example, only logs for IOCTL for a particular function value are logged rather than each IOCTL. When the program is restarted it takes the last line from crashn.log and places it in the file crash.log. This is assumed to be a failed operation. Operations within crash.log are not performed again by default.

After each operation is performed a check on consumed memory within the system is done. The pool tag database and lookaside information is queried. If this operation caused either one of these memory sources to be depleted the operation is repeated. Obviously this increase in memory consumption may have had nothing to do with the request that was just performed. Typically the second call won’t see an increase and the program continues. Real memory leaks show up as a vast number of repeated calls and the tag in question raised to the top of the poolmon display sorted by difference (d).

For calls that would typically be buffered I/O operations the program tracks the number of exceptions the operating system has dispatched. If the number of exceptions increases the operation is also repeated. Although buffered I/O operations may also reference the users address space, its rare and exception dispatching may signal an internal error that’s being handled by an exception handler masking a true parameter or handle validation problem. Devctl can run with the bottom hardware page mapped so that NULL pointer de-references don’t raise exceptions but return garbage. This gives another possible path to show up bad validation.

Candidates for pool leaks and exceptions are logged to a file (diags.txt) should the leak not crash the system or the many repeated calls are missed by the user.

The programs basic execution passes are:

  1. Issue various opens. Synchronous, Asynchronous, Direct, Relative (with various filenames). These catch drivers that are unaware of the relative open semantics and the fact they have to do their own security checks and drivers that may have word integer overflow problems manipulating file names.
  2. Issue queries for just about all possible items the driver might understand.
  3. Issue miscellaneous functions with the file handle like flush, create section, read and write (for asynchronous handles only). Reads and writes for obscure file offsets are performed. These include append writes where the file offset is a 2^64-1 and reads and writes where the offset is an unsigned 63 bit quantity that wraps to a signed 64 bit value when the length is added on. These catch read and write paths that don’t know the full semantics of file offsets or have overflow problems in their validation.
  4. Issue miscellaneous handle less functions such as NtDeletefile, NtQueryFullAttributesFile etc. These exercise some of the fast open paths used for network queries etc.
  5. Issue an IOCTL and FSCTL pass with zero length input and output buffers. This pass detects the most common driver error of not checking buffer length properly.
  6. Issue random IOCTL and FSCTL calls with random size buffers. For buffered I/O requests the buffers are valid but contain random data. For Direct I/O requests the buffers are valid, contain random data that changes asynchronously with this threads execution and are butted to the ends of H/W pages to make more likely references beyond buffer end will fail.
  7. For type 3 buffers the pointers are random.

After IOCTL passes and as part of a ‘miscellaneous function calls pass’ devctl issues a cancel request to the driver. IRPs that were lost (never completed by calling IoCompleteRequest or passed to other drivers but finished with by the device) will cause the process to hang. Through some paths popups appear from the I/O manager warning that IRPs didn’t cancel within an allotted time. These lost IRPs are easily debugged by issuing ‘!process 0 0’ from the debugger. Select the devctl process via a ‘!process xxx’ where xxx is the CID (Client ID) . The IRP (possibly more that one) will show up queued to one of the devctls threads. Use ‘!IRP xxxx’ where xxx is the IRP address to work out what IRP was lost. Occasionally IOCTL or FSCTL requests will pass parameter validation by a driver and will pend for a synchronous request (say some kind of notify request to a driver). Hitting ^C will cause the program to terminate in this case but not for a lost IRP case.

The basic syntax for the program is:

devctl [/i] [/l] [/il nn] [/iu mm] [devnam]

/ and + enable options, - disables options

/a Do all devices in system. Don't prompt for yes/now etc

/al Alert the main thread periodically

/c Enable or disable skipping operations that aborted or crashed

/dl nn Sets lower limit for device type portion of IOCTL and FSCTL code

/du nn Sets upper limit for device type portion of IOCTL and FSCTL code

/e Enable or disable zero length EA's, needed on checked builds

/f Enable or disable all FSCTL paths

/fn Enable or disable FSCTL paths with null buffers

/fr Enable or disable FSCTL paths with random buffers

/fl nn Sets lower limit for function portion of IOCTL and FSCTL code

/fu nn Sets upper limit for function portion of IOCTL and FSCTL code

/h /? Prints this message

/g c h Grabs a handle from another process

/i Enable or disable all IOCTL paths

/if Enable or disable all FSCTL and IOCTL paths

/in Enable or disable IOCTL paths with null buffers

/ir Enable or disable IOCTL paths with random buffers

/l Enable or disable logging and skipping failing functions

/m Enable or disable the misc functions

/n Map zero page so that NULL pointer de-references don't raise

/p Enable or disable the checks on pool usage via tags and lookaside lists

/q Enable or disable the normal handle query functions

/r Enable or disable skipping operations already logged as done

/s Enable or disable the sub or relative opens to obtain handles

/t nn Set maximum number of IOCTL/FSCTL calls made with random buffers

/v Enable or disable the printing of error status values for calls

Devnam is the device to open to issue requests. It must be in native object tree format like ’\device\null’. If this is omitted the program prompts for each device in turn. You can skip to a particular device by typing ‘/prefix’ where prefix is the first few characters of the device you want to match. Here is a typical run:

E:\neillc\devctl>obj\i386\devctl \device\null

Listen socket on port 1192 address 172.31.236.194

Trying to open device \device\null synchronous

Opened crashn.log for reading

Lookaside: PooL, size 128 up 2

Pool: Mdl , Paged up 0, NonPaged up 128

\device\null Open synchronous

Opened file \device\null with access 1f03ff

Pool: File, Paged up 0, NonPaged up 192

Pool: CcBc, Paged up 0, NonPaged up 160

\device\null NtQueryObject ObjectNameInformation

NtQueryObject failed c0000004

NtQueryObject failed c0000004

Lookaside: Pool, size 128 up 1

NtQueryObject failed c0000004

\device\null NtQueryInformationFile FileBasicInformation

\device\null NtQueryInformationFile FileStandardInformation

\device\null NtQueryInformationFile FileInternalInformation

…

…

E:\neillc\devctl>obj\i386\devctl

Listen socket on port 1194 address 172.31.236.194

Device 809A61A0 registered with WMI

Device 8098FC20 registered with WMI

Device 8098F660 registered with WMI

Device 80945B30 registered with WMI

Device 8093DB50 registered with WMI

Device 80948040 registered with WMI

Device 80954040 registered with WMI

Device 80954A80 registered with WMI

Device 80947040 registered with WMI

Device 80947A20 registered with WMI

Device 80946040 registered with WMI

Device 80946A20 registered with WMI

Device 80943A60 registered with WMI

Device 80945040 registered with WMI

Device 80945CF0 registered with WMI

Device 8093DCF0 registered with WMI

Open device Cdfs? /null

Matching "null" against "Cdfs"

Matching "null" against "000126"

Matching "null" against "ASYNCMAC"

Matching "null" against "Afd"

Matching "null" against "Beep"

Matching "null" against "CdRom0"

Matching "null" against "DmLoader"

Matching "null" against "Floppy0"

Matching "null" against "FloppyPDO0"

Matching "null" against "FsWrap"

Matching "null" against "FtControl"

Matching "null" against "Gpc"

Matching "null" against "Hal Pci 0"

Matching "null" against "IdeDeviceP0T0L0"

Matching "null" against "IdeDeviceP1T1L0"

Matching "null" against "IdeFdo809a1288Channel0"

Matching "null" against "IdeFdo809a1288Channel1"

Matching "null" against "IdePort0"

Matching "null" against "IdePort1"

Matching "null" against "Ip"

Matching "null" against "KeyboardClass0"

Matching "null" against "KsecDD"

Matching "null" against "LanmanDatagramReceiver"

Matching "null" against "LanmanRedirector"

Matching "null" against "LanmanServer"

Matching "null" against "Mailslot"

Matching "null" against "MountPointManager"

Matching "null" against "Mup"

Matching "null" against "NTPNP_PCI0000"

Matching "null" against "NamedPipe"

Matching "null" against "Ndis"

Matching "null" against "Null"

Open device Null? y

Trying to open device Null synchronous

Opened crashn.log for reading

Lookaside: Pool, size 32 up 4

Pool: AfdC, Paged up 0, NonPaged up 192

\Device\Null Open synchronous

Opened file Null with access 1f03ff

Pool: File, Paged up 0, NonPaged up 192

\Device\Null NtQueryObject ObjectNameInformation

NtQueryObject failed c0000004

NtQueryObject failed c0000004

Lookaside: Pool, size 128 up 1

Lookaside: Pool, size 192 up 1

NtQueryObject failed c0000004

\Device\Null NtQueryInformationFile FileBasicInformation

\Device\Null NtQueryInformationFile FileStandardInformation

\Device\Null NtQueryInformationFile FileInternalInformation

\Device\Null NtQueryInformationFile FileEaInformation

\Device\Null NtQueryInformationFile FileAccessInformation

\Device\Null NtQueryInformationFile FileNameInformation

\Device\Null NtQueryInformationFile FileModeInformation

\Device\Null NtQueryInformationFile FileAlignmentInformation

Lookaside: PooL, size 128 up 1

Pool: Sect, Paged up 128, NonPaged up 0

Pool: CcSc, Paged up 0, NonPaged up 320

\Device\Null NtQueryInformationFile FileAllInformation

\Device\Null NtQueryInformationFile FileStreamInformation

Pool: VadS, Paged up 0, NonPaged up 32

\Device\Null NtQueryInformationFile FilePipeInformation

\Device\Null NtQueryInformationFile FilePipeLocalInformation

\Device\Null NtQueryInformationFile FilePipeRemoteInformation

^C

E:\neillc\devctl>

Here is an example leak:

C:\>g:\nt\nttest\security\tiger\devctl\obj\i386\devctl -if

…

Open device \Device\000167? /dfs

…

Open device \Dfs? y

…

\Dfs Open synchronous

Opened file Dfs with access 1f03ff

…

\Dfs NtQueryVolumeInformationFile FileFsVolumeInformation

Pool: Mup , Paged up 0, NonPaged up 131136

Lookaside: Scs$, size 64 up 2

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Hal , Paged up 0, NonPaged up 288

Pool: Irp , Paged up 0, NonPaged up 384

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Lookaside: Ntfi, size 264 up 1

Pool: Mup , Paged up 0, NonPaged up 130944

Lookaside: Ntfi, size 264 up 2

Lookaside: Scs$, size 64 up 1

Pool: Mup , Paged up 0, NonPaged up 131008

Pool: Mup , Paged up 0, NonPaged up 129536

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131008

Lookaside: Ntfi, size 264 up 1

Lookaside: Scs$, size 64 up 1

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 130752

Pool: Mup , Paged up 0, NonPaged up 130944

Pool: Mup , Paged up 0, NonPaged up 131008

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Lookaside: PooL, size 256 up 1

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Mup , Paged up 0, NonPaged up 131136

Lookaside: Scs$, size 64 up 2

Pool: Mup , Paged up 0, NonPaged up 131136

Pool: Hal , Paged up 0, NonPaged up 288

Pool: Irp , Paged up 0, NonPaged up 768

^C

Memory: 65080K Avail: 3424K PageFlts: 0 InRam Krnl: 4632K P: 1916K

Commit: 52972K Limit: 666632K Peak: 108844K Pool N: 6312K P:10324K

Tag Type Allocs Frees Diff Bytes Per Alloc

Mup Nonp 84551 ( 0) 9870 ( 0) 74681 4779584 ( 0) 64

SYSA Paged 2227 ( 0) 750 ( 0) 1477 67136 ( 0) 45

CM Paged 6542 ( 0) 5854 ( 0) 688 8877504 ( 0) 12903

Vad Nonp 1460 ( 0) 1000 ( 0) 460 29440 ( 0) 64

File Nonp 3434 ( 0) 3137 ( 0) 297 57024 ( 0) 192

C:\>type diags.txt

\Dfs NtQueryVolumeInformationFile FileFsAttributeInformation Pool: Mup , Paged

up 0, NonPaged up 65600

The IOCTL and FSCTL passes take forever as the space is huge. You can get must quicker coverage if you know the range of IOCTL’s the driver accepts. Here is the procedure with IPNAT:

//

// NAT-supported IOCTL constant declarations

//

#define IOCTL_IP_NAT_SET_GLOBAL_INFO \

_IP_NAT_CTL_CODE(0, METHOD_BUFFERED, FILE_WRITE_ACCESS)

#define IOCTL_IP_NAT_CREATE_INTERFACE \

_IP_NAT_CTL_CODE(2, METHOD_BUFFERED, FILE_WRITE_ACCESS)

…

…

#define IOCTL_IP_NAT_DELETE_REDIRECT \

_IP_NAT_CTL_CODE(13, METHOD_BUFFERED, FILE_WRITE_ACCESS)

The first number in this macro is the function number. You can limit devctl to just cover this range with a command like devctl +fl 0 +fu 13. This limits both the IOCTL and FSCTL zero length and random buffer calls. This will run quite quickly so its probably worth increasing the number of random buffers the program throws at the driver with say +t nnnn.


TD-22.3 Driver Verifier

This paper describes Wustamp.exe, a utility for automatic insertion of the DriverVer directive in INF files for drivers created for the Microsoft® Windows® 2000 and Windows 98 operating systems. This paper also includes details on Windows Update device driver publishing.

Overview

Driver Verifier is a tool that can monitor one or more kernel-mode drivers to verify that they are not making illegal function calls or causing system corruption. Driver Verifier performs extensive tests and checks on the target drivers. For example, if the driver uses memory at an improper IRQL, improperly calls or releases spin locks and memory allocations, or frees memory pool without first removing any timers, Driver Verifier will issue the appropriate bug check.

When the driver is unloaded, Driver Verifier checks to see that the driver has properly cleaned up its queues, worker threads, and other such items.

In addition, Driver Verifier can perform any of the following actions:

  • Allocate the driver's memory requests from a special pool. This action detects if the driver accesses memory outside of its allocations, or accesses memory after freeing its allocation.
  • Place extreme memory pressure on the driver by invalidating pageable code. This action reveals attempts to access paged memory that occur at the wrong IRQL or while holding a spin lock.
  • Randomly fail pool allocation and other memory requests. This action tests the driver's ability to cope with low-memory conditions.
  • Verify that all memory allocations have been freed when the driver is unloaded, to ensure that the driver does not quietly leak memory.
  • Allocate the driver's IRPs from a special pool, and monitor the driver's I/O handling for other inconsistent behavior.

Setup

Results Interpretation

This section summarizes information about the parameters that might appear on the blue screen during bug checks.

Bug Check 0xC1: SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION

The SPECIAL_POOL_DETECTED_MEMORY_CORRUPTION bug check has value 0x000000C1. This signals that the driver wrote to an invalid section of the special memory pool.

Parameters

The following parameters are displayed on the blue screen. Parameter 4 indicates the type of violation.

Parameter 1 | Parameter 2 | Parameter 3 | Parameter 4 | Description
Address that the driver tried to free | Reserved | zero | 0x20 | Attempt to free pool which was not allocated
Address that the driver tried to free | Bytes requested | Bytes calculated | 0x21, |
0x22 | Attempt to free a bad address |  |  |
Address that the driver tried to free | Address where bits are corrupted | Reserved | 0x23 | Freeing an address when nearby bytes on same page have been corrupted
Address that the driver tried to free | Address where bits are corrupted | Reserved | 0x24 | Freeing an address when bytes after end of allocation have been overwritten
Current IRQL | Pool type | Number of bytes | 0x30 | Attempt to allocate pool at incorrect IRQL
Current IRQL | Pool type | Address that the driver tried to free | 0x31 | Attempt to free pool at incorrect IRQL

The _POOL_TYPE codes are enumerated in ntddk.h. In particular, zero indicates nonpaged pool and one indicates paged pool.

Resolving the Problem

Obtain a backtrace of the current thread. This backtrace will usually reveal the source of the error.

Bug Check 0xC2: BAD_POOL_CALLER

The BAD_POOL_CALLER bug check has value 0x000000C2. This signifies that the current thread is making a bad pool request.

Parameters

The following parameters are displayed on the blue screen. Parameter 1 indicates the type of violation.

Parameter 1 | Parameter 2 | Parameter 3 | Parameter 4 | Description
0x01, 0x02, or 0x04 | Pointer to pool header | First part of pool header contents | zero | Pool header has been corrupted
0x06 | Reserved | Pointer to pool header | Pool header contents | Attempt to free pool which was already freed
0x07 | Reserved | Pointer to pool header | zero | Attempt to free pool which was already freed
0x08 | Current IRQL | Pool type | Size of allocation | Attempt to allocate pool at an invalid IRQL
0x09 | Current IRQL | Pool type | Address of pool | Attempt to free pool at an invalid IRQL
0x40 | Starting address | Start of system address space | zero | Attempt to free kernel pool at user-mode address
0x41 | Starting address | Physical page frame | Highest physical page frame | Attempt to free a nonallocated nonpaged pool address
0x50 | Starting address | Start offset in pages from beginning of paged pool | Size of paged pool, in bytes | Attempt to free a nonallocated paged pool address
0x99 | Address being freed | zero | zero | Attempt to free pool with invalid address (or corruption in pool header)

The _POOL_TYPE codes are enumerated in ntddk.h. In particular, zero indicates nonpaged pool and one indicates paged pool.

Resolving the Problem

Activate the Driver Verifier to obtain more information about these errors.

Bug Check 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION

The DRIVER_VERIFIER_DETECTED_VIOLATION bug check has value 0x000000C4. This is the general bug check code for fatal errors found by Driver Verifier.

Parameters (General Driver Verifier codes)

The following parameters are displayed on the blue screen. Parameter 1 identifies the type of violation.

Parameter 1 | Parameter 2 | Parameter 3 | Parameter 4 | Description
0x00 | Current IRQL | Pool type | zero | Call to allocate zero bytes (minimum allocation one byte)
0x01 | Current IRQL | Pool type | Number of bytes | Attempt to allocate paged memory at an IRQL above APC_LEVEL
0x02 | Current IRQL | Pool type | Number of bytes | Attempt to allocate nonpaged memory at an IRQL above DISPATCH_LEVEL
0x03 | Current IRQL | Pool type | Number of bytes | Attempt to allocate too much of the MUST_SUCCEED pool (one page maximum)
0x10 | Bad Address | zero | zero | Trying to free an address that was not returned from an allocate call
0x11 | Current IRQL | Pool type | Address of pool | Attempt to free paged pool at an IRQL above APC_LEVEL
0x12 | Current IRQL | Pool type | Address of pool | Attempt to free nonpaged pool at an IRQL above DISPATCH_LEVEL
0x13 or 0x14 | Reserved | Pointer to pool header | Pool header contents | Attempt to free memory pool which was already freed
0x15 | Timer entry | Pool type (-1 for Special Pool) | Pool address being freed | Attempt to free pool which contains an active timer
0x16 | Reserved | Pool address | zero | Attempt to free pool at bad address, passing invalid parameters to memory routine
0x17 | Resource entry | Pool type (-1 for Special Pool) | Pool address being freed | Attempt to free pool which contains an active ERESOURCE
0x18 | Timer entry | -1 | DLL base address | Attempt to unload a driver whose DLL contains an active timer
0x19 | Resource entry | -1 | DLL base address | Attempt to unload a driver whose DLL contains an active ERESOURCE
0x30 | Current IRQL | Requested IRQL | zero | Attempt to lower the IRQL in KeRaiseIrql (or supplying an uninitialized parameter as IRQL)
0x31 | Current IRQL | Requested IRQL | zero | Attempt to raise the IRQL in KeLowerIrql (or supplying an uninitialized parameter as IRQL)
0x32 | Current IRQL | Spin lock address | zero | Call to KeReleaseSpinLock at an IRQL other than DISPATCH_LEVEL (perhaps due to double-release of spin lock)
0x33 | Current IRQL | Fast mutex address | zero | Attempt to acquire fast mutex at an IRQL above APC_LEVEL
0x34 | Current IRQL | Fast mutex address | zero | Attempt to release fast mutex at an IRQL other than APC_LEVEL
0x35 | Current IRQL | Spin lock address | Old IRQL | Kernel is releasing a spin lock when not at DISPATCH_LEVEL
0x36 | Current IRQL | Spin lock number | Old IRQL | Kernel is releasing a queued spin lock when not at DISPATCH_LEVEL
0x37 | Current IRQL | Thread APC disable count | Resource | A resource is being acquired, but APCs are not disabled
0x38 | Current IRQL | Thread APC disable count | Resource | A resource is being released, but APCs are not disabled
0x39 | Current IRQL | Thread APC disable count | Mutex | A mutex is being acquired "unsafe", but IRQL is not APC_LEVEL on entry
0x3A | Current IRQL | Thread APC disable count | Mutex | A mutex is being released "unsafe", but IRQL is not APC_LEVEL on entry
0x40 | Current IRQL | Spin lock address | zero | Call to KeAcquireSpinLockAtDpcLevel at an IRQL other than DISPATCH_LEVEL
0x41 | Current IRQL | Spin lock address | zero | Call to KeReleaseSpinLockFromDpcLevel at an IRQL other than DISPATCH_LEVEL
0x42 | Current IRQL | Spin lock address | zero | Call to KeAcquireSpinLock at an IRQL above DISPATCH_LEVEL
0x70 | Current IRQL | MDL address | Access mode | Call to MmProbeAndLockPages at an IRQL above DISPATCH_LEVEL
0x71 | Current IRQL | MDL address | Process address | Call to MmProbeAndLockProcessPages at an IRQL above DISPATCH_LEVEL
0x72 | Current IRQL | MDL address | Process address | Call to MmProbeAndLockSelectedPages at an IRQL above DISPATCH_LEVEL
0x73 | Current IRQL | Low 32 bits of the physical address (all 64 bits in Win64) | Number of bytes | Call to MmMapIoSpace at an IRQL above DISPATCH_LEVEL
0x74 | Current IRQL | MDL address | Access mode | Call to MmMapLockedPages in kernel mode at an IRQL above DISPATCH_LEVEL
0x75 | Current IRQL | MDL address | Access mode | Call to MmMapLockedPages in user mode at an IRQL above APC_LEVEL
0x76 | Current IRQL | MDL address | Access mode | Call to MmMapLockedPagesSpecifyCache in kernel mode at an IRQL above DISPATCH_LEVEL
0x77 | Current IRQL | MDL address | Access mode | Call to MmMapLockedPagesSpecifyCache in user mode at an IRQL above APC_LEVEL
0x78 | Current IRQL | MDL address | zero | Call to MmUnlockPages at an IRQL above DISPATCH_LEVEL
0x79 | Current IRQL | Virtual address being unmapped | MDL address | Call to MmUnmapLockedPages in kernel mode at an IRQL above DISPATCH_LEVEL
0x7A | Current IRQL | Virtual address being unmapped | MDL address | Call to MmUnmapLockedPages in user mode at an IRQL above APC_LEVEL
0x7B | Current IRQL | Virtual address being unmapped | Number of bytes | Call to MmUnmapIoSpace at an IRQL above APC_LEVEL
0x7C | MDL address | MDL flags | zero | Call to MmUnlockPages passed an MDL whose pages were never successfully locked
0x7D | MDL address | MDL flags | zero | Call to MmUnlockPages passed an MDL whose pages are from nonpaged pool (these should never be unlocked)
0x80 | Current IRQL | Event address | zero | Call to KeSetEvent at an IRQL above DISPATCH_LEVEL

The _POOL_TYPE codes are enumerated in ntddk.h. In particular, zero indicates nonpaged pool and one indicates paged pool.

Parameters (Memory Allocation Tracking codes)

The following parameters are used only when the Memory Pool Allocation Tracking option of Driver Verifier is active:

Parameter 1 | Parameter 2 | Parameter 3 | Parameter 4 | Description
0x51 | Base address of allocation | Corrupt address | Number of charged bytes | Driver is trying to free memory after having written past the end of the allocation
0x52 | Base address of allocation | Reserved | Number of charged bytes | Driver is trying to free memory after having written past the end of the allocation
0x53, or 0x54, 0x59 | Base address of allocation | Reserved | Reserved | Driver is trying to free memory after having written past the end of the allocation
0x60 | Bytes allocated from paged pool | Bytes allocated from nonpaged pool | Total number of unfreed allocations | Driver did not free all memory pools prior to unload
0x61 | Bytes allocated from paged pool | Bytes allocated from nonpaged pool | Total number of unfreed allocations | Driver is allocating pool (in another thread) at the same time as it is unloading

Resolving the Problem

If you are the driver writer, use the information obtained through this bug check to fix the bugs in your code.

If you are a system administrator, you should unload the driver if the problem persists.

After a Memory Allocation Tracking bug check, use the following command in the kernel debugger:

kd> dc ViBadDriver l1; dc @$p+4 l1; du @$p

This will return the name of the driver causing the error.

Then use the !verifier extension:

kd> !verifier 3 drivername.sys

This will return information about the leaked memory allocations.

Bug Check 0xC5: DRIVER_CORRUPTED_EXPOOL

The DRIVER_CORRUPTED_EXPOOL bug check has value 0x000000C5. This signifies that the system attempted to access invalid memory at a process IRQL that was too high.

Parameters

The following parameters are displayed on the blue screen.

Parameter | Description
1 | Memory referenced
2 | IRQL at time of reference
3 | zero: Read 1: Write
4 | Address that referenced memory

Comments

A driver has probably corrupted the system pool. This code is usually issued when the corruption was in a small allocation (less than PAGE_SIZE).

Resolving the Problem

To deal with this bug, use the Special Pool option of Driver Verifier. If this fails to reveal the guilty driver, use the Global Flags utility to enable the Special Pool by pool tag.

See also Bug Check 0xD0

Bug Check 0xC7: TIMER_OR_DPC_INVALID

The TIMER_OR_DPC_INVALID bug check has value 0x000000C7. This is issued if a kernel timer or delayed procedure call (DPC) is found somewhere in memory where it is not permitted.

Parameters

The following parameters are displayed on the blue screen.

Parameter | Description
1 | zero: Timer object one: DPC object two: DPC routine
2 | Address of object
3 | Beginning of memory range checked
4 | End of memory range checked

Comments

This condition is usually caused by a driver failing to cancel a timer or DPC before freeing the memory where it resides. When Driver Verifier is active, it will catch such errors and issue this bug check.

Resolving the Problem

If you are the driver writer, use the information obtained through this bug check to fix the bugs in your code.

If you are a system administrator, you should unload the driver if the problem persists.

Bug Check 0xC9: DRIVER_VERIFIER_IOMANAGER_VIOLATION

The DRIVER_VERIFIER_IOMANAGER_VIOLATION bug check has value 0x000000C9. This is the bug check code for all Driver Verifier I/O Verification violations.

Parameters (I/O Verification Level 1)

When Driver Verifier is active and I/O Verification has been set to Level 1, various I/O violations will cause this bug check to be issued. The following parameters will be displayed on the blue screen. Parameter 1 identifies the type of violation.

Parameter 1 | Parameter 2 | Parameter 3 | Parameter 4 | Description
0x01 | Address of IRP being freed | zero | zero | Attempt to free object whose type is not IO_TYPE_IRP
0x02 | Address of IRP being freed | zero | zero | Attempt to free IRP still associated with a thread
0x03 | Address of IRP being sent | zero | zero | Call to IoCallDriver with IRP Type not equal to IRP_TYPE
0x04 | Address of DeviceObject | zero | zero | Invalid device object passed to IoCallDriver
0x05 | Address of DeviceObject associated with offending driver | IRQL before IoCallDriver | IRQL after IoCallDriver | IRQL not preserved across call to driver dispatch routine
0x06 | IRP status | Address of IRP being completed | zero | IoCompleteRequest called with status marked as pending or equal to -1
0x07 | Address of cancel routine | Address of IRP being completed | zero | IoCompleteRequest called with cancel routine still set
0x08 | Address of DeviceObject | IRP major function code | Exception code | Invalid buffer passed to IoBuildAsynchronousFsdRequest
0x09 | Address of DeviceObject | I/O control code | Exception code | Invalid buffer passed to IoBuildDeviceIoControlRequest
0x0A | Address of DeviceObject | zero | zero | Device object with an already-initialized timer passed to IoInitializeTimer
0x0C | Address of IO status block | zero | zero | I/O status block passed to IRP is allocated on stack which has already unwound past that point
0x0D | Address of user event object | zero | zero | Event passed to IRP is allocated on stack which has already unwound past that point
0x0E | Current IRQL | Address of IRP | zero | Call to IoCompleteRequest with IRQL above DPC


Parameters (I/O Verification Level 2)

When Driver Verifier is active and I/O Verification has been set to Level 2, all the bug check parameters listed in the Level 1 section above are possible. In addition, many more I/O violations will be detected.

The Level 2 error codes are displayed in different ways on the blue screen, in a crash dump file, and in a kernel debugger. Note that the hexadecimal bug check code 0xC9 and the bug check string DRIVER_VERIFIER_IOMANAGER_VIOLATION do not appear on the blue screen or in the debugger, although they will appear in a crash dump file.

On the blue screen, the following data will be displayed:

  • The message IO SYSTEM VERIFICATION ERROR.
  • The name of the driver which caused the error, along with the address in the driver's code where the error was detected.
  • The message WDM DRIVER ERROR XXX, where XXX is a hexadecimal code representing the specific error. (See the following list of the I/O error codes and their meanings.)

If a kernel-mode crash dump has been enabled, the following information will appear in the crash dump file:

  • The message BugCheck 0xC9 (DRIVER_VERIFIER_IOMANAGER_VIOLATION).
  • The hexadecimal I/O error code. (See the list of the I/O error codes and their meanings.)
  • The address in the driver's code where the error was detected.
  • A pointer to the IRP.
  • A pointer to the DeviceObject.

If a kernel debugger is attached to the system which has caused this violation, the following information will be sent to the debugger:

  • The message WDM DRIVER ERROR, along with an assessment of the severity of the error.
  • The name of the driver which caused the error.
  • A descriptive string which explains the cause of this error. Often additional information is passed along, such as a pointer to the IRP. (See the list of these descriptive strings and what additional information is specified.)
  • A query for further action. Possible responses are b (break), i (ignore), z (zap), r (remove), or d (disable). Instructing the operating system to continue allows you to see what would happen "down the line" if this error had not occurred. Of course, this often will lead to additional bug checks.

Note No other bug checks can be ignored in this manner. Only I/O Verification Level 2 errors which occur when a kernel debugger is present can be ignored.

Resolving the Problem

If you are the driver writer, use the information obtained through this bug check to fix the bugs in your code.

If you are a system administrator, you should unload the driver if the problem persists.

Bug Check 0xCC: PAGE_FAULT_IN_FREED_SPECIAL_POOL

The PAGE_FAULT_IN_FREED_SPECIAL_POOL bug check has value 0x000000CC. This signals that the system has referenced memory which was earlier freed.

Parameters

The following parameters are displayed on the blue screen.

Parameter | Description
1 | Memory address referenced
2 | zero: Read one: Write
3 | Address that referenced memory (if known)
4 | Reserved

If the guilty driver can be identified, its name is printed on the blue screen and stored in PUNICODE_STRING parameter of KiBugCheckDriver.

Comments

The system has accessed Special Pool memory which was already freed by a driver. This usually indicates a system-driver synchronization problem.

This cannot be protected by try - except; it can only be protected by a probe.

Bug Check 0xCD: PAGE_FAULT_BEYOND_END_OF_ALLOCATION

The PAGE_FAULT_BEYOND_END_OF_ALLOCATION bug check has value 0x000000CD. This signals that the system accessed memory beyond the end of some driver's pool allocation.

Parameters

The following parameters are displayed on the blue screen.

Parameter | Description
1 | Memory address referenced
2 | zero: Read one: Write
3 | Address that referenced memory (if known)
4 | Reserved

If the guilty driver can be identified, its name is printed on the blue screen and stored in PUNICODE_STRING parameter of KiBugCheckDriver.

Comments

The driver allocated n bytes of memory from the Special Pool. Subsequently, the system referenced more than n bytes from this pool. This usually indicates a system-driver synchronization problem.

This cannot be protected by try - except; it can only be protected by a probe.

Bug Check 0xD0: DRIVER_CORRUPTED_MMPOOL

The DRIVER_CORRUPTED_MMPOOL bug check has value 0x000000D0. This signifies that the system attempted to access invalid memory at a process IRQL that was too high.

Parameters

The following parameters are displayed on the blue screen.

Parameter | Description
1 | Memory referenced
2 | IRQL at time of reference
3 | zero: Read one: Write
4 | Address that referenced memory

Comments

A driver has probably corrupted the system pool. This code is usually issued when the corruption was in a large allocation (PAGE_SIZE or larger).

Resolving the Problem

To deal with this bug, use the Special Pool option of Driver Verifier. If this fails to reveal the guilty driver, use the Global Flags utility to enable the Special Pool by pool tag.

An alternate method is to set the \\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\ProtectNonPagedPool registry key equal to DWORD 1 and reboot. Then the system will unmap all freed nonpaged pool. This will prevent drivers from corrupting the pool. (This does not protect the pool from DMA hardware, however.)

See Also Bug Check 0xC5

Bug Check 0xD4: SYSTEM_SCAN_AT_RAISED_IRQL_CAUGHT_IMPROPER_DRIVER_UNLOAD

The SYSTEM_SCAN_AT_RAISED_IRQL_CAUGHT_IMPROPER_DRIVER_UNLOAD bug check has value 0x000000D4. This signifies that a driver did not cancel pending operations before unloading.

Parameters

The following parameters are displayed on the blue screen.

Parameter | Description
1 | Memory referenced
2 | IRQL at time of reference
3 | zero: Read one: Write
4 | Address that referenced memory

If the guilty driver can be identified, its name is printed on the blue screen and stored in PUNICODE_STRING parameter of KiBugCheckDriver.

Comments

This driver failed to cancel lookaside lists, DPCs, worker threads, or other such items before unload. Subsequently, the system attempted to access the driver's former location at a raised IRQL.

Resolving the Problem

To deal with this bug, use a kernel debugger to get a stack trace. If the guilty driver has been identified, activate Driver Verifier and attempt to replicate this bug.

Bug Check 0xD5: DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL

The DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL bug check has value 0x000000D5. This signals that a driver has referenced memory which was earlier freed.

Parameters

The following parameters are displayed on the blue screen.

Parameter | Description
1 | Memory address referenced
2 | zero: Read one: Write
3 | Address that referenced memory (if known)
4 | Reserved

If the guilty driver can be identified, its name is printed on the blue screen and stored in PUNICODE_STRING parameter of KiBugCheckDriver.

Comments

The Driver Verifier Special Pool has caught the driver accessing memory which was earlier freed.

This cannot be protected by try - except; it can only be protected by a probe.

Bug Check 0xD6: DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION

The DRIVER_PAGE_FAULT_BEYOND_END_OF_ALLOCATION bug check has value 0x000000D6. This signals the driver accessed memory beyond the end of its pool allocation.

Parameters

The following parameters are displayed on the blue screen.

Parameter | Description
1 | Memory address referenced
2 | zero: Read one: Write
3 | Address that referenced memory (if known)
4 | Reserved

If the guilty driver can be identified, its name is printed on the blue screen and stored in PUNICODE_STRING parameter of KiBugCheckDriver.

Comments

The driver allocated n bytes of memory and then referenced more than n bytes. The Driver Verifier Special Pool detected this violation.


TD-22.4 WHQLDbg

Describe test here

Setup

The purpose of WHQLdbg is to ensure robustness of the printer driver while running the WHQL certification tests. This tool will work on Windows 2000 and later operating system. At this time WHQLdbg.exe Version 0.5 is setup only to track kernel mode failures.

The main focus of the test is too ensure that when using the other WHQL tools, the printer driver or related systems do not cause the system to blue screen. No fault injection settings are enabled.

WHQLdbg.exe will enable the following items:

1. Page heap for spooler

2. Heap tagging for spooler

3. Driver verifier

4. Heap tail checking for spooler

5. Heap free checking for spooler

6. Heap parameter checking for spooler

7. Heap validation on call for spooler

8. Place heap allocations at ends of pages and mark next page read only for spooler

9. Turns off reboot on crash

10. Setup log file for all debug output

Setup

In oder to run this tool the debugger and kernel symbols must be on the system. In the dir where WHQLdbg is executed from. Also the default memory dump settings must be active on the system.

Command line args:

WHQLdbg.exe /on = Turns on debugging

WHQLdbg.exe /off = Turns off debugging

WHQLdbg.exe /check = Checks for a kernel mode breaks

WHQLdbg.exe /clean = Deletes the old dump file

Usage:

First the "/on" command should be called to enable debugging, the system needs to be rebooted for the settings to take effect.

Before each test is run, the "/clean" option should be called to wipe out any old breaks.

After each test the "/check" option should be called, this will generate the log file for pass or fail. If a break is found, the driver will be failed even if the WHQL test itself passed.

Results Interpretation


TD-22.5 Disabler

Disabler.exe is a command-line tool that repeatedly disables and re-enables (or, optionally, removes/refreshes) a Device Manager object for use in testing how that driver responds to many load/unload events. This test works on both Microsoft® Windows® 2000 and Microsoft Windows 98.

Note: WHQL is currently using this for some of their programs.

Setup

Results Interpretation


TD-22.6 PMTE Test Description

[New - v.0.5]

Overview

PMTE is a power management test. It tests devices in a system for functionality, and at the same time cycles the system and supports sleep states.

The devices tested:

DISKS
CD-ROMS
Serial ports
Modems
Sound output
IRDA
Parallel ports

Setup

A kernel debugger is needed because PMTE will break into the debugger when a test process is hanging. This way the issue can be debugged. Since PMTE cycles the system through the system states, the only way to know what was done last when the system hangs, is from what PMTE has logged to the debugger.

Required Hardware

None. Only the machine or specific hardware that is being certified is needed.

Required Software

Kernel Debugger

Results Interpretation

PMTE will log errors on a nonworking device before or after going to a sleep state. It will also log an error if the system fails to go into a sleep state, and others. The default log file name is pmte.log.

Reading pmte.log

PMTE basically pauses and restarts all the device tests, and puts the system into different sleep states. It does these actions synchronously. In the log file any of these actions is preceded with a ===. If one of these major would fail it would contain a line like below.

ERROR Work item completed with Error Code: ####

These are not the only errors that get reported. See the Logging Errors section below for a list of all the different errors PMTE reports..

Below is a sample log file, with the major actions highlighted in red.

=== Initialize all tests === (D:25 H:18 M:25 S:49)

Test C:\ (DISK_0_C__.log)

Test D:\ (DISK_1_D__.log)

Test E:\ (CD_ROM_2_E__.log)

Test \\.\COM2 (COMPORT_3___._COM2.log)

Test Video (VIDEO_4_Video.log)

Test Devnodes (DEVNODES_5_Devnodes.log)

Test NET:\\acpisrv\pmte\io (NET_6_NET___acpisrv_pmte_io.log)

=== Start script run ===

Script file name: boot_test.psf

Test cycles: till: M:9 D:26 H:6 M:0

Number of Sleep states: 2

Sx State Sequence Skip : 0

=== TME_MEDIA_CHECK all tests === (D:25 H:18 M:25 S:50)

Video ,Video

Devnodes ,Seach for devnodes with problems

\\acpisrv\pmte\io\PMTE_ACPI-INTNIG-1 ,Net Read Write I/O

D:\PMTE_ACPI-INTNIG-1 ,Disk Read Write I/O

C:\PMTE_ACPI-INTNIG-1 ,Disk Read Write I/O

\\.\COM2 ,COMX Read Write I/O

E:\ ,CD-ROM Read test

=== Enable Hiberfile (D:25 H:18 M:25 S:54)

=== TME_RESTART_TESTING all tests === (D:25 H:18 M:25 S:55)

C:\PMTE_ACPI-INTNIG-1 ,Disk Read Write I/O

\\acpisrv\pmte\io\PMTE_ACPI-INTNIG-1 ,Net Read Write I/O

D:\PMTE_ACPI-INTNIG-1 ,Disk Read Write I/O

Video ,Video

E:\ ,CD-ROM Read test

\\.\COM2 ,COMX Read Write I/O

Devnodes ,Seach for devnodes with problems

=== Wait for 30 seconds (D:25 H:18 M:26 S:07)

=== TME_PAUSE_TESTING all tests === (D:25 H:18 M:26 S:38)

Devnodes ,Seach for devnodes with problems

D:\PMTE_ACPI-INTNIG-1 ,Disk Read Write I/O

Video ,Video

\\acpisrv\pmte\io\PMTE_ACPI-INTNIG-1 ,Net Read Write I/O

C:\PMTE_ACPI-INTNIG-1 ,Disk Read Write I/O

E:\ ,CD-ROM Read test

\\.\COM2 ,COMX Read Write I/O

=== Wait for 5 seconds (D:25 H:18 M:26 S:39)

=== S1 , Wake method: RTC . Set to wake in 4 Min. Latency 420 Sec. Count 0 === (D:25 H:18 M:26 S:44)

Flags = POWER_ACTION_QUERY_ALLOWED, POWER_ACTION_UI_ALLOWED,

PBT_APMQUERYSUSPEND (D:25 H:18 M:26 S:44)

PBT_APMSUSPEND (D:25 H:18 M:26 S:44)

PBT_APMRESUMEAUTOMATIC (D:25 H:18 M:30 S:51)

System woke up in time: Elapsed time=0:0:4:7:298

=== Wait for 20 seconds (D:25 H:18 M:30 S:52)

=== TME_RESTART_TESTING all tests === (D:25 H:18 M:31 S:12)

D:\PMTE_ACPI-INTNIG-1 ,Disk Read Write I/O

C:\PMTE_ACPI-INTNIG-1 ,Disk Read Write I/O

Video ,Video

\\acpisrv\pmte\io\PMTE_ACPI-INTNIG-1 ,Net Read Write I/O

\\.\COM2 ,COMX Read Write I/O

E:\ ,CD-ROM Read test

Devnodes ,Seach for devnodes with problems

This log snippet indicates that PMTE

  1. Initialized all the tests,
  2. Check media for all devices
  3. Enable the hiberfile
  4. Restarted testing all device
  5. Waited for 30 seconds
  6. Pause testing of all devices
  7. Waited for 5 seconds
  8. Then enable RTC timer to wake in 4 minutes, and put the system to S1 sleep

Detailed description of different log items.

Times in pmte.log

When PMTE does a major action it logs a time with it. The times in pmte.log are in the below format. (D:25 H:18 M:26 S:44) These are absolute times.

    === TME_RESTART_TESTING all tests ===

This action is to start or restart testing devices. A list of device follows.

    === TME_PAUSE_TESTING all tests ===

This action is to pause testing of devices. A list of device follows. Depending on how PMTE was started, not all test will actual pause I/O on this. Device types that can support to do I/O with out getting errors to the device while we are going to suspend will usually not pause I/O. Disks and sound devices are an example of these devices. But comports and modems will pause I/O before we suspend.

    === S# , Wake method: # Set to wake in # Min. Latency ### Sec. Count # ===

    === S# , Wake method: # . Count # ===

This action states that we are going to sleep/hibernate.

  1. S# : The number after the S is the type of sleep state. S4 would indicate system is going to hibernate. S1 through S3 are sleep states.
  2. Wake method: Possible wake methods are
  • "Manual": The user needs to press the power button to wake the system.
  • "RTC": System will wake automatically using the RTC timer.
  • "Reset Hibernate", where system will go into hibernate but the system will not turn off the power to the system, but instead will reset the system.
  3. # Min : Indicates in how many minutes it will take to wake the system from this sleep state.
  4. Latency ### Sec. : This is the number that indicates how much later a system can actually wake then what Min reads till we will flag it as an error. This number is in seconds.
  5. Count #: Indicates how many sleep cycles have already been tested.

Errors in pmte.log

When an error is reported from testing a device, it is done when I pause or restart testing a device. Each error will consist of multiple lines and each line will be preceded with the word ERROR. See examples below.

=== TME_PAUSE_TESTING all tests === (D:27 H:18 M:20 S:55)

Devnodes ,Seach for devnodes with problems

ERROR \\.\COM2 , Status=3221235498 , COMX Read Write I/O

ERROR There is no serial loop back attached.

C:\PMTE_ACPI-HPLH4-1 ,Disk Read Write I/O

D:\PMTE_ACPI-HPLH4-1 ,Disk Read Write I/O

Video ,Video

E:\ ,CD-ROM Read test

\\acpisrv\pmte\io\PMTE_ACPI-HPLH4-1 ,Net Read Write I/O

Errors because one of the device tests are not responding usually means that there is some problem with the device this test is testing. Depending on how PMTE is started PMTE will do different things when a test is hanging. It any case it logs an error that the test timed out to ACK (acknowledge) the state change (see first red line below). After that line it list the test in question. Below is an example log snippet where the devnodes test is hanging.

=== TME_RESTART_TESTING all tests === (D:18 H:00 M:58 S:47)

C:\PMTE_SMITTYDBG15 ,Disk Read Write I/O

\\.\IRDA ,Irda test

D:\PMTE_SMITTYDBG15 ,Disk Read Write I/O

\\.\Sound ,Sound (Did you hear sound?)

\\acpisrv\pmte\io\PMTE_SMITTYDBG15 ,Net Read Write I/O

ERROR Timed out waiting on test to ACK the state change.Time=480

ERROR Test DEVNODES, Device Devnodes, Test terminated=NO

ERROR Failed to terminate one or more test processes

Errors because the system wakes too late or too soon will also be preceded with the word ERROR. PMTE will also log the elapsed time. In the example below the system woke to soon, the system work in 1.46 minutes even so the RTC timer was programmed to wake the system in 4.

=== S1 , Wake method: RTC . Set to wake in 4 Min. Latency 420 Sec. Count 0 === (D:28 H:14 M:21 S:21)

Flags = POWER_ACTION_QUERY_ALLOWED, POWER_ACTION_UI_ALLOWED,

PBT_APMQUERYSUSPEND (D:28 H:14 M:21 S:21)

PBT_APMSUSPEND (D:28 H:14 M:21 S:21)

ERROR System woke to soon: Elapsed time=0:0:1:47:381

PBT_APMRESUMEAUTOMATIC (D:28 H:14 M:23 S:09)

PBT_APMRESUMESUSPEND (D:28 H:14 M:23 S:09)

Errors because the system failed to go to sleep, are shown in the example below. It shows that the system failed to go into S4 (hibernate). This error is also preceded with the word ERROR. The first line will read

"ERROR Work item completed with Error Code: #### "

Where #### is the error number the going to seep API returned. The next error line gives what this error means.

=== S4 , Wake method: Reset Hibernate Count 197 === (D:21 H:05 M:16 S:31)

Flags = POWER_ACTION_QUERY_ALLOWED, POWER_ACTION_UI_ALLOWED,

PBT_APMQUERYSUSPEND (D:21 H:05 M:16 S:31)

PBT_APMSUSPEND (D:21 H:05 M:16 S:31)

PBT_APMRESUMEAUTOMATIC (D:21 H:05 M:16 S:32)

ERROR Work item completed with Error Code: 2001

ERROR The specified driver is invalid.

ERROR PO_ERROR_FAILED_SLEEP_STATE

=== Wait for 20 seconds (D:21 H:05 M:16 S:32)

* * *

Setup

Results Interpretation


TD-22.7 Off-limit API Checker

Describe test here

Setup

Results Interpretation


TD-22.8 Plug and Play Driver Test

The purpose of the Plug and Play Driver test is to provide driver writers with a tool which exercises various PnP related codes paths in the driver and user mode components. If used in conjunction with Driver Verifier, driver writers can feel more confident that their code is performing properly. This tool is only for use on Windows 2000.

Although by using this tool a driver will be forced to handle almost all the PNP IRPs, there are three areas that are stressed specifically – Removal, Rebalance, and Surprise Removal. The test provides a mechanism to test each of these separately or all together (i.e, stress). This is accomplished using a combination of user mode API calls (via the test app) and kernel mode API calls (via an upper filter driver).

Setup

In order to run the test, the test’s INF (pnpdtest.inf) must be copied to the %SystemRoot%\INF directory and the driver (pnpfiltr.sys) must be copied to the %SystemRoot%\system32\drivers directory.

Removal

Device removal is tested by selecting the target device and clicking the "Test Removal" button. This encompasses IRP_MN_QUERY_REMOVE_DEVICE, IRP_MN_CANCEL_REMOVE_DEVICE, and IRP_MN_REMOVE_DEVICE.

The test will attempt to install its upper filter driver on the target device stack. This results in a query-remove IRP – if this query-remove is failed the machine may need to be rebooted in order to get the filter driver onto the device stack. If the remove request is not vetoed, the device stack will be removed and restarted with the filter driver on top (class drivers and class filters on the FDO will still be above the test’s filter driver).

The test, using Setup APIs will cause a query-remove to be sent to the device stack. The filter driver will fail this remove request thus causing a cancel-remove IRP to be sent. The filter driver will assert that the cancel-remove was successful.

Next, the test app calls the appropriate class installer and any registered co-installers to disable/enable and remove/reenumerate the device (this tests the class/co-installers handling of DIF_PROPERTYCHANGE with DICS_DISABLE, DICS_ENABLE, and DICS_PROPCHANGE). When receiving an IRP_MN_REMOVE_DEVICE, the filter driver will assert that the lower drivers completed it successfully.

The test will again call the class/co-installers this time with DIF_REMOVE and then will reenumerate the device’s parent to attempt to restart the device.

Of course, each of these steps involves a preliminary remove request. If that request if vetoed, the device will not be removed. It is up to the driver writer’s discretion to veto a remove request when appropriate, such as while streaming video on a USB camera or if the target device is in the boot/paging path. Bear in mind that simply failing all remove requests is generally not good practice – it will not guarantee that driver will never receive a remove since a remove IRP will still be issued after a surprise removal or if anyone in the device stack fails a start IRP.

Rebalance

Rebalance is tested by selecting the target device and clicking the "Test Rebalance" button. This encompasses IRP_MN_QUERY_STOP_DEVICE, IRP_MN_STOP_DEVICE, and IRP_MN_CANCEL_STOP_DEVICE.

As with the removal test, the test application will attempt to add an upper filter to the target device stack. If this is not successful (i.e., if someone on the target device stack failed the query-remove IRP) the machine may need to be rebooted in order to test rebalance.

Using Plug and Play Io APIs the test application and the filter driver will cause a query-stop IRP to be sent to the target device stack. The device stack will be guaranteed to receive a query-stop and cancel-stop IRP. The filter driver will assert that the cancel-stop IRP is not failed by lower drivers.

The device will only receive a stop IRP if the following two conditions are true:

  • The target device consumes hardware resources.
  • All drivers in the device stack (and children) succeed the query-stop IRP.

If both of these conditions are met, a stop IRP will be issued by the system, followed eventually by a start IRP. The filter driver will assert that the start IRP following a stop IRP is not failed.

If the target device does not consume hardware resources, stop IRP handling can still be tested. This is accomplished by testing rebalance on a resource consuming ancestor of the device. For example, consider a USB mouse connected to a USB controller enumerated by PCI. The mouse does not consume resources, but the USB controller does. If the USB controller and all its children succeed query-stop, the controller and all of its children will receive a stop IRP.

Surprise Removal

Surprise removal is tested by selecting the target device and clicking "Test Surprise Removal". This encompasses IRP_MN_SURPRISE_REMOVAL followed by IRP_MN_REMOVE_DEVICE.

As with the previous tests, the test application will attempt to add an upper filter to the target device stack. If this is not successful the machine may need to be rebooted in order to test surprise removal.

When triggered by the test application, the filter driver will cause the system to send an IRP_MN_SURPRISE_REMOVAL to the device stack, followed by an IRP_MN_REMOVE_DEVICE. The filter driver will assert that both of these IRPs are completed successfully by lower drivers.

After handling these IRPs, the device will be marked by the system with the status code DN_HAS_PRIVATE_PROBLEM. The device will still appear in the device tree in Device Manager because, since it has not actually been physically removed, it will still be reported by its bus driver in response to an IRP_MN_QUERY_DEVICE_RELATIONS for BusRelations. In order to restore the device to working order, the PDO for the device must be deleted. This can be accomplished by rebooting the system, removing and reenumerating the device’s parent, or physically removing the device and reattaching it.

Stress

All of the above scenarios can be tested together by selecting the target device and clicking "Start Stress". The test application will randomly test rebalance and remove for five minutes after which it surprise removes the device. As with the above scenarios, the test application tries first to install an upper filter driver. If the filter is not successfully added, only remove and query-remove are guaranteed to be tested.

Results Interpretation

Errors encountered by the test in calls to Plug and Play APIs will be recorded to a log file. However, errors asserted by Driver Verifier and other built in verification mechanisms are not recorded.


Welcome to the Anti-Virus/File System Filter test kit

Welcome to the Anti-Virus/File System Filter (AV/FSF) Test Kit for Microsoft Windows 2000, SP1. This is a logo testing kit for anti-virus file system filter drivers. ISVs that pass these tests will receive a test report from Windows Hardware Quality Labs. (WHQL) stating that they have met the logo requirements. For future operating systems, a digital signature (CAT file) will be issued with approved passing logs for kernel mode drivers. This new test kit contains file system-related test suites, driver-related logo compliance tests, and tests that exercise anti-virus filter drivers.

Note: The AV/FSF test kit contains more recent versions of tests in the IFS Test Kit.

The AV/FSF test kit includes tests that examine the following functionality:

  • Devctl tests named device objects created by drivers by calling them through various user-mode I/O interfaces.
  • Driver Verifier tool verifies selected drivers. This tool does not generate a log file.
  • Floppy I/O test exercises the floppy drive.
  • USB Disabler test enumerates all USB drives starting at the root, and exercises the enable and disable functionality.
  • IFSTEST tests the file system interface transparency.
  • CDTest exercises the CD-ROM drive. This test does not generate a log file.
  • PMTE exercises the system hibernation functionality.
  • IOSTRESS test exercises the I/O subsystem. This test launches the Driver Verifier tool from within the stress engine.

In addition, the AV Scenario tests include:

  • IFSTEST-AV, the IFS Test Suite, with a virus generation engine that tests anti-virus filter drivers.
  • IOSTRESS-AV, the iostress mix, with the anti-virus generation engine.

The AV/FSF Test Kit includes test procedures, test specifications, and logo requirements. To submit test results to WHQL, download and execute the WHQL License Agreements.

Related links
  • The Anti-Virus/File System Filter test kit overview
  • AV/FSF Device Path Exerciser Test Specification
  • AV/FSF Windows 2000/NT I/O Stress Test Specification
  • AV/FSF IFS Test Specification
  • File System Filter Logo Requirements for Windows2000


The Anti-Virus/File System Filter test kit overview

The AV/FSF Test Kit contains file system-related test suites and generic driver-related tests for Microsoft Windows 2000, Server SP1 logo requirements compliance. Windows Hardware Quality Labs (WHQL) uses the test logs in the AV/FSF Kit to issue a test report from Microsoft stating that they have met the logo requirements. For future operating systems, WHQL issues a digital signature (CAT file) for approved passing logs for the kernel mode drivers.

It takes approximately five days to test Anti-Virus/File System Filters.

Hardware requirements

To run the AV/FSF tests, you need the following system requirement.

Note: Please use a logo'd system listed in the HCL http://www.microsoft.com/hcl as your test system that supports S0-S3 sleep states.

  • 128 MB of RAM
  • Floppy drive
  • External removable media USB drive (zip drive)
  • CD ROM drive
  • Network card

Software requirements

  • Windows 2000, Server SP1

Tester knowledge requirements

To run the AV/FSF tests, testers need to know how to do the following tasks:

  • Partition a hard drive.
  • Set up workgroups.
  • Assign privileges to workgroups.
  • Create users.
  • Add registry values.
Related links
  • Preparing the test system for AV/FSF testing


Preparing the test system for AV/FSF testing

The following information describes the test system requirements, tester knowledge requirements, the AV/FSF kit, and the test log files for the Windows 2000, Server SP1 testing. You must run the tests on single CPU and dual/multi CPU architectures.

Test system requirements

To run the AV/FSF tests, you need the following equipment:

  • Install Windows 2000, Server SP1, with:
  • 128 MB of RAM
  • Floppy drive
  • External removable media USB drive (zip drive)
  • CD ROM drive
  • Network card
  • Partition the hard disk with at least a 2 GB/partition as:
  • C:\ FAT32 boot volume
  • D:\NTFS formatted volume without compression enabled
  • E:\NTFS formatted volume with compression enabled
  • F:\FAT16 formatted volume
  • G:\FAT32 formatted volume
  • Set up the system in a workgroup, not a domain, so users can set privileges and add users with a known password. Give the following privileges to the Local Administrator group of test machine:
  • Act as part of the operating system.
  • Create a token object.
  • Replace a process-level token.
  • Increase quotas.

Tester knowledge requirements

To run the AV/FSF tests, testers need to know how to do the following tasks:

  • Partition a hard drive.
  • Set up workgroups.
  • Assign privileges to workgroups.
  • Create users.
  • Add registry values.
Related links
  • Configuring the test system


Configuring the test system

Note: Run the AV/FSF Kit from an account in the Local Administrators group.

To configure the test system

  1. On the test system, in the Local Users and Groups menu, create a group, where:
  • The group name is ifschild
  2. Add ifstest as a user to the ifschild group, and then set the user password to ifstest.

The user is not required to change the password when logging on.

  3. From the Start menu, select Run, and then type setaudit.exe.

The setaudit.exe is located in the hct\Generic_file_System_filter_tests\ifstest\i386\ folder.

  4. From the Start menu, select Run, and then type setpermissions.exe.

The setpermissions.exe is located in the hct\Generic_file_System_filter_tests\ifstest\i386\ folder.

  5. In Administrative Tools, click Local Security Policy, click Local Policies, and then click Audit Policy.

The Local Security Settings window appears.

  6. Set the following permissions for the ifschild user group:
  • Access this Computer via Network
  • Act as part of the Operating System
  • Backup Files and Directories
  • Bypass Traverse Checking
  • Change the System time
  • Create a page file
  • Debug Programs
  7. In the Policy list, double-click Audit Object Access.

The Local Security Policy Setting dialog box appears.

  8. Select the Success and Failure check boxes, and click OK.
  9. Close the Local Security Settings window.
  10. Add the following registry value to run the quota tests:
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
  • Name: NtfsQuotaNotifyRate
  • Type: REG_DWORD
  • Value: 0000
  11. Go to hct\hct\Generic_file_system_filter_tests\IFSTEST\i386, and copy datacoh.exe to the root directory of each volume being tested.


Installing the AV/FSF test kit

Run the test kit on a system connected to a remote debugger. See the DDK for debugging tools.

To install the AV/FSF test kit

  1. Copy the HCT folder to your boot volume as HCT-filekit.
  2. Click HCT-filekit\hwtest to start the installation.

The HCT installation window appears.

  3. Click Generic file system filter tests to install the AV/FSF test kit.

The Test Manager window appears.

  4. Run the following tests:

Note: The log files are placed in the HCT\testbin directory.

  • Generic_file_system_filter_tests
  • Anti-virus_scenario_tests


The Anti-virus/File System Filter Kit

The AV/FSF Kit consists of a collection of specific file system related test suites, AV scenario-based tests (that apply to AV applications only) and generic driver related tests, which test for compliance with the logo requirements. The tests must be run on both single CPU and dual/multi CPU architectures for maximum coverage. The test configuration is as follows:

  1. Windows 2000, Server SP1, with at least 128 MB RAM, floppy drive, external removable media USB/1394 drive (ex., VST Firewire Zip drive), and CD ROM drive. The hard disk must be partitioned as described next with at least 2GB/partition.
  2. Hard disk must be partitioned as:
  • C:\ FAT32 boot volume
  • D:\NTFS formatted volume without compression enabled
  • E:\NTFS formatted volume with compression enabled
  • F:\FAT16 formatted volume
  • G:\FAT32 formatted volume


Generic_file_system_filter_tests

The Generic_file_system_filter_tests contain the following:

  • Driver Verifier
  • Devctl
  • Floppy I/O
  • USB_Disabler
  • PMTE
  • CDTest
  • IFSTEST-AV
  • I/OSTRESS-AV


CD test

This test exercises the CD-ROM drive.

Note: This is not a required test.

Run Time: Infinite loop.

Log file name: No log file is created.

Operating system: Windows 2000, Server SP1

Test assertion: Chapter <xx>

Related links

Running the CD test


Running the CD test

To run the CDTest test

  1. In the Test Manager window, click Generic_file_system_filter_tests, click CDTest, select CDTest, click Add, and then click Start.
  2. The test automatically runs. Close CDTest windows to abort the test


Devctl test

This test queries for the device name, using the native object tree format. You must run this test before you run the remaining AV/FSF tests.

Run Time: Varies, depending on the device object.

Log file name: crashn.txt

Operating system: Windows 2000, Server SP1

Test assertion: Chapter 22

Related links

Running the Devctl test


Running the Devctl test

To run the Devctl test

  1. In the Test Manager window, click Generic_file_system_filter_tests, click Devctl, select Devctl, click Add, and then click Start.

The Devctl command window appears.

  2. Type the device name using the following format, and press Enter:

\device\filespy

Note: To run the test on the named object starting with prefix, type /prefix at the querying prompt where Prefix is the first few characters of the device you want to match.

The Open Device question appears.

  3. Type y, and then press Enter.

The test runs automatically. Repeat steps 2 and 3 for all named device objects created by your drivers. For unnamed objects, run devctl on the device object to which the unnamed object attaches. When the tests are complete, the Test Results window appears.

  4. When done with all device objects created by your drivers, enter q at the query prompt to quit.
  5. Click View Logs, select the test log file from the list displayed, and then click Details.
  6. Examine and submit test logs to WHQL with your test submission.


Driver Verifier test

The Driver Verifier test examines only unsigned drivers that are designed for Windows 2000, Server SP1. The Driver Verifier test stresses device/driver combinations and tests the device's use of system resources, including the driver's memory paging behavior.

The Driver Verifier test examines device/driver combinations using the following verification types:

  • Special Pool
  • Force IRQL Checking
  • Pool Tracking
  • Low Resource Stimulation (Fault Injection)

For more information on Driver Verifier and the Driver Verifier verification types, see the latest version of the Windows 2000 DDK, section 5.1 "Driver Verifier":

Run time:

  • Ifselected drivers are verified: approximately 4-5 hours

Log file name:verifier.log

Operating system: Windows 2000, Server SP1

Test assertion: Chapter 22

Related links

Running the Driver Verifier test


Running the Driver Verifier test

  1. In the Test Manager window, click Generic_file_system_filter_tests, select the Driver Verifier test, click Add, and then click Start.

The Driver Verifier dialog box appears.

  2. On the Settings tab, select the driver(s) under test.
  3. In the driver list, select the drivers you want to test, which include all kernel mode drivers in your product, set your Verify Settings to match the following values, click Apply, and then click Verify.
  • IO Verifier - select
  • Level 2 – select
  • Special pool – select
  • Force IRQL checking
  • Low resource simulation – select
  • Pool tracking - select

The driver verifier is turned on.

  4. Click the Settings tab, and locate the drivers you selected.

If the following message appears in the Status column: "Reboot system", then reboot the test system.

  5. From the Windows desktop, click Start, select Programs, select HCT, and then click Test Manager Restart.


Floppy I/O, USB Disabler, and PMTE tests

The floppy I/O tests exercises the floppy drive and performs reads and writes to the floppy. The USB Disabler test is an enumeration test that enumerates the USB devices starting with the HUB and disables and enables them. PMTE stresses the system and cycles it through S0-S3 sleep states and tests whether all devices wake up from standby and hibernation.

Run Time: 1 hour, 5 minutes to 1 hour, 30 hours

Log file name: diskload.log, disabler.log, pmte.log

Operating system: Windows 2000, Server SP1

Test assertion: Chapter 22

Related links

Running the Floppy I/O, USB_Disabler, and PMTE tests


Running the Floppy I/O, USB_Disabler, and PMTE tests

To run the Floppy I/O, USB_Disabler, and PMTE tests

  1. In the Test Manager window, click Generic_file_system_filter_tests, select the following tests in the following order, click Add, and then click Start:
  • Floppy_IO
  • USB_Disabler
  • PMTE

The tests run automatically, in the order you selected them. When the tests are complete, the Test Results window appears.

  2. Click View Logs, select the test log file from the list displayed, and then click Details.
  3. Examine and submit test logs to WHQL with your test submission.


IFSTEST-AV test

This test checks whether the filter system filter driver complies with the NT file system semantics.

Note: Ensure that the anti-virus application is scanning and is set to delete, or quarantine virus files.

Run Time: 1-2 hours

Log file name: ifstest-av.log

Operating system: Windows 2000, Server SP1

Test assertion: Chapter 21

Related links

Running the IFSTEST-AV test


Running the IFSTEST-AV test

  1. In the Test Manager window, click Anti-virus_Scenario_tests, click ifstest-av, select ifstest-av, click Add, and then click Start.
  2. Click View Logs, select the test log file from the list displayed, and then click Details.
  3. Examine and submit test logs to WHQL with your test submission.


Running the I/O Stress-av test

To run the I/O Stress-AV test

  1. In the Test Manager window, click Anti-virus_Scenario_tests, click iostress-av, select iostress-av, click Add, and then click Start.

The I/O Stress dialog box appears.

  2. Click the System Settings tab, and click Preferred Settings for Stress.
  3. Click the Registration and Verifier tab.
  4. In the Verify Drivers text box, type the driver file names.

Note: For more than one file name, separate each file name with a comma (,).

  5. Click Preferred Settings to turn on the settings for the specified drivers.
  6. Click the Run Info tab, select the Specify Number of hours to run check box, and type 72:00.
  7. Click the Stress Tests tab, and click Run.

The I/O Stress test automatically selects a random number of files to run the tests on. The I/O Stress statistics window appears in the upper right corner of the screen.

Note: The system will reboot at the end of the test.

  8. After 72 hours, from the Windows desktop, click Start, select Programs, select HCT, and then click Test Manager Restart.

The Test Results window appears.

  9. Click View Logs, select the test log file from the list displayed, and then click Details.
  10. Examine and submit test logs to WHQL with your test submission.


Introduction to the IFS test kit test plan

Objectives:

The primary objective of this test plan is to document how WHQL examines the installation, usability, and cleanup of the IFS test kit. The IFS test kit is a combination of tests that you use to confirm that an IFS driver is robust under stress, and to perform interface tests. These IFS software packages are third-party applications that use the Windows® 2000 IFS interfaces to hook file system requests for their own purposes (such as anti-virus products and backup software).

WHQL evaluates the test kit submission as a package, and evaluates each test by the log files recorded and the results returned via the GUI interface. Measurable test items include:

  • Verify that the test kit functionality is intact.
  • Verify proper Test Manager interface or wrapper installation.
  • Check tests for complete installation (for example, do all files copy correctly?).
  • Test operability within Test Manager environment, and via a command shell.
  • Perform log file comparison with actual test pass/fail results and Test Manager report.

This document is intended for review and use by the WHQL IFS kit development team. Additional audiences include:

  • Developers that assisted in the creation of the test kit
  • Microsoft employees
  • External partners

You do not need special APIs, registry keys, drivers, or development tools to perform these tests. The only items you need are Windows 2000 Service Pack 1, and the test kit.


Component testing

Functionality tests

The test kit examines IFS functionality from the beginning. WHQL evaluates the installation process for ease of use, and corrects file copy and installation, and documentation. WHQL designed the IOSTRESS test groups to perform maximum or minimum type of testing for performance boundary tests. WHQL examines the other hardware and software tests using a variety of command line options to vary the test runs.

Run the functionality tests from the Test Manager, as well as via the command line. Use scripts to run the command line tests, and copy the test logs from each run to a separate location for analyzing later. Compare these logs against the Test Manager report to determine if the results are being properly reported to Test Manager, and if Test Manager displays them correctly.


Key scenarios

Key testing points, based on previous failures, include:

  • Test logs reporting the proper severity for each failed test.
  • Test Manager displays all tests in the left column of the GUI.
  • All necessary files are copied to the proper location(s).
  • The test runs clean up their "mess" appropriately.

If a reboot is required (for example, the createpagefile test), then the cleanup is measured after the reboot.

  • Changing the device types used for stress tests and IFS tests by using external devices (Jaz, Zip, SCSI, IEEE-1394) and different size partitions for internal devices (SCSI and IDE).
  • Checking for presence of new options and UI screens. WHQL does not expect new screens for the 2195 builds.


New features

Check for the presence of new functionality or unexpected screens, options that are enabled or disabled, or new items that were not in the previous build(s).


Vanilla configuration

The best testing scenario for the IFS test kit includes running the test on a system with no add-on or third-party components. This provides a baseline for test comparison.


Stress

The IOSTRESS test handles most of the file system interaction with the IFS software. Additional software can be added after the basic test kit is proven sound.


Leaks

WHQL assumes that all tests are correct and do not cause leaks. The scope of this test plan does not cover leaks caused by third-party software.


Logging or administering the tests

The test kit stores logs for each test run from Test Manager, and runs from the command line. The test kit also stores the differences between Test Manager test runs and command-line test runs, and may report differences as bugs. WHQL analyzes error levels on failed tests to ensure that the proper level of failure was reported. Use Perl/Shell scripts for parsing the log file and extracting a subset of the log for each failure type.

Run individual tests from the command line, while selecting groups of related tests from the Test Manager. The test kit uses a series of scripts to launch individual tests for verification of results. Once again, use Perl/Shell scripts to parse each log file and check for errors and failures.

Most Test Manager tests run manually; however, the test kit plan attempts to start some test passes with as much script automation as possible.


Error messages

Errors often indicate failed tests, so examine the logs for clarity with regard to why a test failed and where. WHQL examines standard error messages, or contrived messages that occur.


Single test-group runs

Run each test group from the Test Manager shell as detailed in following topics, and also run test groups from a command line interface using Perl/Shell scripts, also described in following topics. Test Manager executes the IFS test groups as one item, although they consist of multiple tests.


Single-test runs

Run all individual tests (that aren’t part of a group) from a command line interface. The test scripts perform the individual tests automatically as described in the individual test run section.


Additional variations of the tests

After you establish a baseline, the following faults are planned as a set of additional test variations.

AntiVirus variation

Run the test on a system with an enabled AntiVirus filter driver that performs real-time detection and quarantine of viruses.

Long duration variations

As the requirements for certification require at least 72 hours for IOSTRESS and 72 hours for IFS runs with no Bugchecks, run all tests for at least 72 hours, possibly for 96 hours without interruption. Attach a debugger to these test-run PCs so that you can determine the cause of any errors.

Globalization variation

Changing the locale settings to various country and regional settings to verify that the test kit runs as expected through the Test Manager interface.


Untested or unsupported configurations

Setup requires build 2195 (Windows 2000) Server family operating systems, upgraded to SP1. The test kit plan does not support the upgrade path from one build to the next for the IFS kit.


Preparing for IFS testing

These test steps apply to running the test kit either from the test kit CD , or from a shared network.

Note: WHQL intends to deliver the IFS test kit on a CD. WHQL expects some anomalies when installing the IFS test kit from a network share.

Test system requirements

Set up the test system as defined in the hct\hct\docs\readme.doc file located in the certification kit. The tester confirms that the AV/FSF kit consists of the following equipment:

  • Collection of specific file system, related test suites, and generic driver-related tests, which test for compliance with the logo requirements.
  • Run the tests on both single CPU and dual/multi CPU architectures for maximum coverage.
  • WHQL uses the tests in the AV/FSF kit to validate anti-virus file system filters.

Test system configuration

To configure the test system

  1. Install the following:
  • Windows 2000, Server SP1
  • Minimum 128 MB of RAM
  • Floppy drive
  • External removable media USB drive (zip drive)
  • CD-ROM drive
  • Network card

Note: The hard disk drive must be partitioned as described below with at least 2 GB/partition.

  2. Partition the hard disk drive as follows:
  • C:\ NTFS boot volume
  • D:\NTFS formatted volume without compression enabled
  • E:\NTFS formatted volume with compression enabled
  • F:\FAT16 formatted volume
  • G:\FAT32 formatted volume
  3. Set up the machine in a workgroup—not a domain—so that the user can set the privileges and add user with known password.
  4. In Administrative Tools, click Local Security Policy, click Local Policies, click User Rights Assignment, and then assign the following privileges to the Local Administrator group for the test system:
  • Act as part of the operating system.
  • Create a token object.
  • Replace a process level token.
  • Increase quotas.
  5. In the Users group, create a test user on the test system, set the user name to ifstest, and then set the password to ifstest.

Note: Do not require the user to change the password on next logon.

  6. In Administrative Tools, click Local Security Policy, click Local Policies, select Audit PolicySet, and then activate the Audit Object Access to engage for both Success and Failure.
  7. Add the following registry value to run the quota tests:
  • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
  • Name: NtfsQuotaNotifyRate
  • Type: REG_DWORD
  • Value: 0000
  8. In hct\hct\Generic_file_system_filter_tests\IFSTEST\i386, copy the datacoh.exe to the root directory of each volume being tested.
  9. Run the AV/FSF kit from an account that is in the local administrators group.

If there is a significant difference, then either this test plan or the readme.doc needs to be revisited.

Note: You can use a system for testing the FsFct suite that has partitions less than 2 GB, and you can use partitions as small as 100 MB. The larger partitions are required for an extended test run (for example, the 72-hour run required by the WHQL driver signing program).


Driver Verifier test (internal test plan)

The Driver Verifier test examines only unsigned drivers that are designed for Windows operating systems. The Driver Verifier test stresses device/driver combinations and tests the device's use of system resources, including the driver's memory paging behavior.

The Driver Verifier test examines device/driver combinations using the following verification types:

  • Special Pool
  • Force IRQL Checking
  • Pool Tracking
  • Low Resource Stimulation (Fault Injection)

For more information on Driver Verifier and the Driver Verifier verification types, see the latest version of the Windows 2000 DDK, section 5.1 "Driver Verifier:"

Run time: 15 minutes (including a system reboot)

Log file name: Shrtver.log

Operating system: Windows Whistler

Test assertion: Chapter 22

Related links
  • Running the Driver Verifier test.


Running Driver Verifier test

To run the Driver Verifier test

  1. Select Driver Verifier test from the list, click Add, and then click Start.
  2. From the Settings tab, click Preferred Settings.
  3. Click Apply, and then click Exit.
  4. Click OK twice, and the System Shutdown prompt appears.

The system restarts. The HCT and Driver Verifier test appear automatically.

  5. Confirm that the settings are active, and then click Exit.
  6. Click View Results, and the test log message, ‘NOT RUN’ appears because the Driver Verifier test does not generate a log file.


CD Copy Compare (cdtest) test

This test copies and compares various amounts of data copied from a CD-ROM drive to a hard disk drive to verify that the hard disk drive functions properly with WHQL-designated core controllers. This test requires a CD-ROM with a minimum of 50 files in five directories, with files ranging in size from one byte to 500 KB. The target hard disk drive must have at least 125 MB of disk space available.

Note: This test is known to eventually cause a bugcheck on Windows 2000 SP1. It works only on a CD/DVD-ROM drive with powered eject/insert (i.e. not a notebook-type CD/DVD-ROM drive).

Run time: 3 minutes

Log file name: cdtest.log

Operating system: Windows Whistler

Test assertion: N/A

Logo requirement: B10.4.3.3


Running the CD Copy Compare (cdtest) test

To run the Driver Verifier test

  7. Select cdtest from the list, click Add, and then click Start.
  8. Confirm that this test is present, and runs correctly, then abort the test by closing each window manually (click the X on the title bar of each relevant CMD prompt).


The DevCtl test

DevCtl is very unfriendly, by design. When run, the test offers a choice of Symbolic links, which you use to identify the control device object for the driver.

  • You can skip to a particular device by typing /prefix where prefix is the first few characters of the device you want to match.
  • If running a vanilla variation, then choose /ntfs.
  • If running an anti-virus variation, type in the name of one of the device objects related to the anti-virus product.

Run time: depends on number of devices


Running the DevCtl test (internal test plan)

  9. Abort the test using Test Manager. View the log, and confirm that it is a fail.
  10. Run the test again and let it complete. Confirm that the log indicates success, and has the correct device object name in the log file.
  11. Press Q or q to exit DevCtl normally. Anything other method (CTRL+C) will cause a fail.


Floppy I/O tests

The Floppy I/O tests exercise the floppy disk drive and perform reads and writes to the floppy disk drive. The USB_Disabler test enumerates the USB devices starting with the HUB and disables and enables them. PMTE stresses the system and cycles it through S0-S3 sleep states and tests whether all devices wake up from standby and hibernation.

Run Time: 1 hour, 5 minutes to 1 hour, 30 minutes

Log file name: diskload.log, disabler.log, pmte.log

Operating system: Windows 2000, Server SP1

Test assertion: Chapter 22

Related links
  • Running the Floppy I/O tests
  • Running the Disabler (USB) test
  • Running the PMTE test


Running the Disabler (USB) test

Run time: 15 minutes

To run the Disabler (USB) test

  12. Before running the test, use Windows 2000 Device Manager to determine which USB devices are working, and note their presence and functional state.
  13. Run the test to completion. When it completes, view the log and confirm that this is successful.
  14. Use Windows 2000 Device Manager to determine that the USB devices list and state is the same as before running the Disabler (USB) test.


Running the IFSTEST test

Run time: Approximately 2 hours

To run the IFSTEST test

This provides a ‘copying files dialog’, and then runs a variety of tests.

  16. Let the test finish, and then verify the following:
  • If this is the anti-virus variation, expect the possibility of a fail. If the test does fail, confirm there are SEV2 errors in the logs.
  • If this is the vanilla variation, confirm that the log indicates success. There must be no SEV2 entries in the log.

To run the IFSTEST-AV test

This provides a ‘copying files dialog’, and then runs a variety of tests.

  17. Let the test finish, and then verify the following:
  • If this is the anti-virus variation, expect the possibility of a fail. If the test does fail, confirm there are SEV2 errors in the logs.
  • If this is the vanilla variation, confirm that the log indicates fail. There must be a number (probably many) of SEV2 entries in the log since the viruses were not detected.


Running the IOSTRESS test

Run time: Check run: 4 hours; Full run: 72 hours

To run the IOSTRESS test

  18. After installing the test suite on a vanilla system, launch IOStress-AV.
  19. Let the test run for a minimum of 72 hours.
  20. Reboot and check the logs.

The virus test logs appear as failures and 72 hours worth of test runs appear in the log files. Also check for driver verifier log events.

  21. Add an anti-virus product and rerun the IOSTRESS-AV tests after rebooting to ensure that the Anti-virus tests pass.

Important: The following list describes known issues with IOSTRESS test: If your Driver Verifier is turned on, and the Out of Resources window appears, then a bugcheck occurs. This event rarely occurs and WHQL does not plan to repair it in v. 2195. If the issue becomes more prevalent than expected, then WHQL will consider modifying the test requirements. This issue is not present in Whistler builds.

The stack for the IOSTRESS break looks similar to the following example:

0: kd> dc ee037d50 l2

ee037d50 c00000a1 00000000

0: kd> !thread 827168b0

THREAD 827168b0 Cid 8.18 Teb: 00000000 Win32Thread: 00000000 WAIT: (DelayExecution) KernelMode Non-Alertable

82716998 NotificationTimer

Not impersonating

Owning Process 8271daf0

WaitTime (seconds) 756990

Context Switch Count 3482476

UserTime 0:00:00.0000

KernelTime 0:00:08.0281

Start Address ntkrnlmp!ExpWorkerThread (0x80116db2)

Stack Init ee038000 Current ee037acc Base ee038000 Limit ee035000 Call 0

Priority 14 BasePriority 13 PriorityDecrement 1 DecrementCount 16

ChildEBP RetAddr Args to Child

ee037ae4 8012b72a 82174e08 ee037b48 00000000 ntkrnlmp!KiSwapThread+0x1b1

ee037b0c 8013cb3c 00000000 00000000 80172bb8 ntkrnlmp!KeDelayExecutionThread+0x182

ee037bc4 8013c669 e1f8bc20 e1f8bc24 fffd1226 ntkrnlmp!MiFlushSectionInternal+0x396

ee037c00 8010ecba 82151bd4 e1f8bc20 00001000 ntkrnlmp!MmFlushSection+0x11b

ee037cd4 8010e576 82151bd4 00000000 00000001 ntkrnlmp!CcFlushCache+0x3ae

ee037d0c 80112e04 82711f28 80174980 827168b0 ntkrnlmp!CcWriteBehind+0x124

ee037d78 80116e61 82711f28 00000000 00000000 ntkrnlmp!CcWorkerThread+0x158

ee037da8 801534c8 82711f28 00000000 00000000 ntkrnlmp!ExpWorkerThread+0xaf

ee037ddc 80168712 80116db2 00000000 00000000ntkrnlmp!PspSystemThreadStartup+0x54

00000000 00000000 00000000 00000000 00000000 ntkrnlmp!KiThreadStartup+0x16


Running the PMTE test

Run time: Approximately 16 hours

To run the PMTE test

  15. Start the test and run until completed.

This should take 16 hours (it is set to run until 7 a.m. the next day).


IFSTest VirusGroup testing with ISV drivers

The VirusGroup tests fail unless you install an anti-virus product.

There are special configuration options that you can choose for each specific anti-virus product. The following lists these options:

Guidefiles.dat contains three entries:

  • Virusfile1.evf, encode.exe, 0
  • Virusfile2.evf, eicar.com, 1
  • Virusfile3.evf, trivial.txt, 0

Assuming c:\ifstest\currentbin is the location of IFSTEST, c:\ifstest\currentbin\virusfiles\ contains:

  • Guidefile.dat
  • Virusfile1.evf
  • Virusfile2.evf
  • Virusfile3.evf

It may also optionally contain virusfile4.evf. This is eicar in a .zip file, which you can also use.

  22. Include the following runVirus script:

RUNVIRUS.CMD

Del vnorm.log vname.log vsize.log vgroup.log

Ifstest /t VirusNormalTest %1% /n vnorm.log /N 356789AB

Ifstest /t VirusNameTest %1% /n vname.log /N 356789AB

Ifstest /t VirusSizeTest %1% /n vsize.log /N 356789AB

Ifstest /g Virus %1% /n vgroup.log /N 356789AB

  23. Type Cd /d c:\ifstests\currentbin, press ENTER, and then type RunVirus D:
  24. In each of the following three log files: vnorm.log, vname.log, vsizelog, look for the "Total Files Processed" summary.
  • False detect should = 0
  • Not detected should = 0
  • There should be no Sev2 errors

Note: If this is not correct, either guidefile.dat is wrong, the AV product is not working, or the AV product is incorrectly configured.

  25. Check that vgroup.log contains no SEV2 errors.
  26. Uninstall the Anti-virus product and reboot the test system.