CD Copy Compare

This test copies and compares various amounts of data copied from a CD-ROM drive to a hard disk.

Parameters

Specify a CD-ROM drive and a hard disk.

Configuration

Insert the HCT or DDK CD-ROM in the CD-ROM drive being tested.

The target hard disk must have at least 50 MB of disk space available.

CD-ROM (Audio Cert)

The automatic CD-Audio test uses the MCI interface to play CD audio tracks automatically. It uses all functionality present in the MCI CD-Audio interface that affects the CD-ROM driver. Different operations are tried from different states. For example, seeking is done when the CD-ROM is playing, when it is stopped, and when it is paused. The mcicert.txt test script shows which commands are executed and what results are expected.

Configuration

These tests require you to insert the HCT CD-ROM in the drive used by MCI CD-Audio commands.

If you have more than one CD-ROM drive connected to your system, the test uses the default unit.

To change the default CD-ROM unit

1. Go to the Windows NT Control Panel.
2. Choose Multimedia Properties.
3. In CD Music, select the CD-ROM drive you want to use.

Recommendations

Make certain the HCT CD-ROM is in the CD-ROM drive. If you have problems, use MPlayer or CDPlayer to verify that the CD-ROM is visible as a CD-Audio device. You need not listen for audio output during this test.

CD-ROM (Audio Manual)

The automatic CD-Audio test uses the MCI interface to play CD audio tracks automatically. It uses all functionality present in the MCI CD-Audio interface that affects the CD-ROM driver. When you run this test it will run through verious audio tracks and prompt you to answer questions about the state of the CD. Some of these questions are answered by listening to the output coming from the speakers, some of these questions are answered by reaeding the most recent entry in the "WIN 32 MCI General Test" dialog.

CD Redbook Verification Test

This test tests the audio capabilities of the CD-ROM drive for compliance to the Redbook Audio Specification.

Extended BIOS Parameter Block

This test ensures that a block device will be able to use long file names without windows 32-bit mode drivers.

This test checks the device's support for extended BIOS parameter blocks and IOCTL code=48 by calling into the driver to get information about the drive, rebooting the computer, and verifying the results.

Parameters

None.

Disk Ioctl Test

1. Overview

Windows 2000 supports thirteen disk ioctls. This Test Tool is intended to ensure that these ioctls perform correctly given valid input, and that they return proper error codes and that they do not "crash" the system when given invalid input.

The test is broken up into three sections:

• Harmless ioctl testing: positive and negative tests for those ioctls that will not move, change, or otherwise corrupt the information on a disk.
  
  
• Harmful ioctl testing: positive and negative tests for those ioctls that will move, change, or otherwise corrupt the information on a disk.
  
  
• Invalid handle testing: negative testing which feeds valid handles to non-disk drives into the disk ioctls.
  

The test defaults to positive and negative testing of harmless ioctls and invalid handle testing of all ioctls. The default is that harmful ioctls will not be tested. This behavior can be changed using the command line flags, which will be explained later in this topic. In addition, the test defaults to running these tests on every drive in the system. This behavior can also be changed through the use of the command line arguments.


2. Harmless Ioctl Testing

There are ten so-called "harmless" disk ioctls. They are:

IOCTL_DISK_CHECK_VERIFY
IOCTL_DISK_GET_MEDIA_TYPES
IOCTL_DISK_GET_DRIVE_GEOMETRY
IOCTL_DISK_PERFORMANCE
IOCTL_DISK_GET_PARTITION_INFO
IOCTL_DISK_VERIFY
IOCTL_DISK_GET_DRIVE_LAYOUT
IOCTL_DISK_LOAD_MEDIA
IOCTL_DISK_EJECT_MEDIA
IOCTL_DISK_MEDIA_REMOVAL

2.1 Positive Testing

Each positive test attempts to call the ioctl using a handle to a valid system drive. If the ioctl call fails, the test is regarded as a failure. For those ioctls that return data about the drive, the data returned is printed to the log file.

Some ioctls are cannot be run on certain drive types.

• IOCTL_DISK_LOAD_MEDIA, IOCTL_DISK_EJECT_MEDIA, and IOCTL_DISK_MEDIA_REMOVAL may only be run on drives that support removable media. The test will attempt to detect whether or not the drive being tested supports removable media. If it does not, these tests will be skipped. If these tests are run, user interaction is required to load and remove disks into and out of the drive.
• IOCTL_DISK_FORMAT_TRACKS may only be run on a floppy disk drive. The test will attempt to determine whether or not the drive being tested is a floppy drive. If it is not, this test will be skipped.
• IOCTL_DISK_PERFORMANCE requires the diskperf service to be installed as a filter. If this service is not installed, this ioctl will fail. However, this failure will not be noted as a test failure in the test log.

2.2 Negative Testing

Each negative test attempts to call the ioctl in ways that should fail. If the ioctl call reports that it passed, or if the ioctl corrupts the system, a test failure has occurred.

Each ioctl is subjected to the following illegal input variations, if applicable for that ioctl:

Invalid handle value - the ioctl is called with valid input and output buffers, if necessary, but is given the value INVALID_HANDLE_VALUE as a handle.

Null handle - the ioctl is called with valid input and output buffers, if necessary, but is given a null handle.

Null input - if the ioctl requires input, the ioctl is called with a valid handle to a system drive, a valid input buffer size, and a null input buffer.

Null input and zero input size - if the ioctl requires input, the ioctl is called with a valid handle to a system drive, a null input buffer, and an input buffer size of zero.

Zero input size - if the ioctl requires input, the ioctl is called with a valid handle to a system drive, a valid input buffer, and an input buffer size of zero.

Null output - if the ioctl requires output, the ioctl is called with a valid handle to a system drive, a valid output buffer size, and a null output buffer.

Null output and zero output size - if the ioctl requires output, the ioctl is called with a valid handle to a system drive, a null output buffer, and an output buffer size of zero.

Zero output size - if the ioctl requires output, the ioctl is called with a valid handle to a system drive, a valid output buffer, and an output buffer size of zero.


3. Harmful Ioctl Testing

There are three so-called "harmful" disk ioctls. They are:

• IOCTL_DISK_FORMAT_TRACKS
• IOCTL_DISK_REASSIGN_BLOCKS
• IOCTL_DISK_SET_DRIVE_LAYOUT

Testing of these ioctls will not run by default. The user must instruct the test to run these ioctl tests through the use of the command line arguments. In addition, a specific drive must be given on which to test these ioctls, as they will most likely corrupt and destroy data on the disk.

3.1 Positive Testing

Each positive test attempts to call the ioctl using a handle to a valid system drive. If the ioctl call fails, the test is regarded as a failure. For those ioctls that return data about the drive, the data returned is printed to the log file.

Some ioctls are cannot be run on certain drive types.
IOCTL_DISK_FORMAT_TRACKS may only be run on a floppy disk drive. The test will attempt to determine whether or not the drive being tested is a floppy drive. If it is not, this test will be skipped.

3.2 Negative Testing

Negative testing is the same as that for harmless ioctls. See section 2.2 (Negative Testing) above.


4. Invalid Handle Testing

Invalid handle testing involves calling all of the disk ioctls with handles to non-disk drives. Each of these calls should return failure. The test will fail if any of the calls do not return failure, or if any of the calls cause a system access violation, a bluescreen, or cause the system to become unstable or corrupted.

To gather these valid handles to non-disk devices, QueryDosDevices is called. This call returns a multistring with the names of all the devices on the system. For each of these devices that is determined to not be a system drive, the test attempts to get a handle. If a handle can be created to this device, each ioctl is given a simple call using this handle.

5. Gathering Ioctl Input

Some of the disk ioctls require input buffers describing the function they are required to perform. For example, IOCTL_DISK_FORMAT_TRACKS requires the user to specify a starting location on the disk, the length of the format, and the type of disk media, among other things.

DiskIO gathers this data from an initialization file called "diskio.ini" that must be present in the same directory as diskio.exe. This contents of this initialization file must follow a very rigid format. The order of items may not be altered, and items may not be removed or inserted. The data values for each item, however, may be altered by the user to produce different test scenarios. If the format of this file is incorrect, the test will print an error message to this effect and will exit.

6. Command Line Arguments available if running the test as a stand-alone binary.

DiskIO makes use of several command line arguments that control certain parameters about the test.

Parameters allowed in testmanager

None.

FAT (File I/O)

This is an API-level test to verify that file operations work on a File Allocation Table (FAT)--formatted drive. The test uses various file I/O system calls to test the file allocation table.

Parameters

Specify one or more FAT-formatted disk partitions of at least 5 MB. By default, the test uses a FAT partition with enough space to run the test.

Configuration

The test requires at least one FAT-formatted disk. This test produces verbose output to the log file if you specify the proper environment variable when you run the test. For information about setting parameters, see Section 1.5, "Launching the Hardware Compatibility Test Kit."

Floppy I/O

This API-level test verifies file operations on a floppy disk.

Parameters

Specify a floppy disk drive. By default, the test uses the first floppy disk drive in the system (usually A).

Configuration

This test requires one floppy disk drive. You must provide a formatted, blank disk.

IDE Test

This test determines if the PCI IDE Controller has been programmed for bus mastering, if native mode support is enabled, if the IDE controller registers conform to spec, and if DMA has been enabled.

To enable DMA on the test system

You must enable DMA on the test system before you run the IDE test, otherwise it will fail.

1. On the Desktop, right-click My Computer. From the drop-down menu, select Manage. The Computer Management application appears.
2. On the Tree tab, select Device Manager. Device Manager appears in the right pane of the Computer Management application.
3. In Device Manager, expand "IDE ATA/ATAPI Controllers".
4. Under "IDE ATA/ATAPI Controllers", do the following for the "Primary IDE Channel", and for the "Secondary IDE Channel" (if available).
   1. Right click on the "Primary IDE Channel" or "Secondary IDE Channel".
   2. From the menu, choose Properties.
   3. In the IDE Channel Properties dialog, choose the Advanced tab.
   4. For each device listed in the Advanced tab, select "DMA is available" from the Transfer Mode drop-down
   5. Click OK.
   6. The System Setting Change dialog appears, prompting you to reboot your system. Click "Yes" to reboot now, or "No" to reboot later.

      After you reboot your system, the IDE Test will run properly.

Algorithm

1. The IDE Controller's PCI config. space registers are checked to see if bus mastering is/can be enabled. If not, then it is a FAIL.
2. The IDE Controller's PCI config. space registers are checked to see if native mode is supported. If not, then it is a FAIL. Native mode support is exempted only for a Multi-function South Bridge device.
3. The IDE controller registers are checked to see if they conform to ATA spec. Reserved bits should read 0. If not, then it is a FAIL.
4. The IDE controller status registers are checked to see if DMA is enabled. There are two status registers (one for each channel), each having two bits (one for each device). Let us name these bits as "DMA bits."

There are two flags in the registry which should be set to 1. The two flags are DmaEnabled and DmaDetectionLevel. If both flags are set to 1, then it means the IDE driver has turned on DMA. Even if one of them is set to any other value, it means the IDE driver has not turned on DMA.

• If DMA bits are set & Driver has turned on DMA, it is a PASS.
• If DMA bits are set & Driver has not turned on DMA, it is a FAIL.
• If DMA bits are not set & IDE devices in the machine are DMA capable, it is a FAIL.
• If DMA bits are not set & IDE devices in the machine are not DMA capable, then DMA capable IDE devices must be connected and the test must be re-run .

Issues

This test runs on Windows NT® 4.0 and Windows® 2000. The test will not appear in the HCT Test Manager if the system does not have a PCI IDE controller. If the system has more than one PCI IDE controller, the test results will report "not defined."

To help understand the DMA test results realize that the following register bits are checked by the IDE test:

• Command register (offset 0x04 in PCI configuration space) bit-2 should be set to indicate bus mastering.
• Programming Interface Byte registers (offset 0x09 in PCI configuration space) - bit-7 should be set to indicate bus mastering enabled.
• Bits-3,1 should be set to indicate native mode support (native mode support is exempted if the IDE controller is one of the functions of a multi-function south bridge).
• IDE Controller's Status registers at offset 0x02 & 0x0a (0x02 for primary 0x0a for secondary). These are offsets from the base address found in offset 0x20 in PCI configuration space.
• Bits-5,6 (bit-5 for master drive, bit-6 for slave drive) should be set if the devices connected are DMA capable.
• All other reserved bits should read zero.

IDE S.M.A.R.T. Disk

This test tests the S.M.A.R.T. drive for SFF-8035I compliance

Int 13H Extensions

This tests the proper implementation of the Phoenix Int 13h Extensions. These extensions allow the BIOS to access disks utilizing a 64 bit LBA, rather than the Cylinder, Head, and Sector addressing scheme, allowing the BIOS to fully utilize very large disks. The test is based off of the Phoenix Enhanced Disk Drive Specification Version 1.1 dated May 9, 1995. The spec defines the additional INT 13h functions, and their implementation.

This test runs in MS-DOS mode and will require a blank formatted floppy disk. The bootable disk will be created by Test Manager and the system must reboot and load MS-DOS from the floppy. The Int13 test will run and log the results to the floppy disk. After it completes the tests the user must reboot the system without the floppy in the drive. After Test Manager restarts it will prompt the user for the floppy disk and extract the required log results.

At least one CD-ROM drive and one hard disk drive should be attached to the test controller.

For complete storage testing it is recommended that the Int 13H Extensions test should be run with a removable media drive attached to the test controller as the boot device.Additionally, make sure that you do not have greater than two gigabytes (2 GB) of RAM installed in the test machine, or you will get RAM drive errors. If you get RAM drive errors, you will need to reduce the total installed RAM to 2 GB and re-run the test.

1. INT 13h, AH=41 (Check Extensions Present). The test checks that the BIOS returns values properly, in the proper registers.
   
   
2. INT 13h, AH=48 (Get Drive Parameters). The test checks the validity of these values returned, and stores the information for the Read, Write, Verify, Seek and Compare tests.
   
   
3. The test tries to use INT 13h commands that are said not to be supported. The spec clearly defines how the BIOS should react to being called with unsupported functions.
   
   
4. Seek Fakeout test issues 500 seeks to the first and last sectors on the disk. The test then issues 500 reads to the first and last sectors on the disk. The test will record the amount of time that it takes to perform both of these operations. If the seek time is less then 10% of the read time, the test will issue a warning. The spec clearly states that the BIOS should move the head on the disk to the proper sector when a seek command is issued. Some BIOS versions do not do this, but they simply return a good status back. The test can determine if this is actually occurring by timing the operations.
   
   
5. Functional tests. Issues the following sequence of commands to every LBA reported by function 48h: Seek, Read, Write, Write, Verify, Compare (which is two reads). More then 50 inaccessible LBAs result in a failure.
   
   
6. Functional tests II. Same as above but using randomized LBAs.
   
   
7. Removable commands issued (45h, 46h, and 49h), if applicable.

Parameters

None.

Issues

You must use a 1.44 MB formatted floppy disk when running this test. DMF formatted floppies and other non-standard floppy disk formats will cause errors with this test.

You must not use a write protected floppy when running this test. If you do, you will not receive an error message, however, when you reboot, you will get a non-bootable floppy error, and the test must be aborted by ejecting the floppy and booting the system off its normal boot drive. Additonally, no results are recorded.

Mapped (File I/O)

This is a test of mapping memory directly to disk. It is designed to use every byte of available space on the drive that you specify. Consequently, the duration of the test depends on the amount of space you have available. If you have a 1-MB partition, for example, the test completes quickly. With a larger partition, however, it takes several hours.

The test uses mapped I/O system calls to test file/memory mapping. You can use any file system format.

This test provides little status information while running.

Parameters

Specify one or more disk partitions. By default, the test uses the first partition it finds with enough space to run the test.

Configuration

This test requires at least one disk of any format.

Recommendations

Do not run this test on the drive that has the paging file. Because the test uses all available space, the paging file might not be able to grow, and the system might experience memory management problems.

While running, the test or system may appear to hang. It is not unusual for this test to take an hour to run on a small drive, and longer on large drives.

This test uses all the space in the root of each partition you specify. If the test terminates abnormally, it may not clean up after itself. If this occurs, delete the file mapio.dat from the root directory.

MCI CD Interface

The test issues a series of standard MCI commands to the CD-ROM and verifies it responds correctly to those commands. An audio CD must be in the drive to run this test. An enhanced (Data/Audio) CD may also be used. If you start the test with an enhanced CD, when the test Prompts with "did not find an audio CD", click ignore and the test will begin. Most ot the problems this test finds can be traced back to the CD-ROM firmware.

Parameters

None.

Issues

You must have a separate Audio CD or enhanced CD-ROM to complete this test. When an audio CD is inserted in the CD-ROM drive to begin this test, Windows 95 & 98 systems will auto launch CDPLAYER.EXE if autorun is enabled. Be sure to close CDPLAYER.EXE before starting the MCI CD test, otherwise the test will fail.

NTFS (File I/O)

This test uses various file I/O system calls to test the NTFS.

Parameters

Specify one or more NTFS-formatted disk partitions. By default, the test uses all NTFS partitions with enough space to run the test.

Configuration

This test requires at least one NTFS-formatted disk.

RAID Data Integrity Test

This test tests a system's RAID controller for errors in data transfer between hard disk drives.

Storage Device Stress (SdStress)

At least one CD-ROM drive and one hard disk drive should be attached to the test controller.

For complete storage testing it is recommended that the Int 13H Extensions test should be run with a removable media drive attached to the test controller as the boot device.

Overview:
SdStress tests storage API commands and stresses the hard disks and CD-ROMs in a system. SdStress is a console based application, there are no complicated GUIs for this version. It works entirely off of command line parameters and is a very flexible utility. There are many options available to the user:

• Total number of passes for each thread
  
• Thread multipliers for both CD-ROMs and Hard Disk Drives
  
• Adjustable Block sizing
  
• Randomized Block size selection
  
• Adjustable Test File size
  
• Debug output to a Kernel Debugger
  
• Three separate test scenarios (see below)
  
• Stress across network drives
  

Driver code coverage:
I/O Completion Ports were implemented in this stress utility, it was found that some pieces of device driver code (such as ATAPI) would not be executed without I.O Completion Ports. I/O Completion Ports are implemented in SdStress in a separate test scenario, for greater code coverage.

"Worker thread system"
All of the test cases built into SdStress utilize a worker thread system. This is how SdStress determines source and target worker threads while the user only has to specify which drives to stress. Please refer to the following examples for an explanation of the worker thread system.

Example 1:
In this example, the user has selected to run SdStress against one Hard Disk Drive (Drive C), and one CD-ROM (Drive D), as shown below (on the command line, the user would do this by entering 'sdstress /s:cd'). The arrows represent the threads of operation. In this case there will be only two:

SDSTRESS /S:CD

As you can see, the CD-ROM drive uses one thread copying from itself to the Hard Disk Drive, while the Hard Disk Drive has a thread copying from it to itself.

Example 2:
In this example, the user has selected to run SdStress against one Hard Disk Drive (Drive C), one Removable Medium device such as Iomega®'s Jaz® drive (Drive D), one CD-ROM (Drive E), and one Network Drive (Drive F) as shown below (on the command line, the user would do this by entering 'sdstress /s:cdef'). Again, the arrows represent the threads of operation. In this example, there will be twelve threads:

SDSTRESS /S:CDEF

Test Cases:
Scenario #1, CopyTestFile: (This is the only scenario run during system testing.)

The name of the first scenario is CopyTestFile, and it is so named because CopyTestFile is the name of the function in the code itself. This scenario is the most basic of the three and simply reads a block of data from the source, writes the block to the target, and then re-reads both and compares them. Note that the compare is done against an image in memory (with the exception of CD-ROMs), and both the source and destination are compared against this image rather then each other. This image is the same image that was used to create the test files at the beginning of the test. The blocks that are read and written are done in a set size. The default block size is the volume's sector size, although this can be overridden using the '/B:' or the '/R' switch. If there is a discrepancy between either the source or target images read back during the compare, SdStress will indicate at which offset in the buffer the discrepancy occurred, as well as what the expected and actual values were.

Scenario #2, CopyTestFileUsingIoC:

This scenario uses I/O Completion Ports and asynchronous file I/O to perform its writing. Again, this function operates based on the block size setting in the structure passed to it. This function works very similar to the others, in that it reads a block into memory, and then writes it. But when it is written, it is done using Overlapped I/O, so the return is immediate. The status of the write is later checked using the completion ports. The compare scheme is identical to the other scenarios. This scenario was implemented upon the advice of several members of the NT Base Development team.

Scenario #3, CopyTestFileMultiple:

This scenario is very similar to the first scenario, but the difference is that all read and write operations are done thirty two times in succession. For example, when this scenario goes to read a block, it enters a loop that will first set the file pointer backwards the size of the block (if it is not the first pass through the loop), and then it will issue the read command. This operation will be repeated thirty two times. The same is done for write operations. After the block has been copied, it is compared against the image in memory. This scenario was implemented with the idea that it may turn up caching problems on devices and / or adapters.

Key Functions:

AnalyzeCmdLine () - This function looks at all of the command line switches, and processes them accordingly.

AnalyzeDrives () - This function gathers all the information about the drives selected for stress. This includes getting the sector information, determining the type of device, and checking that the disk has sufficient space to run. This function also creates a structure that describes the device. This structure is crucial for the worker threads that are run later. Furthermore, this function will determine how many files are on a CD-ROM, if a CD-ROM drive is selected for stress.

CreateTestFile () - This function will create the source test files on all of the drives selected for stress. It generates a random pattern of data, and then writes the pattern to each device. This pattern of data is retained for later comparisons.

InitThreads () - This function initializes, and starts the primary worker threads. There are three embedded loops for determining which worker threads copy where. This function also creates the multiple threads, if specified. If the user specifies a thread multiplier of two for disk threads, then all disk related threads will have two instances. The same applies to CD-ROM threads, but a separate switch is required for this. When this function creates the threads, it creates them in a suspended state. Once all threads are created, they are started simultaneously.

SdStressThread () - This is the primary worker thread function. It determines source and target file names, and initiates the secondary worker threads. This thread is also responsible for determining which file shall be copied from a particular CD-ROM. Furthermore, this function is responsible for running CD-ROM threads endlessly until all others have finished. The reason for this is that since files are randomly copied off of the CD-ROM, sometimes very small files are selected. Since they are copied very quickly, a CD-ROM could go through all of its passes in a fraction of the time it may take a hard disk drive. One of the ideas behind this tool is generic devices stress, so it was necessary to keep CD-ROM threads running in a forever condition, until hard drive threads have completed.

GetRandomFile () - This function is responsible for walking down a CD's directory structure in the effort of randomly selecting a file. The first thing this function does is select a random number that is between one and the number of files on the CD. This function maintains a list of subdirectories, while incrementing a counter for every file it finds. When the counter is equal to the random number, the subdirectory path as well as the file name are placed in a empty buffer handed to the function. SdStressThread uses that file name with the secondary worker threads.

CopyTestFile (), CopyTestFileUsingIoC (), and CopyTestFileMultiple () - These three functions constitute the secondary worker threads. These threads do the actual copying and comparing based on block sizing. The comparing mechanism is actually done by creating yet another worker thread for exclusively handling the comparisions.

VerifyData () - This function is responsible for the comparisons between source and target images. This function compares both images against an image retained in memory, rather then comparing the images against each other. This makes for a better compare, as it can distinguish between source and target image discrepancies. For CD images, it does a simple comparison between the source and target.

SysCache

This test reads, writes, and verifies data with and without the Windows NT® buffer feature. Testing halts when the SysCache test detects data corruption.

At least one CD-ROM drive and one hard disk drive should be attached to the test controller.

For complete storage testing it is recommended that the Int 13H Extensions test should be run with a removable media drive attached to the test controller as the boot device.

Note: This test is designed to run while your hardware system is connected to the debugger (see NT Debugging Overview).

If there is a problem, the debugger provides you with detailed error information. We recommend that you use the debugger; without the debugger, the SysCache test runs to the end of its designated time and records a failure. If you are not using a debugger and wish the test to halt on an error, see the procedure in this section, "To run the SysCache test without the debugger."

Parameters
You can choose the drive and set how long the test takes.

Configuration
The test requires at least one hard drive.
To run the SysCache test
1. From Test Manager, in the Available Tests box, expand Device or System, expand Storage, and expand SysCache.
2. Select the drive you are testing, and add to the Selected Tests box.
3. In the Select Tests box, double-click the name of the drive you are testing.
4. In the Parameters dialog box, type the drive letter of the test drive, including a trailing colon (:), as shown here: Drive c:
5. In the Parameters dialog box, you can also change the time, in minutes, that the test takes to run. (System testing will require 60 minutes per partition, Microsoft will verify test results.)
6. Choose the OK button to return to the Test Manager window, and start the test.

To run the SysCache test without the debugger
1. Using a text editor, in your test directory go to: \HCT\Testbin\drvcache.bat
2. Open DRIVECACHE.BAT, remove the "-d" switch.
3. Save DRIVECACHE.BAT and restart the SysCache test.
When the test encounters an error, a warning pop-up appears.

Media Changer Test

The Media changer test tests medium changer drivers and hardware for compliance.

Tape I/O

This test verifies that the functions of a tape drive are working correctly. First it queries the drive to determine its supported functionality. Then the test checks each reported function to confirm that it is fully supported. If the test fails, examine the log file. All tape operations are logged in Win32 API format.

Parameters

You can specify which drive to test.

Configuration

The test requires one tape drive with a tape loaded. The appropriate tape driver must also be installed.

Algorithm

This section describes how to test various functions of the tape drive. To determine which of these functions is supported, the test calls the GetTapeParameters API function to get the TAPE_GET_DRIVE_PARAMETERS structure. It then checks the FeaturesLow and FeaturesHigh structure fields.

Block Mode Functionality: This section describes how to test various functions of the tape drive. To determine which of these functions is supported, the test calls the GetTapeParameters API function to get the TAPE_GET_DRIVE_PARAMETERS structure. It then checks the FeaturesLow and FeaturesHigh structure fields.

Positioning Functionality: First the test writes a set of data blocks to the tape. Each block has a unique pattern. Then, using each supported positioning method (as indicated in FeaturesHigh), the test moves the tape to different positions and checks the data pattern to determine whether the position is correct. The following positioning methods are tested:

• TAPE_DRIVE_LOGICAL_BLK
• TAPE_DRIVE_LOG_BLK_IMMED
• TAPE_DRIVE_ABSOLUTE_BLK
• TAPE_DRIVE_ABS_BLK_IMMED
• TAPE_DRIVE_RELATIVE_BLKS
• TAPE_DRIVE_REWIND_IMMEDIATE
• TAPE_DRIVE_END_OF_DATA
• TAPE_DRIVE_REVERSE_POSITION

Tape Mark Functionality: This test checks each type of supported tape mark (as indicated in FeaturesHigh). It writes several marks of each supported type on the tape, separated by data blocks containing unique patterns. If TAPE_DRIVE_WRITE_MARK_IMMED is set in FeaturesHigh, the test repeats with Immediate mode enabled. The following types of marks are tested:

• TAPE_DRIVE_WRITE_SHORT_FMKS
• TAPE_DRIVE_WRITE_LONG_FMKS
• TAPE_DRIVE_WRITE_FILEMARKS
• TAPE_DRIVE_WRITE_SETMARKS

• TAPE_DRIVE_SETMARKS
• TAPE_DRIVE_FILEMARKS
• TAPE_DRIVE_SEQUENTIAL_FMKS
• TAPE_DRIVE_SEQUENTIAL_SMKS

Erase Functionality: The test writes some data and then erases it. It uses the TAPE_DRIVE_ERASE_SHORT and TAPE_DRIVE_ERASE_LONG methods, if the drive supports them (as indicated in FeaturesLow). If TAPE_DRIVE_ERASE_IMMEDIATE is set in FeaturesLow, the test repeats with Immediate mode enabled. If TAPE_DRIVE_ERASE_BOP_ONLY is not set in FeaturesLow, the test erases in the middle of some data and then checks that the preceding data still exists.

Setting Features: The test attempts to enable and disable certain supported features (as indicated in FeaturesHigh). The only feature whose operation can be confirmed is TAPE_DRIVE_SET_REPORT_SMKS. For other features, the test only checks the ability to enable and disable them. The following features are checked:

• TAPE_DRIVE_SET_COMPRESSION
• TAPE_DRIVE_SET_ECC
• TAPE_DRIVE_SET_PADDING
• TAPE_DRIVE_SET_REPORT_SMKS

To Call Tape API Functions Manually

To assist you in debugging errors, you can call individual tape API functions manually.

• At the command prompt, change to the directory containing the tape tests. For example:
  

  cd \hct\tests\tape

• To run the program DTAPE.EXE, type:
  

  dtape

  When you type a question mark (?) at the dtape command prompt, the program displays a list of all available operations. The tape API function help display consists of three sections:

  1. Tape Operations: The name of each function is followed by a two-letter abbreviation and a list of parameters. To call one of these functions, type the function abbreviation at the command prompt, followed by appropriate arguments. For example, to call the CreateFile function to open the first tape drive, type:
     

     cf \\.\tape0

     You can obtain additional information about each API function parameter list by typing a question mark (?), followed by the function abbreviation. For example:
     

     ? STP

     
     displays information about the parameter list for SetTapeParameters.
  2. Buffer Manipulation Operations: The operations you can perform on a set of pre-defined buffers are edit, compare, dump, and set the values of the buffers.
  3. List of Buffers and Variables: This is a set of pre-defined buffers and variables. Use the commands in the Buffer Manipulation Operations section to view or modify the contents of these buffers and variables. The buffers are large enough to handle all tape operations. For example, to write "5" to every byte of the write buffer, type:
     

     s wb 5

     
     The next example shows how you can use the program to write a buffer to the beginning of the tape and then read back the written data.
     1. Before beginning any operations, open the tape drive. For example:
        

        cf \\.\tape0

     2. Fill the write buffer with bytes of the numeral 3:
        

        s wb 3

     3. Write 512 bytes to the tape, using the WriteFile API function:
        

        wf 512

     4. Rewind tape to beginning of write position (complete rewind):
        

        stop tape_rewind 0 0 0 0

     5. To read the buffer back from the tape using the ReadFile API function, type:
        

        rf 512

     6. To view the contents of the read buffer, type the dump command:
        

        d rb

        
        Type d several times to view the entire buffer.

Tape Backup/Restore

This test checks the NTBACKUP utility. It first creates a tree of data files starting at the drive and path that you specify. Then it backs up the tree of files to the tape, restores the files, and compares the checksums of the original and restored file trees.

You can also specify up to four additional drive partitions. For these drives, the test backs up the entire partition and then verifies with the original files, without restoring the files.

Parameters

This test has four parameters

• The partition and path in which the test creates data to be backed up. The default path is \TAPETREE.
• The tape drive port and bus ID.
• The number of MB to use for creating backup data. The default is 50 MB.
• The names of up to three optional, additional partitions to use for creating backup data.

Configuration

The test requires one tape drive and at least one hard disk drive. The disk drive must have enough free space to accommodate at least 50 MB or more of your backup data. Also if PAGEFILE.SYS is on your test drive, leave room for expansion. As a rule of thumb, plan on using enough storage space for the test plus 20% more.

To test the tape backup utility

1. Determine the amount of free space available on the hard disk that you want to receive the restored files.
2. From Test Manager, in the Available Tests box, expand Device, expand Storage, and expand Manual Drive Change.
3. Select Datadrive:\Path=c:\Tapetree and add to the Selected Tests box.
4. In the Select Tests box, double-click the tape drive you are testing.
5. In the Parameters dialog box, type the drive letter and path of the data drive (where the test creates the data to back up and to which the test restores the data) including a trailing colon (:), as shown here:

   Data Drive:\Path

   d:\tapetree

   Do not specify an existing directory path.

6. Type the number of megabytes to use on the data drive, as shown here:

   MB To Use on Data Drive

   50

7. Type drive letters, separated by spaces, for up to four backup drives (from which the test backs up the data), including a trailing colon (:), as shown here:

   Addit. Backup Drv1

   e: f: g:

8. Click 'OK' to return to the Test Manager window, and start the test.

Tape Partition Test

This test tests the partitioning methods that device/driver combination claims to support, including:

CD-ROM (File I/O)

This test verifies that various API-level file I/O calls work on a CD-ROM file system. This test also does file locking on a byte level on all files on the CD.

Parameters

Specify the CD-ROM drive you want to test.

Configuration

This test requires one CD-ROM drive. The HCT or the DDK CD-ROM must be inserted in the CD-ROM drive.

To test file I/O calls on a CD-ROM

1. Verify that you have a CD-ROM drive with an HCT or DDK CD-ROM disk inserted.
2. In Test Manager, from the Available Tests window, expand Device, expand Storage, and expand CD-ROM (File I/O).
3. Select the CD-ROM's name, and add to the Selected Tests box.
4. In the Selected Tests box, double-click the CD-ROM's name.
5. In the Parameters dialog box, type the drive letter of the CD-ROM drive you want to test, including a trailing colon (:), as shown here:
   

   Test Drive	f:

6. Choose the OK button to return to the Test Manager window, and start the test.

CD-ROM (File I/O)_Long

This test verifies that various API-level file I/O calls work on a CD-ROM file system. This test also does file locking on a byte level on all files on the CD.

Parameters

Specify the CD-ROM drive you want to test.

Configuration

This test requires one CD-ROM drive. The HCT or the DDK CD-ROM must be inserted in the CD-ROM drive.

To test file I/O calls on a CD-ROM

1. Verify that you have a CD-ROM drive with an HCT or DDK CD-ROM disk inserted.
2. In Test Manager, from the Available Tests window, expand Device, expand Storage, and expand CD-ROM (File I/O).
3. Select the CD-ROM's name, and add to the Selected Tests box.
4. In the Selected Tests box, double-click the CD-ROM's name.
5. In the Parameters dialog box, type the drive letter of the CD-ROM drive you want to test, including a trailing colon (:), as shown here:
   

   Test Drive	f:

6. Choose the OK button to return to the Test Manager window, and start the test.