Driver Test Manager Introduction

 Purpose

This documentation provides preview information about using Driver Test Manager (DTM) to test your device driver or system.

The DTM documentation contains preliminary information and is subject to change.

Getting Started

The following topics will get you started using DTM:

  • DTM Setup
  • Using DTM to Test for a ''Designed for Windows'' Logo
  • Using DTM to Create Your Own Jobs
See Also

Windows Hardware and Driver Central (WHDC)

© 2006 Microsoft Corporation
Send feedback on this topic
DTM Releases
Built on April 19, 2006
Build machine: CAPEBUILD


Legal Information

Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 1985 – 2005 Microsoft Corporation. All rights reserved.

Microsoft, Microsoft Press, MS-DOS, Windows, Windows NT, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.


Accessibility for People with Disabilities

Microsoft is committed to making its products and services easier for everyone to use. This section provides information about the following features, products, and services that make the Microsoft Windows operating system more accessible for people with disabilities:

  • Accessibility in Microsoft Windows
  • Adjusting Microsoft Products for People with Accessibility Needs
  • Microsoft Windows Documentation in Alternative Formats
  • Assistive Technology for Windows
  • Customer Service for People Who Are Deaf or Hard-of-Hearing
  • Getting More Accessibility Information

Note The information in this topic applies only to users who license Microsoft products in the United States. If you obtained this product outside the United States, your package contains a subsidiary information card listing Microsoft support services telephone numbers and addresses. You can contact your subsidiary to find out whether the type of products and services described in this topic are available in your area. See the [image] Microsoft Accessibility Web site for more information available in the following languages: English, French, Portuguese, Spanish, Chinese, Japanese, Swedish, and Italian.


Accessibility in Microsoft Windows

Many accessibility features have been built right into Microsoft Windows. These features are useful for individuals who have difficulty typing or using a mouse, are blind or have low vision, or who are deaf or hard-of-hearing. These accessibility features can be installed during setup. For more information about the various accessibility features in Microsoft products, go to the [image] Microsoft Accessibility Web site.


Adjusting Microsoft Products for People with Accessibility Needs

Accessibility options and features are built into many Microsoft products, including the Windows family of operating systems. Accessibility options and features are useful for individuals who have difficulty typing or using a mouse, are blind or have low vision, or who are deaf or hard-of-hearing.

Free Step-by-Step Tutorials

Microsoft offers a series of [image] Microsoft Accessibility Step by Step Tutorials to help you learn how to adjust the accessibility options and settings on your computer. The tutorials provide detailed procedures on how to adjust options, features, and settings to meet the needs of people with disabilities and accessibility needs. This information is presented in a side-by-side format so that you can see how to use the mouse, the keyboard, or a combination of both.


Microsoft Windows Documentation in Alternative Formats

Obtaining documentation from the Microsoft Web site

An indexed list of Microsoft products with accessible documentation is available on the Microsoft Accessibility Web site.

Obtaining documentation from Recording for the Blind & Dyslexic, Inc.

In addition, you can obtain additional Microsoft publications from Recording for the Blind & Dyslexic, Inc. These documents are distributed to registered, eligible members of their distribution service on audiocassettes or on floppy disks. The collection contains more than 80,000 titles, including Microsoft product documentation and books from Microsoft Press.

For information about eligibility and availability of Microsoft product documentation and books from Microsoft Press, contact:

Recording for the Blind & Dyslexic, Inc.

20 Roszel Road
Princeton, NJ 08540
Phone from within the United States: (800) 221-4792
Phone from outside the United States and Canada: (609) 452-0606
Fax: (609) 987-8116
Web: http://www.rfbd.org/


Customer Service for People who Are Deaf or Hard-of-Hearing

If you are deaf or hard-of-hearing, complete access to many Microsoft products and customer services is available through a text telephone (TTY/TDD) service.

Customer service

You can contact the Microsoft Sales Information Center on a text telephone by dialing (800) 892-5234 between 6:30 a.m. and 5:30 p.m. Pacific time, Monday through Friday, excluding holidays.

Technical assistance

For technical assistance in the United States, you can contact Microsoft Product Support Services on a text telephone at (800) 892-5234 between 6:00 A.M. and 6:00 P.M. Pacific time, Monday through Friday, excluding holidays. In Canada, dial (905) 568-9641 between 8:00 A.M. and 8:00 P.M. eastern time, Monday through Friday, excluding holidays. Microsoft support services are subject to the prices, terms, and conditions in place at the time the service is used.


Getting More Accessibility Information

The [image] Microsoft Accessibility Web site provides information about accessible technologies to help improve the lives of people with disabilities by making computers a positive force in employment, education, and recreation. The information on this site benefits people with disabilities and their friends and family members, people in outreach organizations, educators, and advocates.

A free monthly newsletter is offered via e-mail to help you keep up to date with accessibility topics about Microsoft products. For more information, visit the Microsoft Accessibility Web site.


Keyboard Shortcuts

This topic provides instructions for accessing DTM Studio commands by using keyboard shortcuts. The following table lists DTM Studio menu items and the keyboard shortcuts that perform the same action as the menu item.

Menu Item | Keyboard Shortcut Using Ctrl | Keyboard Shortcut Using Alt
File Menu |  | Alt + F
Open | Ctrl + O | Alt + F + O
Save | Ctrl + S | Alt + F + S
Save As |  | Alt + F + A
Print | Ctrl + P | Alt + F + P
Print Preview |  | Alt + F + V
Recent Files |  | Alt + F + R
Exit |  | Alt + F + X
New Job |  | Alt + F + N + J
New Package |  | Alt + F + P
Export Jobs |  | Alt + F + E
Import Jobs |  | Alt + F + I
Save Job | Ctrl + S | Alt + F + E
Create Schedule | Ctrl + Shift + S | Alt + F + U
Save Result | Ctrl + S | Alt + F + E
Edit Menu |  | Alt + E
Undo | Ctrl + Z | Alt + E + U
Cut | Ctrl + X | Alt + E + T
Copy | Ctrl + C | Alt + E + C
Paste | Ctrl+ V | Alt + E + P
Delete | Del | Alt + E + D
View Menu |  | Alt + V
Query | Ctrl + Q | Alt + V + Q
Hierarchy | Ctrl + H | Alt + V + H
Refresh | F5 | Alt + V + R
Task Results | Ctrl + T | Alt + V + T
Toolbars |  | Alt + V +_T
Status |  | Alt + V + S
Explorers Menu |  | Alt + X
Job Explorer |  | Alt + X + J
Result Explorer |  | Alt + X + R
Job Monitor |  | Alt + X + M
Result Collection |  | Alt + X + C
Error Log View |  | Alt + X + E
Result Rollup |  | Alt + X + O
Device Explorer |  | Alt + X + D
Tools |  | Alt + T
Management Console |  | Alt + T + C
Plugin Manager |  | Alt + T + P
Device Categories |  | Alt + T + D
Window |  | Alt + W
Cascade |  | Alt + W + S
Tile |  | Alt + W + T
Opened Window |  | Alt + W + [window number]
Close |  | Alt + W + C
Close All |  | Alt + W + A
Help | F1 | Alt + H
Contents |  | Alt + H + C
Show Start Page |  | Alt + H + H
About DTM Studio |  | Alt + H + A


Getting Started

This section contains the following topics:

Overview of DTM

Setting Up DTM

Creating Your Own DTM Jobs

Troubleshooting DTM Problems


Overview of DTM

[This is preliminary documentation and subject to change.]

Driver Test Manager (DTM) is a collection of software components that provide a harness to run tests to obtain a “Designed for Windows” logo for your driver. DTM reduces the work-load on testers by automatically distributing tests to available computers.

DTM enables you to test your drivers on more computers and with greater ease than manually reconfiguring computers on which to run the logo tests. With DTM, whenever a computer becomes idle, it can be automatically scheduled to run further tests. Meanwhile, testers can monitor the progress of a test while the test is running. DTM increases testing coverage for your driver, reduces tester overhead, and speeds the process to obtain a Windows logo.

In addition, DTM provides a powerful feature that enables a tester to create custom tests to further exercise a driver to determine how it performs and the cause of driver failures.

Driver Test Manager Components

DTM is divided into the following components:

  1. DTM clients are computers that run tests. You should have as many client computers with as many different configurations as possible so that your driver can be tested under the widest variety of real-world conditions. Clients should have different hardware and software configurations and different operating systems and service packs installed.

  2. DTM controllers are computers that control what tests run on DTM clients and when those tests run. Controllers host a SQL database that stores tests to be run and the results of previous tests for review and future use.

  3. DTM Studio is the application and user interface testers use to create and schedule tests and otherwise manipulate controllers and clients. DTM Studio enables you to organize the computers in your lab into the appropriate environment to test your driver.

General DTM Concepts

DTM operates on jobs. Jobs are comprised of groupings of individual tasks, such as open a file, save a file, then close the file.

You use DTM Studio to schedule jobs for a controller to execute on an available client. The controller will schedule a client to execute a job only if the client meets the job’s requirements, such as a specific display adapter or minimum amount of system memory.

Controllers continually schedule jobs to execute on client computers. When a client executes a job (whether the job passes or fails), the results of the job are stored back to a controller. The controller can then schedule the client to run another test. You can then examine the job results in DTM Studio to determine the source of any failures.

Testers can leverage a greater number of clients and increase a driver’s testing coverage with DTM because multiple testers can use DTM Studio (from their respective computers) to create and schedule jobs. Controllers then handle distributing jobs from multiple testers automatically to clients as clients become available.

Scenarios

You can use DTM in a small lab environment, comprised of a minimum of two computers, or you can use DTM in large labs with dozens of computers.

When you set up and configure DTM, you will need to allocate at least one computer on which to install the DTM controller. You can allocate up to 100 clients per controller. However, for performance reasons, Microsoft recommends that you allocate no more than 30 clients per controller.

For example, in a small lab, each tester could be allocated 5 to 10 computers on which to test a driver. One of those computers becomes a controller, one of them the tester installs DTM studio on, and the others become clients. In larger labs, you can allocate dozens of clients to a controller. Each tester should install DTM Studio on his primary work computer. Then, testers can work together to create and schedule jobs for the drivers that they are responsible for testing by using all the clients available in the lab, and letting the controllers schedule what tests to run on which clients. Then, testers can share the task of reviewing job results from their primary work computers.

The DTM Controller and Client Organization topic includes more information about DTM setup scenarios.


Setting Up DTM

Driver Test Manager (DTM) requires a minimum of two computers. At least one computer will become a DTM controller, and the other computer(s) will become DTM clients. It is recommended that you allocate an additional computer on which to install DTM Studio. Avoid installing DTM Studio on a DTM client computer. If necessary, you can install DTM Studio on a DTM controller computer.

Review the following considerations before you deploy DTM in your lab and configure your DTM Studio, controller(s),and client(s) computers:

Lab security

Computer requirements

DTM controller and client organization

After you have deployed DTM in your lab, you must configure your controller(s) and clients. You use DTM Studio to access the DTM controllers to schedule jobs to execute on the DTM clients.


DTM Lab Security

Before you deploy DTM, you should consider security requirements. There are two areas of logo testing that significantly affect security:

  • Enabling auto-logon functionality

  • Running tests in an administrator role

In addition, be aware of the following security precautions and considerations:

  • Isolate DTM computers on the network

    To prepare to deploy DTM in your lab, you should isolate the computers that you intend to install it on. For example, do not allow those computers access to the Internet or your primary network. If any of your test systems can connect to a corporate network or the Internet, those connections should be disabled during testing. Alternately, put lab computers on their own private subnet. For more information about configuring a private subnet, see [image] Configuring APIPA.

  • Use dedicated computers and reformat them before use

    Systems that are used for testing should not store sensitive data or be used (or have been used in the past) for company-provided services (such as a Web server, Dynamic Host Command Protocol [DHCP] server, or a backup domain controller [BDC]). If new systems are not available, then reformat and wipe clean all dedicated DTM computers before installing DTM and running the logo test to ensure that no sensitive information is inadvertently captured in the DTM logs. For example, in the event of a kernel crash, the job log could record a full memory dump that might contain potentially sensitive information. For more information about cleaning your lab computers, see [image] Fdisk and Format a Hard Disk. After you have cleaned the computer you must install the operating system you want the computer to run.

  • Use hardware and/or software firewalls

    When you install the DTM controller and DTM client, the installers will open TCP port 1778. Ensure that no other software running on a controller or client uses port 1778. The controller and client installers will prompt you to open this port in the Window’s software firewall. However, if your lab includes non-Microsoft software firewalls or hardware firewalls, you must manually make sure that port 1778 is open. Otherwise, DTM controllers will be unable to communicate with their clients and schedule them to run tests. If you use a hardware firewall, refer to the documentation that came with it to open TCP port 1778.

  • Set user permissions

    When you install the DTM controller, its installer will create a network share and set the permissions for the share to allow access for DTM clients. One folder inside the network share is for the DTM client installer, and another folder is for the DTM Studio installer. Another network share is created for clients to communicate job results back to the controller. You can increase security by allowing only testers and DTM clients to connect to these shares across the network, which is another reason why you should isolate the computers of your lab on a private subnet.

  • Physically secure your lab

    You should enable auto-logon on DTM clients. Therefore, wherever possible, test systems should be located in a locked room and should be physically available to testing and support personnel only. Enabling auto-logon is described in greater detail when you install the DTM client.

For more information about security and Microsoft products, see the following references:

  • Microsoft Security

  • Microsoft TechNet

  • Microsoft TechNet: Automating Logon in Windows XP


DTM Computer Requirements

DTM Studio, controllers, and clients can be installed on a variety of different hardware and software configurations. Typically, though, DTM controllers have more robust requirements than do their clients.

DTM controller computer requirements

A DTM controller must be able to keep up with job scheduling, tracking test progress, and gathering and storing job results for the many clients that it may control.

Before you set up a controller, make sure the designated system meets the following requirements:

  • Hardware Requirements:

    The DTM controller setup is currently supported only on x86-based architectures.

    For best performance, a controller should be a multiprocessor and/or multicore host, with at least 2 gigabytes (GB) or more of memory, a 200 gigabyte (GB) hard disk drive (or SCSI RAID-array when testing with more than 30 clients), and a 100 megabits per second (Mbps) network connection.

  • Software Requirements:

    The following software must be installed on the controller before you install the DTM controller:

    • The x86-based version of Microsoft Windows Server 2003 Service Pack 1 (SP1), or Windows XP Service Pack 2 (SP2).

    • Microsoft SQL Server 2000 Desktop Engine (MSDE 2000) Service Pack 3a (SP3a).

    • Microsoft .NET Framework 1.1 (if you install Windows XP SP2).

  • User Account Requirements:

    To install the DTM controller, you must be logged onto the controller as a user who is a member of the Administrators group. You may need to separately [image] create a special user account and [image] add that user to the Administrators group before you proceed with installation.

DTM Studio computer requirements

DTM Studio has fewer system requirements than the DTM controller. You can even install DTM Studio on your main development machine. The main thing to keep in mind when installing DTM Studio is that it must be on the same network (private subnet) on which the controllers and clients are on. Otherwise, you will not be able to connect to a controller to have it schedule jobs to execute on clients.

Before you install DTM Studio, make sure your system meets the following requirements:

  • Hardware Requirements:

    The DTM Studio setup currently support x86-based and and x64-based architectures.

  • Software Requirements:

    The following software must be installed before you install DTM Studio:

    • The x86-based version of Windows Server 2003, or Windows XP SP2.

  • User Account Requirements:

    To install DTM Studio, you must be logged onto the computer as a user who is a member of the Administrators group. You may need to separately create a special user account and add that user to the Administrators group before you proceed with installation.

    Note: The DTM Studio user account must also be a member of the Administrators group on controllers to access data stores on them.

DTM Client computer requirements

DTM client computers should represent the vast diversity of end-user computers in both hardware and software configurations.

Before you set up a client, make sure that the client meets the following requirements:

  • Hardware Requirements:

    The DTM client setup is supported on x86-based, Itanium-based, and x64-based architectures. Clients must have at least 128 MB of RAM. For checked builds, 256 MB or more of RAM is recommended.

  • Software Requirements:

    The DTM client runs on the following operating systems:

    • Windows Vista
    • Windows Server 2003
    • Windows XP SP2
    • Windows 2000

  • User Account Requirements

    To install the DTM client, you must be logged onto the client as a user who is a member of the Administrators group. You may need to separately create a special user account and add that user to the Administrators group before you proceed with installation.

Operating Systems Requirements

When configuring DTM clients with software, including operating systems and service packs, observe the system requirements. The following list provides links to the system requirements for supported operating systems:

  • Windows Server 2003

  • Windows XP Professional

  • Windows XP Home Edition

  • Windows 2000 Server

  • Windows 2000 Advanced Server

  • Windows 2000 Datacenter Server

  • Windows 2000 Professional


DTM Controller and Client Organization

Before you install the DTM software in your lab, you should decide how you want to organize your lab’s resources to utilize DTM.. Determine the number of controllers, the number of clients connecting to those controllers, and on which computer(s) to install DTM Studio. These decisions are partly influenced by the type of devices and/or systems that you want to logo.

For example, to test specific devices, such as a USB-based flash-card reader, you might decide to allocate fewer controllers, each with more clients, because multiple testers can access the controllers, schedule jobs, and review job results, simultaneously.

Note: This release of DTM does not support enterprise scenarios, wherein controllers communicate directly with each other to share clients and distribute scheduled jobs. That is, DTM does not support load-balancing.

Typically, there are two ways to organize your controller and client lab resources:

  1. Allocate fewer controllers, each with many clients connected to them.

    2. Advantages: You will have less overhead administering the controllers and clients. Also, the chances are higher of a client with the necessary hardware and software configuration being available, or becoming available shortly, to execute a scheduled job.

    Disadvantages: Adds more latency to the DTM controller. DTM Studio menu items will be slower to respond and jobs slower to launch.

  2. Allocate more controllers, each with fewer clients connected to them.

    3. Advantages: Any given controller will be more responsive because it has fewer clients communicating with it. You can reduce overall latency.

    Disadvantages: You will have more overhead administering, especially if you intend to schedule similar jobs from multiple controllers because you must manually set up the jobs on each controller. Controllers will not automatically pass jobs between each other.

If you configure your controllers to run on high performance/high resource hardware it will be able to handle more clients.

Note: Multiple controllers are independent of each other.

DTM puts a limit of 100 clients that can connect to a single controller. If you have a large lab that has more than 100 computers intended to be clients, then you will need to allocate multiple controllers. Regardless of the size of your lab, you can allocate multiple controllers, each with any number of clients (up to 100 per controller) connected to a given controller. If you have multiple controllers and you want them to schedule similar or identical jobs, then you must manually set up the jobs on each controller. Controllers will not communicate with each other (or each other’s clients) to balance scheduled jobs or to store job results.

When allocating controllers and clients, you should also allocate additional computers on which to install DTM Studio. You can also have multiple DTM Studio installations. For example, each tester could install DTM Studio on a work computer to access the controller, as long as that computer is part of the same network. Otherwise, DTM Studio will not be able to access controllers.

Note: Installing DTM Studio does not count toward the limit of 100 clients per controller.

The following table describes example scenarios for labs of different sizes:

Number of computers | Minimum number of DTM controllers to allocate | Number of DTM clients to allocate | Configuration
2 to 10 | 1 | 1 to 9 | Allocate a single controller that will have 1 to 9 clients connected to it. The remaining computers all become clients of the controller.
11 to 101 | 1 or more | 1 to 100 | Allocate at least one controller, and possibly more. For example, you could allocate 1 controller that could have up to 100 clients. Or, you could allocate 2 controllers and distribute the remaining computers as their clients in an arbitrary manner. The decision of which ratio to allocate clients to controllers is completely at your discretion.
102 or more | 2 or more | 100 or more | You must allocate at least 2 or more controllers for labs that contain more than 100 clients because this release of DTM supports only 100 clients per controller.

Note: To use DTM to obtain a logo, all tests must be performed from a single controller. You cannot combine results from multiple controllers to obtain a logo.


DTM Installation

Driver Test Manager (DTM) must be installed on at least two computers. Install the DTM controller on one computer and then install the DTM client on the computer (or computers) that you will use to run tests. You must install DTM Studio on a computer that you did not install the DTM client on.

Note The DTM client can be installed only on a computer that does not have another DTM application installed on it.

For detailed instructions about installing DTM, see the Microsoft Windows Driver Kit (WDK) installation instructions. If you are installing DTM from a CD, you can find the WDK installation instructions in the install.htm file in the root directory on the CD.

If you later plan to uninstall a client, you must first set its status to unsafe on the controller.

Click to show or hide information. To set the client computer’s status to unsafe (before you uninstall the client)

  1. Switch to the Job Monitor window, or click Explorers and then click Job Monitor.
  2. Select your DTM controller from the list at the top left of the Job Monitor window.
  3. In the left pane of the Job Monitor window, select the machine pool that contains the client computer.
  4. Right-click on the computer in the Machines pane, point to Change Status, and then click Unsafe.


DTM Controller and Client Configuration

After you have installed the DTM software components, you are ready to begin using DTM. Before you can execute jobs, you must organize your controllers’ client computers into groupings called machine pools. When you install DTM client, that client computer is placed in the default pool of the controller from which you ran the DTM client installer. In addition the client is set to manual status. The first time you run DTM Studio, you will need to create a user-named machine pool, and then move the client computer(s) from the default machine pool into your user-named pool. You also will need to reset client computers statuses before the controller can schedule them to execute jobs. You can create additional pools, depending on how you want to organize and distribute the clients among the controllers.

  1. Create machine pools.
  2. Reset the client computers’ status.
  3. Create user accounts.
  4. Prepare the client computers to run the “Designed for Microsoft Windows” logo test jobs. (This step is required only if you want to run the logo test jobs for the Windows Vista Beta 2 release.)


Starting DTM Studio

When you install DTM Studio, an entry is added to the Start menu. To start DTM Studio, complete the following steps:

  1. Click Start.
  2. Click All Programs, point to Windows Driver Kits, point to Microsoft Driver Test Manager, and then click Studio.

    The DTM Studio window opens.


Grouping Client Computers into Machine Pools

A machine pool represents a group of client computers. Typically, when you use DTM Studio, you must specify a machine pool before performing any other actions. Specifying a machine pool restricts the computers that you can work with to the computers that are members of the machine pool.

When you install the DTM client on a computer, the computer is automatically added to the default pool. Before you can work with this computer, you must move it from the default pool into a machine pool that you’ve already created and indicate that the newly added computer is available to run jobs. Before other users can work with this computer, you must give the users permission to run jobs on the machine pool that you created.

Click to show or hide information. To create a machine pool

  1. Switch to the Job Monitor window.
    You can also open a new Job Monitor window by clicking Explorers, and then clicking Job Monitor.
  2. Select your DTM controller from the drop-down box at the upper left of the Job Monitor window.
  3. In the Machine Pool pane, right-click the dollar sign ($) at the root of the machine pool hierarchy, and then click Add Machine Pool.
  4. Enter the following information in the Add Machine Pool dialog box:
    1. In the Name box, type a name for the machine pool.
    2. In the Job Delivery Agent box, select your DTM controller.
    3. Select the When scheduling, allow the scheduler to search for config jobs to automatically execute on the machines to help them match the constraints of the job. check box.
    4. Click OK.

      Your new machine pool’s name will appear in the Machine Pool pane.

Note: You can create a child machine pool by adding the new machine pool to an existing machine pool, instead of adding it to the root of the machine pool hierarchy.

Click to show or hide information. To move a computer from one machine pool to another machine pool

  1. Switch to the Job Monitor window.
    You can also open a new Job Monitor window by clicking Explorers, and then clicking Job Monitor.
  2. Select your DTM controller from the drop-down box at the upper left of the Job Monitor window.
  3. In the Machine Pool pane, click the machine pool name that contains the computer that you want to move.
    The computers that belong to the machine pool that you select are listed in the Machines pane.
  4. Drag the computer from the Machines pane to the machine pool that you want the computer to belong to.

Important: Do not move the controller out of the System pool.


Enabling a Client Computer to Run Tests

You can change the status of a client computer to indicate whether it is ready to run tests. Client computers whose status is Ready are available to run tests. Client computers whose status is Manual, Debug, or Unsafe are not available to run tests. Resetting a client computer’s status places the client computer in the Ready state.

The icon next to a client computer’s name in the Job Monitor window indicates the client computer’s status. See Monitoring Client Computer Status for more information about Job Monitor, including a description of the icons and their meanings.

Click to show or hide information. To indicate that a client computer is available to run tests

  1. Switch to the Job Monitor window.
    You can also open a new Job Monitor window by clicking Explorers, and then clicking Job Monitor.
  2. Select your DTM controller from the drop-down box in the upper left of the Job Monitor window.
  3. In the Machine Pool pane, select the machine pool that contains the client computer.
  4. In the Machines pane, right-click the computer, point to Change Status, and then click Reset.

Click to show or hide information. To indicate that a client computer is unavailable to run tests

  1. Switch to the Job Monitor window.
    You can also open a new Job Monitor window by clicking Explorers, and then clicking Job Monitor.
  2. Select your DTM controller from the drop-down box in the upper left of the Job Monitor window.
  3. In the Machine Pool pane, select the machine pool that contains the client computer.
  4. In the Machines pane, right-click the computer, point to Change Status, and then click one of the following status values to indicate that the machine is in a specific state: Manual, Debug, or Unsafe.


Managing DTM User Accounts

A DTM user account is automatically created for the person who installed the DTM controller, and that account is granted administrator privileges within DTM. A person who has a DTM user account with administrator privileges is called a DTM administrator.

DTM administrators can create new DTM user accounts or modify the permissions of existing DTM user accounts.

Everyone who uses DTM Studio must be a member of the Administrators group on the computer that is running the DTM controller.

Click to show or hide information. To create a DTM user account

  1. Switch to the Management Console window.
    You can also open a new Management Console window by clicking Tools, and then clicking Management Console.
  2. In the left pane of the Management Console window, expand Console Root. Then expand your Datastore and right-click on Users. Select New User.
    The Datastore User Properties – New User dialog box opens.
  3. In the Datastore User Properties – New User dialog box, in the top pane, type the user name of the person you are creating a DTM user account for using the format domain\username, where domain is the user’s domain or workgroup name, and username is the user’s user name. If you are creating multiple user accounts, separate each user with a semicolon.
  4. In the Datastore Role box, select the dtm_DSUsers check box.

    Note: To create an account for a DTM administrator, also select the dtm_DSAdmins check box.

  5. Click OK.

Click to show or hide information. To give DTM users permission to run jobs on a machine pool

  1. Switch to the Job Monitor window.
    You can also open a new Job Monitor window by clicking Explorers, and then clicking Job Monitor.
  2. Select your DTM controller from the drop-down box at the upper left of the Job Monitor window.
  3. In the Machine Pool pane of the Job Monitor window, expand the machine pool hierarchy, right-click the machine pool that you want the user to be able to run a job on, and then click Properties.
    The Properties dialog box for your machine pool will appear.
  4. On the Security tab, click Add.
    The User List dialog box appears.
  5. Select the user name, and then click OK.

    6. Note: If the user name does not appear in the user list, then the user does not have a DTM user account. Create the user account, and then give the user permission to run jobs.

  6. In the bottom pane of the Properties dialog box for your machine pool, under Allow, select the Execute Jobs check box and clear any check boxes for permissions that you don’t want the user to have, and then click OK.


Preparing Client Computers to Run the Logo Tests

To execute the jobs that come with the Windows Driver Kit (WDK), DTM requires special dimensions and a Local Logical User (LLU) account on each client computer.

Dimensions are key/value pairs that identify a characteristic of a client computer. For example, a dimension whose key is ProcessorCount might have the value of 1 on one client computer and have the value of 4 on another client computer. The LLU dimension maps a variable within the job to a set of user credentials.

The DTM Client Setup performs the steps of creating the required dimensions automatically. You do not need to manually create the LLU or any other dimensions initially required by DTM.

Note: In addition to creating the required dimensions, the DTM Client Setup exposes the Administrator account (on the client) to enabling Fast-User Switching (FUS). This feature modifies the following registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList\Administrator = (DWORD) 1.


Creating Your Own DTM Jobs

In addition to executing the “Designed for Microsoft Windows” logo tests, you can use Driver Test Manager (DTM) to run your own tests. You do this by creating and executing jobs.

A job contains tasks, which usually run a test and perform related activities. A job can be constrained so that it can only execute on client computers that have certain characteristics. You can define parameters for the job, either when you create the job or when you execute it, to enable the same job to perform different, but related, tasks.

Jobs can be executed, saved, and shared. When a job is executed, DTM identifies a client computer that matches the job’s constraints, then executes the job’s tasks on the client computer.

This section includes the following topics:

  • How Jobs Are Organized
  • Custom Jobs
  • Executing a Job


How Jobs Are Organized

Jobs are stored either within the DTM controller or in a package. You can display jobs by using the Job Explorer and selecting either the DTM controller or a specific package.

Within Job Explorer, jobs are organized in a hierarchy of features. When you create a job, you assign a feature to the job. The following figure illustrates one possible hierarchy of features for organizing jobs.

A job feature hierarchy

If you create a new feature node within the feature hierarchy, you have permission to create jobs within the feature node. If you created the node, you can also grant other DTM users permission to create jobs within the feature node. However, all DTM users can run the jobs within the feature node.

Click to show or hide information. To show or hide the feature hierarchy

  1. Switch to the Job Explorer window.
    You can also open a new Job Explorer window by clicking Explorers, and then clicking Job Explorer.
  2. Click Show/Hide Hierarchy ( [image]).

Click to show or hide information. To create a new feature node

  1. Switch to the Job Explorer window.
    You can also open a new Job Explorer window by clicking Explorers, and then clicking Job Explorer.
  2. Select your DTM controller from the drop-down box in the upper left of the Job Explorer window.
  3. Expand the nodes in the Feature pane until you locate the node you want to add the new feature to.
  4. Right-click the node you want to add the new feature to, and then select Add Node.
  5. Type a name for the new feature node.

Click to show or hide information. To give users permission to add jobs to a feature node

  1. Switch to the Job Explorer window.
    You can also open a new Job Explorer window by clicking Explorers, and then clicking Job Explorer.
  2. Select your DTM controller from the drop-down box in the upper left of the Job Explorer window.
  3. Expand the nodes in the Feature pane until you have located the node you want to give users permission to.
  4. Right-click the node you want to give users permission to, and then select Properties.
  5. On the Security tab of the Properties dialog box, click Add.
  6. In the User List dialog box, select the user name or group that you want to give permission to, and then click OK.

    Note If the user you want to give permission to is not listed, you must first create a DTM user account for the user.

  7. In the bottom pane of the Properties dialog box, select the permissions that you want to grant to the user.
    • Manage Feature Node: Permission to change the feature node. This includes permission to grant more permissions.
    • Create Child Feature Node: Permission to create feature nodes within this feature node.
    • Manage Jobs: Permission to create jobs in this feature node.
  8. Click OK.

Click to show or hide information. To locate a job

There are two ways to search for an existing job: create a simple query, or create an advanced query. Whichever way you use, you must already know whether the job is on the controller or, if the job is in a package, you must know which package it is in.

The following procedure provides the steps to search for a job by using an advanced query. Any search that you can perform with a simple query can also be performed with an advanced query.

  1. Switch to the Job Explorer window.
    You can also open a new Job Explorer window by clicking Explorers, and then clicking Job Explorer.
  2. Select your DTM controller from the drop-down box in the upper left of the Job Explorer window. If the job you are searching for is in a package, select the name of the package instead of your DTM controller.
  3. If the query pane is not visible, click Show Query Builder ( [image]).
  4. Select the Advanced Query tab.
    A form similar to the following is displayed.

    A query that finds jobs that contain the string “GDI” in their name and were created by user1

  5. Select a new row in the job query form and enter the following information:
    1. In the And/Or column, select And to search for jobs that match the constraints on the previous rows of the query and the row that you are typing. Select Or to search for jobs that match the constraints of the previous rows of the query or the row that you are typing.
    2. In the Field Name column, select the name of a field within the job by using the drop-down list.
    3. In the Operator column, select an operator to use to compare the field’s value.
    4. In the Value column, enter the value that you want to compare the field of each job to.

    Note The first row of the query is filled in automatically and specifies either the name of the controller or the name of the package that you are searching.

  6. Click Refresh ( [image]).
    The jobs that match the query are displayed in the Jobs pane.


Custom Jobs

Jobs are very flexible, but also very complex. The first topics in this section introduce basic concepts and procedures related to jobs. Later topics present advanced concepts and procedures for performing specialized tasks. This section includes the following topics that describe using DTM to create a custom job:

  • Basic Job Concepts
  • Basic Task Concepts
  • Defining a Job
  • Defining Tasks
  • Executing Tasks in a Custom Order
  • Specifying Which Computers Jobs Run On
  • Using Variables within a Job


Basic Job Concepts

A job is a set of tasks that can be executed on a client computer. Typically, you create a job to run a test, although, you can also create jobs to perform other actions. For more information about tasks, see Basic Task Concepts.

Jobs are stored within the DTM controller, and there is no practical limit to the number of jobs that a DTM controller can store. You can create a package that contains jobs and share that package with other testers who use DTM.

There are many fields associated with a job that you can use to group similar jobs and to search for specific jobs. The primary field that is used to group jobs is the Feature. For more information about organizing and searching for jobs, see How Jobs Are Organized.

Because a job is defined independently of the client computers that it will be executed on, jobs can be reused. Each job can have constraints that limit the types of client computers that the job can execute on. You can execute multiple instances of a job simultaneously. You can also create a job that requires more than one client computer to run, such as a job that needs one computer to act as a server and a second computer to act as a client.

A job can have one of four roles:

  1. Automated: Runs without user intervention.
  2. Manual: Represents the need for a user to perform manual actions.
  3. Library: Is similar to an automated job, but can be reused within other jobs.
  4. Configuration: Sets the value of a dimension.

You can use configuration jobs to make your set of jobs more modular. When you execute a job that requires a dimension, DTM can automatically execute a configuration job that sets that dimension. By using configuration jobs, you can create many jobs that require a certain configuration of the client computer without including the tasks to create that configuration in every job. The configuration task would be isolated in the configuration job.

Although all jobs share certain common features, the job role determines much of the important information that you must provide when you define the job.

DTM provides information about the job and about the computer that the job is executing on as variables. You can access the values of these variables from the tasks in a job. You can also define your own parameters and access the parameters’ values from the tasks in a job.

For more information about creating a job, see Defining a Job.


Basic Task Concepts

Tasks perform the work of the job. For example, a simple job could contain three tasks: one task to copy a test program to the client computer, a second task to run the test program, and a third task to copy a log file from the client computer to a server that holds all log files.

Tasks run in three phases: setup, regular, and cleanup. All setup tasks must complete before any regular tasks can run. Cleanup tasks run either when all of the regular tasks have completed, or when a regular task that is marked “FailAndStop” fails. You can take advantage of the way that phases affect the order that tasks run. For example, you can put tasks that configure client computers in the setup phase, and tasks that return the client computers to their previous state in the cleanup phase. Tasks that copy test binaries, modify system settings, or install additional software often go in the setup phase. Tasks that undo these actions often go in the cleanup phase. Tasks that execute the tests themselves generally belong in the regular phase. To build on the previous example, the first task (copy the test program to the client computer) would go in the setup phase; the second task (run the test program) would go in the regular phase; and the third task (copy the log file to a server) could go in either the regular or cleanup phase. By considering the phases, we can see that there could be a missing fourth task: there should be a fourth task to remove the test program and leave the client computer in the state it was in before the job executed.

Within each phase, you can further specify the order that tasks run in. Sequential and parallel execution between the tasks are built in to DTM.

A task’s type determines its behavior:

  • An Execute task executes a command line.
  • A Copy File task copies files from a remote location to the client computer.
  • A Copy Result task copies files from the client computer to a remote location.
  • A Run Job task runs another job (a library job ).
  • A Manual Prompt task displays a prompt and options to the user and waits for the user to make a selection.

    Tip Manual Prompt tasks can be useful in debugging a job. You can create a Manual Prompt task that displays the value of a variable in the job, or provides another indication of the job’s status.

Continuing the previous example, the first task (copy the test program to the client computer) would be a Copy File task; the second task (run the test program) would be an Execute task; the third task (copy the log file to a server) would be a Copy Result task; and the fourth task (delete the test program) would be an Execute task.

Two additional aspects of a task influence how the task affects the job it belongs to. First, you can specify whether the job should continue executing if the task itself fails. Second, you can indicate whether the pass or fail result of the task should contribute to the pass or fail result of the job. To continue the example, if the first task (copy the test program) fails, the job should stop; there is no point running the test program if it has not been copied to the client computer. If the other tasks fail, the job should probably continue to execute. If the result of the test program is the only important output of the job, then the pass or fail result of the second task (run the test program) should roll up to the job, and the pass or fail results of the other tasks should not roll up to the job.

The following table combines the details from all of the previous examples.

Task | Phase | Type | Failure Action | Rollup Results
Copy test program to client | Setup | Copy file | Fail and stop | No
Run test program | Regular | Execute | Ignore fail and continue | Yes
Copy log to server | Regular or cleanup | Copy result | Ignore fail and continue | No
Delete test program | Cleanup | Execute | Ignore fail and continue | No


Defining a Job

Jobs can be complex, and the procedure for creating a job differs depending on the role of the job. This topic contains a procedure for creating the basic structure of a job. Within the procedure, links are provided to topics that explain how to create the parts of a job that differ depending on the job role.

Click to show or hide information. To create a job

  1. Switch to the Job Explorer window.
    You can also open a new Job Explorer window by clicking Explorers, and then clicking Job Explorer.
  2. Select your DTM controller from the drop-down box in the upper left of the Job Explorer window.
  3. Expand the nodes in the Feature pane until you locate the node you want to add the new job to.

    Note If you want to create the job in a new feature node, first create the new feature node, and then create the job. See How Jobs Are Organized for instructions to create a new feature node.

  4. Right-click the node you want to add the new job to, and then select New Job.
    The New Job window is displayed.
  5. Enter a name for the job in the Job Name box.
  6. In the Role box, select one of the following roles for the job that you are creating:
    • Automated if this job, or parts of this job, can be done by executing a command at the command prompt on the client computer.

    • Configuration if this job sets a value for a dimension.
    • Library if other jobs can use this job.
    • Manual if this job must be performed by a person.

    Note An automated job can contain manual tasks. Select Automated if parts of the job can be accomplished without user intervention. Select Manual only if the entire job must be done by a person. Manual jobs are rare.

  7. In the Is Active box, select True if you want users to be able to execute the job. If you select False, the job will be saved, but users will not be able to execute it.
  8. To define parameters that you can pass to tasks within the job, see Job Parameters.
  9. In the Description tab in the lower pane, type a description of the job. Since this job can be run by other users, it is helpful to provide a description so that others know what the job does.
  10. To restrict the client computers that this job can run on, see Specifying Which Computers A Job Can Run On.
  11. Use the appropriate procedure to finish creating the job.

    If this is an automated job, add tasks to the job by using the procedure in the topic Defining Tasks.

    If this is a configuration job, continue creating the job by using the procedure in the topic Creating a Configuration Job .

    If this is a library job, continue creating the job by using the procedure in the topic Creating a Library Job.

    If this is a manual job, continue creating the job by using the procedure in the topic Creating a Manual Job.

  12. Click Save ( [image]) to save the job.

Click to show or hide information. Optional job information

In addition to the values that DTM uses, a job can also contain information that you can use either to document the job or to make it easier to search and filter all jobs. This information has no effect on how the job behaves; it is merely descriptive.

The optional values that you can set are:

  • Assigned to: The DTM user name of the person that the job is assigned to. By default, this is the user name of the person who created the job.
  • Priority: The level of importance of the job. Valid values are 0, 1, 2, or 3.
  • Expected Runtime: The amount of time, expressed in days, hours, and minutes, that you expect the job to run.
  • Keywords: Any string of text that you will use for grouping or documenting the job.
  • Text1, Text2: Any string of text that you will use for grouping or documenting the job.
  • Int1, Int2: Any integer that you will use for grouping or documenting the job.
  • URL: The address of a Web site that is relevant to the job. If a URL is provided for the job, you can right-click the job in Job Explorer, and then click Go To Feature Site to open the Web page identified by the URL.

For more information about searching jobs, see How Jobs Are Organized.


Creating a Configuration Job

A configuration job is used to set the value of a dimension. Configuration jobs can be executed automatically when DTM is trying to execute another job that requires the dimension.

A common DTM paradigm is to use a dimension to represent setup tasks having been completed on the client computer. A configuration job that sets the dimension executes the tasks that configure the client computer. A configuration job that deletes the dimension executes the tasks that clean up the client computer. All of the jobs that require the client computer to have been set up have a constraint that specifies a value for the dimension. By using this paradigm, you can have one pair of configuration jobs to set up and clean up the client computer, instead of repeating the same setup and cleanup tasks in each job that requires them. When a job that requires the dimension is executed, the configuration job is executed automatically. Furthermore, if any other jobs that require the same setup are scheduled to execute, then these other jobs can run after the first job has completed before the cleanup is done. This optimization means that setup and cleanup tasks can be executed only once, and all jobs can be executed on a client computer that has already been set up.

You must specify the following three things in a configuration job:

  1. The dimension that will be changed.
  2. A parameter that will be used as the value of the dimension.
    If this job sets a dimension, as opposed to deleting a dimension, then the value that’s given to the dimension will be the value of the parameter.
  3. Tasks that change the dimension.
    These tasks configure or clean up the client computer.

If you want the value of a dimension to persist when the client computer is rebooted, include a task that uses the wttcmd command to add a registry key for the dimension.

Click to show or hide information. To create a configuration job

  1. Create a new job and enter the basic job information.
  2. In the bottom pane of the New Job window, select the Parameters tab.
  3. In the Name column, enter a name for the parameter.
  4. From the drop-down list in the Type column, select String.
  5. In the Value column, enter a value for the parameter. This is the value that will be assigned to the dimension when the job finishes executing.
  6. On the Dimension Change tab, select Delete if this job will delete the dimension, or select Set if this job will set a value for the dimension.
  7. In the Dimension column, select the dimension to set.

    Note To set the value of a dimension, the dimension must already be defined on the controller. To define a new dimension, see Defining and Viewing Dimensions.

  8. In the Parameter column, enter the name of the parameter that represents the value for the dimension. If this job sets a dimension, than the parameter specifies the value that will be assigned to the dimension. If this job deletes a dimension, then it will only delete a dimension whose value matches the value of the parameter.
  9. Add tasks to the job by using the procedure in the topic Defining Tasks.
  10. Click Save ( [image]) to save the job.


Creating a Library Job

A library job is similar to an execute job, except that library jobs can be called by tasks in other jobs. In this sense, a library job functions like a subroutine in a program.

To pass parameters from the task that calls the library job to the library job itself, define the parameters within the library job, and then follow the detailed procedure in the Creating a Run Job Task topic. For more information about using parameters, see Using Parameters.

Click to show or hide information. To create a library job

  1. Create a new job and enter the basic job information.
  2. Add tasks to the job by using the procedure in the topic Defining Tasks.
  3. Click Save ( [image]) to save the job.


Creating a Manual Job

A manual job represents work that must be performed by a person and is rare.

If you believe that you need to use a manual job, first consider whether an automated job with a manual task will suffice. If not, use the Feedback Link at the bottom of this topic to send an e-mail message that explains the scenario that you are creating a manual job for.


Defining Tasks

Automated, configuration, and library jobs contain tasks that perform the work of the job. The procedure for adding tasks is the same for each type of job. See Basic Task Concepts for more information about tasks.

Click to show or hide information. To define a task

  1. Create or edit a job.
  2. In the bottom pane of the New Job window, select the Tasks tab.
  3. Select the Setup, Regular, or Cleanup tab to define tasks that run in the setup, regular, or cleanup phases, respectively. The procedure for adding tasks is the same for all of these phases.
  4. Select one of the following orders that the tasks should run in:
    • Execute these tasks sequentially, in the order given below: Only one task in the job will run at a time. The tasks will run in the order in which they are listed in the job.

      Note If you run the job on more than one client computer, multiple tasks might execute simultaneously on different computers, but only one task will execute at a time on any individual client computer.

    • Execute these tasks in parallel: All of the tasks are executed simultaneously.
    • Execute these tasks according to custom dependencies: The tasks are executed based on an order that you define. For more information about creating custom dependencies, see Executing Tasks in a Custom Order.
  5. Click Add.
  6. In the Task Type dialog box, select the type of task that you want to create:
    • Execute: This task will execute any valid command that you could type at a command prompt.
    • Copy File: This task will copy files from a source location to a location on the client computer.
    • Copy Result: This task will copy files from a location on the client computer to a destination location.
    • Run Job: This task will run a library job.
    • Manual Prompt: This task will display a message to the user on a client computer and wait for the user to respond.
  7. Click OK.
  8. In the Add Task Details dialog box on the General tab, type a name for the task.
  9. In the Failure Action box, select one of the following actions that you want to happen if the task fails:
    • FailAndContinue: If this task fails, other tasks will continue to run, but the job itself will fail.
    • FailAndStop: If this task fails, then any remaining setup and regular tasks will be canceled, any cleanup tasks will run, and the job will fail.
    • FailStopFreeze: If this task fails, any task within this job that is currently running will be stopped and no new tasks will be started. The client computer’s status will be set to Debug.
    • IgnoreFailAndContinue: If this task fails, the rest of the tasks in the job will still run. The failure of this task will not affect the success or failure of the job itself.
  10. Use the appropriate procedure to finish creating the task.

    If this is an execute task, continue creating the task by using the procedure in the topic Creating an Execute Task.

    If this is a copy file task, continue creating the job by using the procedure in the topic Creating a Copy File Task .

    If this is a copy result task, continue creating the job by using the procedure in the topic Creating a Copy Result Task

    If this is a run job task, continue creating the job by using the procedure in the topic Creating a Run Job Task

    If this is a manual prompt task, continue creating the job by using the procedure in the topic Creating a Manual Prompt Task.

  11. Repeat this procedure beginning at step 5 to define the other tasks in this phase.
  12. Repeat this procedure beginning at step 3 to add tasks to the other job phases.


Creating an Execute Task

Tasks perform the work of a job. An Execute task is the most common type of task and is used to execute any command that you could type at the command prompt. For more information about tasks, see Basic Task Concepts.

Click to show or hide information. To define an Execute task

  1. Create or edit an Execute task within a job.
  2. For some tasks, it might be acceptable for the task to succeed eventually, even if the task does not succeed the first time it is run. For example, it might be appropriate to retry a task that uses an unstable network connection.
    If this task should be rerun when it fails, provide the following information:
    1. In the On failure, retry the task x times box, type the number of times that the task should be rerun. If the task has not passed after it has been run this many times, the task will fail.
    2. In the at an interval of x seconds box, type the number of seconds that should elapse before the task is rerun.
  3. In the Add Task Details dialog box on the Execute , type the command that should be executed when the task is run.

    Note To pass parameters from the job to the task and use these parameters within the command, see Using Parameters.

  4. If this task requires a command shell to run, select the Create new command shell for this task check box. If you do not select the Create new command shell for this task check box, the task will be run from the windows environment and will not be able to access environment variables.

    Tip If the command line contains an MS-DOS command, executes a batch script, or requires environment variables, then it probably requires a command shell to run.

  5. Select the Check this to fail the task if it does not reboot the machine check box if you expect the client computer to reboot when this task runs. If the client computer reboots while running this task, and you did not select this check box, then the task will fail. If the client computer does not reboot and you did select this check box, then the task will also fail.
  6. If this task’s completion status should affect the completion status of the job, select Rollup Results to Job. If you do not roll the task’s results up to the job, then if the task fails, it will not cause the job to fail.
  7. To run the task from a specific directory, select the Use the following directory option and enter the path to the directory that the task should run in. If you accept the default of Use the jobs working directory, the task will run from a temporary directory that will be deleted when the job completes.
  8. If the task should stop automatically after a specific amount of time, on the Execution Options tab, select Set timeout to, type the number of days, hours, and minutes after which you want to cancel the task, and then select Cancel task and declare failure if the task is still running (task timeout).
    If the task is still running after the specified amount of time, the task will fail.
  9. If the task should still be running after a specific amount of time, on the Execution Options tab, select Set timeout to, enter the number of days, hours, and minutes after which you want to check whether the test is still running, and then select Declare failure if the task stops before the timeout (infinite task).
    If the task is not running after the specified amount of time, the task will fail.
  10. If you want this task to run at the beginning of the phase, and other tasks to run immediately after this task starts running, then select This task will be running in the beginning of the execution phase in the Daemon Task section of the Execution Options tab.
  11. If you want this task to run at the end of the phase, after all of the other tasks have finished running, select This task will be running in the end of the execution phase in the Daemon Task section of the Execution Options tab.

    12. Note DTM will reorder the list of tasks on the Tasks tab of the New Job window and place all daemon tasks at the beginning of the list. Daemon tasks do not affect the order that non-daemon tasks run, regardless of whether you selected parallel, sequential, or custom task execution.

  12. In the User Context section of the Execution Options tab, select the user context and session that will be used to run the task on the client computer, and then select one of the following options:
    • Run in System Context to run in the system context (also called “session zero” or “console”) on the client computer. There is no desktop associated with the system context, and therefore no display. Services commonly run in the system context.
    • Run as the user that is logged onto the first active session to run in the context of the user that is logged on to the first active session on the client computer. If no user is logged on to the client computer, the task will fail.
    • Run as user in user’s active session to run as a specific user, if that user is logged on to the client computer. If the user is not logged on, the task will fail.
    • Run as user in Console if logged in to run as a specific user if that user is logged on to the client computer. However, the task will run in session zero, rather than in the user’s session. If the user is not logged on, the task will fail.
    • Run as user in Console even if not logged in to run as a specific user in session zero, even if the user is logged on to the client computer.
  13. If you selected Run as user in user’s active session, Run as user in session zero if logged in, or Run as user in session zero if not logged in, use the following procedure to identify the user:
    1. In the User Credentials section of the Execution Options tab, select Run as Specific User to identify the user by user name, or select Run as Local Logical User to identify the user by using a Local Logical User (LLU).
    2. If you selected Run as Specific User, enter the user name and domain of the user to run as. If the User Context is Run as user in Console even if not logged in, also enter the user’s password.

      Caution The password is stored on the controller and is not secure.

    3. If you selected Run as Local Logical User, enter the LLU as the Local Name.
  14. Click OK to return to the New Job window.


Creating a Copy File Task

Tasks perform the work of a job. A Copy File task copies files from a source location to a location on the client computer. For more information about tasks, see Basic Task Concepts.

Click to show or hide information. To define a Copy File task

  1. Create or edit a Copy File task within a job.
  2. For some tasks, it might be acceptable for the task to succeed eventually, even if the task does not succeed the first time it is run. For example, it might be appropriate to retry a task that uses an unstable network connection.
    If this task should be rerun when it fails, provide the following information:
    1. In the On failure, retry the task x times box, enter the number of times that the task should be rerun. If the task still does not pass after it has been rerun the specified number of times, the task will fail.
    2. In the at an interval of x seconds box, enter the number of seconds that should elapse before the task is rerun.
  3. On the Copy Files tab, click Add.
  4. In the Add Copy File dialog box, enter a Universal Naming Convention (UNC) path to the location of the files to be copied.

    Note The source path can contain wildcards.

  5. Select the destination on the client computer that the files should be copied to. Select Job’s working directory to copy the files to a system-generated directory that will be deleted when the job completes, or select Custom and enter a local path on the client computer. Since this job might run on multiple client computers, do not use specific drive letters. To use an environment variable such as %TEMP% as part of the local path, see Job Parameters.
  6. If this task should copy all subdirectories below the source directory, then select Recursive.
  7. Click OK to close the Add Copy File dialog box.
  8. In the User Context section of the Execution Options tab, select one of the following user contexts and sessions that will be used to run the task on the client computer:
    • Run in System Context to run in the system context (also called “session zero” or “console”) on the client computer. There is no desktop associated with the system context, and therefore no display. Services commonly run in the system context.
    • Run as the user that is logged onto the first active session to run in the context of the user that is logged on to the first active session on the client computer. If no user is logged on to the client computer, the task will fail.
    • Run as user in user’s active session to run as a specific user, if that user is logged on to the client computer. If the user is not logged on, the task will fail.
    • Run as user in Console if logged in to run as a specific user if that user is logged on to the client computer. However, the task will run in session zero rather than in the user’s session. If the user is not logged on, the task will fail.
    • Run as user in Console even if not logged in to run as a specific user in session zero, even if the user is logged on to the client computer.
  9. If you selected Run as user in user’s active session, Run as user in session zero if logged in, or Run as user in session zero if not logged in, then use the following procedure to identify the user:
    1. In the User Credentials section of the Execution Options tab, select Run as Specific User to identify the user by user name, or select Run as Local Logical User to identify the user by using a Local Logical User (LLU).
    2. If you selected Run as Specific User, enter the user name and domain of the user to run as. If the User Context is Run as user in Console even if not logged in, also enter the user’s password.

      Caution The password is stored on the controller and is not secure.

    3. If you selected Run as Local Logical User, enter the LLU as the Local Name.
  10. Click OK to return to the New Job window.


Creating a Copy Result Task

Tasks perform the work of a job. A Copy Result task copies files from a location on the client computer to a remote destination. For more information about tasks, see Basic Task Concepts.

Click to show or hide information. To define a Copy Result task

  1. Create or edit a Copy Result task within a job.
  2. For some tasks, it might be acceptable for the task to succeed eventually, even if the task does not succeed the first time it is run. For example, it might be appropriate to retry a task that uses an unstable network connection.
    If this task should be rerun when it fails, provide the following information:
    1. In the On failure, retry the task x times box, enter the number of times that the task should be rerun. If the task has not passed after it has been rerun the specified number of times, the task will fail.
    2. In the On failure, retry the task x times box, enter the number of times that the task should be rerun. If the task has not passed after it has been rerun the specified number of times, the task will fail.
  3. On the Copy Results tab, click Add.
  4. In the Add Copy Result dialog box, enter the path to the files on the client computer to copy.

    Note The source path can contain wildcards.

  5. If the files to be copied are in the system-generated directory that was created for the job, select Preface source with Jobs working directory.
  6. To specify the name of a subdirectory to contain the copied files, select Sub Folder, and then enter the name for the directory.
  7. Select Prefix destination filename with computer name to include the name of the client computer that the files are copied from in the name of each destination file.
  8. Select Exact Destination to use the source file’s name as the name of the destination file.

    Note If you select Exact Destination, the source path cannot contain wildcards.

    Note You can only specify Exact Destination if you provided a Sub Folder.

  9. If this task should copy all subdirectories below the source directory, select Copy Recursively.
  10. Click OK twice to close the Add Copy Result dialog box and return to the New Job window.


Creating a Run Job Task

Tasks perform the work of a job. A Run Job task runs another job (a library job) as part of the job that the task is defined in. For more information about tasks, see Basic Task Concepts.

Click to show or hide information. To define a Run Job task

  1. Create or edit a Run Job task within a job.
  2. If you know the ID of the library job, enter it in the ID field. Otherwise, use the following procedure to find the library job to run:
    1. Click Browse.
    2. On the Feature tab of the Library Job Chooser dialog box, expand the nodes in the feature hierarchy until you find the node that contains the library job to run.
    3. Select the library job to run from the lower right pane and click OK.
  3. If this task’s completion status should affect the completion status of the job, select Rollup Results to Job. If you do not roll the task’s results up to the job, then if the task fails, it will not cause the job to fail.
  4. If the library job defines parameters, a grid will appear at the bottom of the Run Job tab. If you want to pass a value for a parameter to the library job, use the following procedure to specify the parameters:
    1. Select the name of the parameter in the library job from the Library Job Param Name column in the first empty row of the grid.
    2. To pass a variable value to the library job, in the Job Param Name column, select the name of the parameter in this job whose value you will associate with the variable in the library job.

      Note You must have defined the variable in this job before you can associate it with a parameter in the library job.

    3. To pass a constant value to the library job, enter the value in the Value column.
    4. To provide values for additional parameters in the library job, repeat this procedure beginning with step a.
  5. Click OK to return to the New Job window.


Creating a Manual Prompt Task

Tasks perform the work of a job. A Manual Prompt task displays a message to the user on the client computer, and then waits for the user to respond. For more information about tasks, see Basic Task Concepts.

Click to show or hide information. To define a Manual Prompt task

  1. Create or edit a Manual Prompt task within a job.
  2. In the Instructions to user pane, type the message that will be displayed on the client computer when the task runs.
  3. If this task’s completion status should affect the completion status of the job, select Rollup Results to Job. If you do not roll the tasks results up to the job, then if the task fails, it will not cause the job to fail.
  4. Select Provide User with “Pass” and “Fail” buttons to have buttons labeled Pass and Fail added to the message dialog box. Or, select Provide User with “Continue” button to have a button labeled Continue added to the message dialog box.
    When the task runs, if the user selects the Pass or the Continue button, the task will pass. If the user selects the Fail button, or closes the dialog box without selecting any button, the task will fail.
  5. Click Preview if you want to see preview of the message that will be displayed to the user when the task runs.

  6. If the task should fail when the user does not respond to the prompt within a certain amount of time, on the Execution Options tab, select the Set timeout to check box and enter the number of hours, days, and minutes after which the task should fail.

  7. If the task should fail when the user does respond to the prompt within a certain amount of time, on the Execution Options tab, select the Set timeout to check box and enter the number of hours, days, and minutes after which the task should fail.
  8. In the User Context section of the Execution Options tab, select one of the following user contexts and sessions that will be used to run the task on the client computer:
    • Run as the user that is logged onto the first active session to run in the context of the user who is logged on to the first active session on the client computer. If no user is logged on to the client computer, the task will fail.
    • Run as user in user’s active session to run as a specific user, if that user is logged on to the client computer. If the user is not logged on, the task will fail.
    • Run as user in Console if logged in to run as a specific user if that user is logged on to the client computer. However, the task will run in session zero rather than in the user’s session. If the user is not logged on, the task will fail.
    • Run as user in Console even if not logged in to run as a specific user in session zero, even if the user is logged on to the client computer.
  9. If you selected Run as user in user’s active session, Run as user in session zero if logged in, or Run as user in session zero if not logged in, then use the following procedure to identify the user:
    1. In the User Credentials section of the Execution Options tab, select Run as Specific User to identify the user by user name, or select Run as Local Logical User to identify the user by using a Local Logical User (LLU).
    2. If you selected Run as Specific User, enter the user name and domain of the user to run as. If the User Context is Run as user in Console even if not logged in, also enter the user’s password.

      Caution The password is stored on the controller and is not secure.

    3. If you selected Run as Local Logical User, enter the LLU as the Local Name.
  10. Click OK to return to the New Job window.


Executing Tasks in a Custom Order

The tasks in a job can be assigned to the setup, regular, or cleanup phases. Tasks in the regular phase execute after all of the tasks in the setup phase finish executing. Tasks in the cleanup phase execute after all of the tasks in the regular phase finish executing, or after a task in the setup or regular phase fails and the failing task’s failure action is FailAndStop.

Within a phase, you can declare that the tasks run in series or in parallel. In addition to serial and parallel execution, you can create daemon tasks that begin running either before or after all other tasks and might run in parallel with the other tasks. If you need to provide a more complex ordering of tasks within a phase, you can create custom dependencies. Custom dependencies are particularly useful for jobs that execute on more than one computer simultaneously, such as jobs that use a Logical Machine Set (LMS). You can create dependencies between two tasks that execute on the same computer, between two tasks that execute on all computers, or between two instances of the same task that execute on different computers.

For example, consider a job that has three tasks and requires two client computers. The first task distributes data to both computers. Unfortunately, the program that distributes data can only run on one computer at a time. The second task runs the test. However, the test cannot run on a computer until the data has already been distributed to that computer. The third task collects the results of the test on both computers. Before it can collect the results, though, the test must have finished running on all computers. The following figure illustrates these dependencies.

Example of tasks that require custom dependencies

You can represent the requirements for ordering the tasks by using custom dependencies. The following table shows how you would define the dependencies.

Task 1 (T1) | Task 2 (T2) | Dependency
Distribute | Distribute | T2 on each machine executes after T1 on previous machine
Distribute | Test | T2 on each machine executes after T1 on same machine
Test | Collect | T2 on all machines executes after T1 on all machines

Click to show or hide information. To specify a custom order for task execution

  1. Create or edit a job and add all of the tasks for the job.
  2. Select the Tasks tab in the bottom pane of the New Job window, and then select either the Setup tab to create dependencies between tasks in the setup phase, the Regular tab to create dependencies between tasks in the regular phase, or the Cleanup tab to create dependencies between tasks in the cleanup phase.
  3. Select Execute these tasks according to custom dependencies, and then click Dependencies.

    Note The Dependencies button will appear after you select Execute these tasks according to custom dependencies.

  4. Click Add in the Task Dependency List dialog box.
  5. In the Add Task Dependencies dialog box, select the dependent task as T2. This is the task that will execute after the task that you specify next.
  6. Select the task that T2 depends on as T1.
  7. In the Dependency area, select the type of dependency that exists between the task that you designated as T1 and the task that you designated as T2. The dependencies you can select include:
    • T2 on all machines executes after T1 on all machines: T2 will not execute until T1 has finished executing on all of the computers that task T1 is scheduled to run on.
    • T2 on each machine executes after T1 on same machine: T2 on a specific computer will execute after T1 on that same computer has finished executing.
    • T2 on each machine executes after T1 on previous machine: Only one instance of the task can run at a time. When the task finishes running on one computer, it can be started on another computer.

      Note This option is only available if you select the same task as both T1 and T2.

  8. Click OK.
  9. Repeat this procedure beginning at step 4 to define additional dependencies for this job phase.
  10. Repeat this procedure beginning at step 2 to define custom dependencies for the other job phases.


Specifying Which Computers a Job Can Run On

Dimensions specify characteristics of a client computer, such as the computer having an x86-based processor, or that it is running the Microsoft Windows XP operating system. When you define a job, you can constrain it to run only on client computers whose dimensions match certain conditions. For example, you can specify that a job that runs a multi-processor test can execute only on client computers that have more than one processor. You indicate that a job can run only on certain types of client computers by specifying constraints for the job. A set of constraints is called a context.

When you execute a job, DTM searches for an available client computer that matches the job’s constraints and “pushes” the job to the client computer. For example, assume that there are three client computers with the following values for their dimensions:

Computer Name | WTT\Processor | WTT\OS | WTT\ProcCount
Client1 | X86 | Windows XP | 1
Client2 | X86 | Windows XP | 2
Client3 | X64 | Windows Server 2003 | 2

Consider a job with the following two constraints:

WTT\Processor equals x86

WTT\OS equals Windows XP

Both Client1 and Client2 satisfy the job’s constraints. If only Client1 had a status of Ready, the scheduler would push the job to Client1 to execute. If both Client1 and Client2 had a status of Ready, the scheduler would choose either Client1 or Client2 and push the job to that computer to execute.

You can create a single job that runs in multiple contexts by defining a mix for the job. A mix is a set of contexts. Each context describes one type of client computer that the job should run on. When you execute the job, one instance of the job is created for each context in the mix.

To continue the previous example with Client1, Client2, and Client3, consider a job with the following mix:

Context1:

WTT\Processor equals x86

WTT\ProcCount equals 1

Context2:

WTT\Processor equals x64

WTT\ProcCount equals 2

When you execute this job, the scheduler will create two instances of the job: one instance for Context1 and one instance for Context2. The scheduler will then search for client computers to execute the job instances. Since Client1 is the only client computer that satisfies the constraints of Context1, the scheduler will push the Context1 instance of the job to Client1 if Client1 has a status of Ready. Since Client3 is the only client computer that satisfies the constraints of Context2, the scheduler will push the Context2 instance of the job to Client2 if Client2 has a status of Ready.

Some jobs require more than one client computer to execute. For example, a job that runs a network test might require one client computer to send packets across the network, and a second client computer to receive the packets. Logical Machine Sets (LMSes) allow you to specify contexts for the different roles that client computers play in a single job. To continue the example, if the client computer that sent the packets had to be running a server version of the operating system, and the client computer that received the packets had to be running a client version of the operating system, you could create an LMS to constrain the client computers. The LMS would have two contexts: a server context that constrained the operating system to be a server version, and a client context that constrained the operating system to be a client version.

You can also add constraints or restrict the job to execute on specific client computers when you schedule the job to execute. For more information about adding constraints and restricting client computers when you schedule a job, see Executing a Job.

This section includes the following topics:

Using Constraints in a Job

Using a Mix in a Job

Using a Logical Machine Set in a Job


Using Constraints in a Job

A constraint specifies a condition that a client computer must meet in order for a job to run on the computer. Each constraint compares the value of a dimension on the client computer with a value that you specify. For example, if you create a job to run a multi-processor test, you could add a constraint to the job that specifies that the job can only execute on client computers whose WTT\ProcCount dimension has a value greater than one.

For more information about constraints and additional ways to restrict the client computers that a job can execute on, see Specifying Which Computers a Job Can Run On.

Click to show or hide information. To add constraints to a job

  1. Create or edit a job.
  2. On the Constraints tab in the bottom pane of the New Job window, move the cursor to the Dimension cell in the first empty row, and then select the dimension that you want to compare from the drop-down list.
  3. In the Operator column, select the operator that you want to use to compare the dimension to its value. The list of operators might vary depending on the dimension that you selected:
    • Equals: The value of the dimension is equal to the value that you specify in the constraint.
    • Not Equals: The value of the dimension is not equal to the value that you specify in the constraint.
    • Less Than: The value of the dimension is less than the value that you specify in the constraint.
    • Greater Than: The value of the dimension is greater than the value that you specify in the constraint.
    • Less Than or Equal To: The value of the dimension is less than or equal to the value that you specify in the constraint.
    • Greater Than or Equal To: The value of the dimension is greater than or equal to the value that you specify in the constraint.
    • Contains: The value of the dimension contains the string that you specify in the constraint.
    • Not Contains: The value of the dimension does not contain the string that you specify in the constraint.
    • Within: The value of the dimension is one of the values that you specify in the constraint.
    • Not Within: The value of the dimension is not one of the values that you specify in the constraint.
    • Exists: The dimension is defined on the client computer.
    • Not Exists: The dimension is not defined on the client computer.
  4. In the Value column, enter the value to compare the dimension to.

    Note If the operator is Within or Not Within, you must select the value from a list. If the operator is Exists or Not Exists, do not enter a value.


Using a Mix in a Job

If you want your job to run on multiple computers, where each computer meets a different set of criteria, you can use a mix.

A mix is a set of contexts. Each context contains constraints and parameters. Each constraint compares the value of a dimension on the client computer with a value that you specify. You can use parameters to provide different values to the command lines within the tasks for each context.

For example, assume the program MyTest.exe tests different features of a driver on 32-bit and 64-bit versions of the Windows XP operating system. You want to create one job that runs MyTest.exe on both versions of the operating system. However, you have to invoke MyTest.exe with a different flag for each operating system. To do this, you would create a job to run the test and add a mix, with two contexts, to the job. Each context would have a different constraint for the operating system. Both contexts would define the same parameter to represent the flags that are passed to MyTest.exe, but each context would specify a different value for the parameter. The following table summarizes these details.

Context Name | Constraint | Parameter
32-bit Windows XP | WTT\OS equals Windows XP | flags = “/32-bit”
64-bit Windows XP | WTT\OS equals Windows XP 64-Bit Edition Version 2003 | flags=”/64-bit”

The command line within the task that runs MyTest.exe would be:

MyTest.exe [flags]

For more information about mixes and additional ways to restrict the client computers that a job can execute on, see Specifying Which Computers a Job Can Run On. For general information about parameters, see Using Parameters.

Click to show or hide information. To add a mix to a job

  1. Create or edit a job.
  2. On the Constraints tab in the bottom pane of the New Job window, click Add Mix.

    Note You might have to expand the New Job window to see the Add Mix button.

  3. In the Choose Mix Source dialog box, select Local for the Mix Source, select Simple for the Type, and then click OK.

  4. In the New Mix dialog box, type a name for the mix.
  5. In the Contexts tab, click Add.
  6. Type a name for the context in the Add Context dialog box.
    You should choose a meaningful name for the context. When you examine the progress of the job by using Job Monitor, the context name for each instance of the job that is executing will be displayed.
  7. On the Constraints tab in the bottom pane of the Add Context dialog box, move the cursor to the Dimension cell in the first empty row, and then select the dimension that you want to compare from the drop-down list.
  8. In the Operator column, select the operator that you want to use to compare the dimension to its value. The list of operators might vary depending on the dimension that you selected:
    • Equals: The value of the dimension is equal to the value that you specify in the constraint.
    • Not Equals: The value of the dimension is not equal to the value that you specify in the constraint.
    • Less Than: The value of the dimension is less than the value that you specify in the constraint.
    • Greater Than: The value of the dimension is greater than the value that you specify in the constraint.
    • Less Than or Equal To: The value of the dimension is less than or equal to the value that you specify in the constraint.
    • Greater Than or Equal To: The value of the dimension is greater than or equal to the value that you specify in the constraint.
    • Contains: The value of the dimension contains the string that you specify in the constraint.
    • Not Contains: The value of the dimension does not contain the string that you specify in the constraint.
    • Within: The value of the dimension is one of the values that you specify in the constraint.
    • Not Within: The value of the dimension is not one of the values that you specify in the constraint.
    • Exists: The dimension is defined on the client computer.
    • Not Exists: The dimension is not defined on the client computer.
  9. In the Value column, enter the value to compare the dimension to.

    Note If the operator is Within or Not Within, you must select the value from a list. If the operator is Exists or Not Exists, do not enter a value.

  10. Repeat this procedure beginning at step 7 to add additional constraints to the context.
  11. If you want to add parameters to the context, select the Parameters tab and use the following procedure to add the parameters:
    1. Enter a name for the parameter in the Name column.
    2. In the Type column, select String.

      Note Parameters can also have the type FileData. A FileData parameter represents a file whose contents you specify in the job. A separate instance of the file is copied to the client computer each time the job is executed. FileData parameters are used primarily to copy a script to a client computer and to reference the script in the task that runs it. For more information about using FileData parameters, see Using FileData Parameters.

    3. Type a description of what the parameter is used for in the Description column.
    4. If you want the user to be able to override the value of this parameter when the job is scheduled, select the ScheduleDisplay check box.
    5. In the Value column, enter the default value for this parameter. If you do not enter a value, the default will be an empty string.

      Tip Parameters can be nested. For example, you could define a parameter named ServerName and give it the value of “MyServer”. You could define a second parameter named DataFileLocation and give it the value “\\[ServerName]\test”. You could then use DataFIleLocation within a task, for example, by using the command line:
      TestProgram.exe /datafile=[ DataFileLocation]

      When the task was executed, TestProgram.exe would receive a datafile argument with the value “\\MyServer\test”.

  12. When you have added all of the constraints and parameters to the context, click OK.
  13. Repeat this procedure beginning at step 5 to add each additional context.
  14. When you have added all of the contexts, click OK.


Using a Logical Machine Set in a Job

If you have a test that requires more than one computer, and the computers play different roles in the test, you can add Logical Machine Sets (LMSes) to your job to specify the required computers. Each LMS defines constraints that restrict the computers to be used in each role and specifies the number of required computers. For example, if your test requires one computer to run the server-side component of the test, and three computers to run the client-side component of the test, you would create a job with two LMSes. The first LMS would include constraints that the computer in the server role must meet. The second LMS would include constraints that the computers in the client role must meet. In addition, the second context would specify that three computers that match the constraints in this context are required.

When you define an LMS, you supply a name for each context in the LMS. To continue the previous example, you might name the context for the server computer “server”, and you might name the context for the client computers “client”. When you add tasks to the job, you specify which context’s computers to run the task on. In this example, you would assign the task that runs the server-side component of the test to the server context. You would assign the task that runs the client-side component of the test to the client context.

DTM automatically defines variables with the same names as the LMSes. These variables are useful when the computers in different roles of the same job need to know the names of the computers in other roles of the job. Continuing the previous example, if each client needed to know the name of its server, in the command line of the task that runs the client-side part of the test, you would pass the DTM variable [server] as a command-line parameter. If there is more than one computer in the same role, the variable for that context evaluates to a comma-delimited list of the names of the computers, with no spaces between the list items. To continue the example, if DTM assigned the computers test01, test04, and test17 to be part of the client context, [client] would evaluate to the string “test01,test04,test17”.

For more information about LMSes and additional ways to restrict the client computers that a job can execute on, see Specifying Which Computers a Job Can Run On. To specify complex dependencies between the tasks, see Executing Tasks in a Custom Order.

Click to show or hide information. To specify an LMS for a job

  1. Create or edit a job.
  2. On the LMS tab in the bottom pane of the New Job window, select Multi Machine Job—Job requires multiple machines to execute , and then click Add.
  3. In the Add Job LMS Details dialog box, type a name for the LMS. DTM will create a variable with this name, so choose a name that is meaningful.
  4. If you need more than one client computer in this LMS, enter the minimum and maximum number of computers in the Minimum and Maximum fields. If this LMS should contain just one computer, type 1 for both Minimum and Maximum.

  5. If you want the computers in this LMS to use your constraints and the constraints that you specified for the job as a whole, if any, then select Inherit constraints from Job. If you do not want the constraints from the job as a whole to apply to this LMS, clear the Inherit constraints from Job check box. If this is the primary LMS, it must inherit constraints from the job.
  6. If you want the client computer or computers in this LMS to have specific characteristics, complete the following procedure to add constraints to the LMS:
    1. In the LMS Constraints area, move the cursor to the Dimension cell in the first empty row, and then select the dimension that you want to compare from the drop-down list.
    2. In the Operator column, select the operator that you want to use to compare the dimension to its value. The list of operators might vary depending on the dimension that you selected:
      • Equals: The value of the dimension is equal to the value that you specify in the constraint.
      • Not Equals: The value of the dimension is not equal to the value that you specify in the constraint.
      • Less Than: The value of the dimension is less than the value that you specify in the constraint.
      • Greater Than: The value of the dimension is greater than the value that you specify in the constraint.
      • Less Than or Equal To: The value of the dimension is less than or equal to the value that you specify in the constraint.
      • Greater Than or Equal To: The value of the dimension is greater than or equal to the value that you specify in the constraint.
      • Contains: The value of the dimension contains the string that you specify in the constraint.
      • Not Contains: The value of the dimension does not contain the string that you specify in the constraint.
      • Within: The value of the dimension is one of the values that you specify in the constraint.
      • Not Within: The value of the dimension is not one of the values that you specify in the constraint.
      • Exists: The dimension is defined on the client computer.
      • Not Exists: The dimension is not defined on the client computer.
    3. In the Value column, enter the value to compare the dimension to.

      Note If the operator is Within or Not Within, you must select the value from a list. If the operator is Exists or Not Exists, then do not enter a value.

    4. Repeat steps a through d to add additional constraints.
  7. If you selected Inherit constraints from Job, click Show Conflicts to display a report of any conflicts between this LMS and the job as a whole.
  8. Click OK.


Using Variables within a Job

A task can reference information about the job or about the computer that the job is executing on by using a variable. When the job executes on a client computer, variables are replaced with their values.

Variables can be used in different places for each type of task.

  • In an Execute task, variables can be used within the command line, working directory, log file name, user name, domain, password, and local name.
  • In a Copy File task, variables can be used within the source file name, destination directory, user name, domain, password, and local name.
  • In a Copy Result task, variables can be used within the source file name, destination directory, user name, domain, password, and local name.
  • In a Manual Prompt task, variables can be used within the user name, domain, password, and local name.
  • Variables cannot be used within a Run Job task.

Certain types of variables can also contain references to other variables. For more information about nesting variables, see Using Parameters.

You can use the following types of variables within a task:

  • Dimensions
  • Environment variables
  • Run-time variables
  • Parameters

DTM creates a variable that corresponds to each dimension. When a job that uses a dimension as a variable is executed, the variable is replaced with the value of the dimension on the client computer. For more information about using dimensions, see Using Dimensions as Variables.

Operating system environment variables can be used within a task. When the task is executed, the variable is replaced with the value of the environment variable on the client computer. For more information about using environment variables, see Using Environment Variables within a Job.

DTM provides information about the context that the job is running in as run-time variables. For more information about using run-time variables, see Using Run-Time Variables.

You can define your own variables, called parameters, and use them to pass values to the tasks in the job. Fore more information about using parameters, see Using Parameters.

To evaluate a variable, enclose the name of the variable in square brackets. For example, the environment variable “[TEMP]” would be replaced with the path to the directory where temporary files are stored when the job that referenced the variable was run. Similarly, the dimension [WTT\machinename] would be replaced with the name of the client computer.


Using Dimensions as Variables

Each dimension that is defined on the DTM controller can be used as a variable within a job. When the job is executed, references to the dimension are replaced with the value of the dimension on the client computer.

For example, assume that a program called MyTest.exe requires a command-line argument that indicates the amount of RAM on the computer that MyTest.exe is running on. WTT\RAM is a built-in dimension that provides exactly the information that MyTest.exe needs. You could create a job with a task whose command line is “MyTest.exe [WTT\RAM]” to run the test and pass the amount of RAM as a command-line parameter.

Although any dimension that is defined on the DTM controller can be used as a variable, some dimensions might not have a value on all client computers. For example, a lab manager might create the dimension ComputerManufacturer to indicate the manufacturer of each computer in the lab. Perhaps, however, the lab manager only set a value for the ComputerManufacturer dimension on half of the client computers. A task with the command line “MyTest2.exe [ComputerManufacturer]” would work differently on the client computers whether they did or did not have values for the ComputerManufacturer dimension, as shown in the following table.

If the value of ComputerManufacturer is… | The command line that is executed is…
MyCompany | MyTest2.exe MyCompany
Undefined | MyTest2.exe [ComputerManufacturer]

See Defining and Viewing Dimensions for more information about:

  • Viewing all dimensions that are defined on the DTM controller.
  • Defining a new dimension.
  • Providing a value for a dimension on a client computer.


Using Environment Variables within a Job

You can use system environment variables within a job by enclosing the name of the variable within square brackets. User environment variables, however, cannot be used as variables within a job.

For example, assume that a program called MyTest.exe requires a command-line argument that specifies where to place temporary files. The system environment variable TEMP provides this information. You could create a job with a task whose command line is “MyTest.exe [TEMP]” to run the test and pass the location for temporary files as a command-line parameter.


Using Run-Time Variables

When a job executes, DTM makes information about the job available as run-time variables. Run-time variables describe the job and task as well as the execution environment.

The following table describes the run-time variables that are provided by DTM.

Variable Name | Meaning
WTTJobName | The name (TCM name) of the job to which the task belongs.
WTTFullName | Trace name or fully qualified name of the job, including the feature path.
WTTJobGuid | The globally unique identifier (GUID) for the job to which the task belongs.
WTTResultGuid | The GUID for the result of the job to which the task belongs.
WTTRunGuid | The GUID for the run that contains the job and any linked library jobs.
WTTTaskGuid | The GUID for the task being run.
WTTMachinePoolName | The name of the machine pool that is being scheduled.
WTTLMSName | The LMS that the task is assigned to.
<LMSName> | This name is mapped to a comma separated list of physical computers that correspond to this LMS. For example, with an LMS named MYLMS that contains three computers, "[MYLMS]" within a task will expand to "computer1,computer2,computer3".
WTTTargetMachineName | The physical computer that the task is running on. You can also get this from the [machinename] environment variable.
WTTRunWorkingDir | Default working directory for the job run.
WTTCopyLogsDest | Location to which test logs are copied when using a Copy Result task.
WTTControllerName | Name of the Controller/Push Daemon computer.
WTTDbMachineName | Name of the SQL Identity Server computer.
WTTDbName | Name of the logical datastore.

To evaluate a variable, enclose the name of the variable in square brackets.


Using Parameters

Job parameters function like user-defined variables—they allow you to pass data from the job itself to the tasks within the job. By using parameters, you can make your jobs easier to modify and reuse.

For example, you could use a parameter to specify the location where data files for a test are stored. To do this, you would define a parameter named DataFileLocation. If there were five tasks in a job that each used the same data file, the tasks could use the parameter to provide the location of the data files. Each task would have a command line of the form:

TestProgram.exe /datafile=[ DataFileLocation]

If you set DataFileLocation to “c:/data/testdata”, when each task is executed, TestProgram.exe would receive a datafile argument with the value “C:/Data/TestData”.

Parameters can be either global or local. Global parameters are defined on the DTM controller, and can be used within any job on that controller. Local parameters are defined within a job, and can only be used within the job in which they are defined.

Continuing the previous example, if DataFileLocation were a local parameter that was used in a single job, you could debug TestProgram.exe by saving your own test data in one location and giving the DataFileLocation parameter a value that points to your debugging data, such as “C:/Data/TestData”. When you were satisfied that TestProgram.exe was correct, you could change the value of the DataFileLocation to the location of the real test data, such as “\\MyServer\Data\TestData”.

If DataFileLocation were a global parameter, you could have many jobs that referenced DataFileLocation. If you moved the test data from one server to another, you could change just the value of DataFileLocation; you wouldn’t have to modify the jobs that used the DataFileLocation parameter. For example, if you moved the data files from MyServer to MyNewServer, you could simply change the value of the global DataFileLocation parameter from “\\MyServer\Data\TestData” to “\\MyNewServer\Data\TestData”. Each job that used the DataFileLocation parameter would now receive the new value.

You can override the value of a parameter when you schedule a job. When you define the parameter—either in the job for a local parameter, or by using the Management Console for global parameters—you can specify a default value and indicate whether the user can override the default value when the job is scheduled.

Continuing the example, if you overrode the value of DataFileLocation when you scheduled the job, you could provide a default location for the test data files in the job’s definition and occasionally override the default location with a new location without changing the job. For example, if the test data were stored at \\MyServer\Data\TestData, but you wanted to run MyProgram.exe with data that your customer sent you, you could change the DataFileLocation to “C:/Customer/TestData” when you scheduled the job. This would leave the value of the DataFileLocation parameter the same for every other person who used the job, and it would leave the DataFileLocation value the same the next time that you executed the job, but would allow you to use the customer’s data (one time).

To create a new global parameter, see Defining and Modifying Global Parameters.

Click to show or hide information. To define a local parameter in a job

  1. Create or edit a job.
  2. On the Parameters tab in the bottom pane of the New Job window, select the Local tab.
  3. Type a name for the parameter in the Name column.
  4. In the Type column, select String.

    Note Parameters can also have the type FileData. A FileData parameter represents a file whose contents you specify in the job. A separate instance of the file is copied to the client computer each time the job is executed. FileData parameters are used primarily to copy a script to a client computer and to reference the script in the task that runs it. For more information about using FileData parameters, see Using FileData Parameters.

  5. Type a description of what this parameter is used for in the Description column.
  6. If you want the user to be able to override the value of this parameter when the job is scheduled, select the Schedule check box.
  7. In the Value column, enter the default value for this parameter. If you do not enter a value, the default will be an empty string.

    Tip Parameters can be nested. For example, you could define a parameter named ServerName and give it the value of “MyServer”. You could define a second parameter named DataFileLocation and give it the value “\\[ServerName]\Test”. You could then use DataFIleLocation within a task, for example, by using the command line:
    TestProgram.exe /datafile=[ DataFileLocation].

    When the task was executed, TestProgram.exe would receive a datafile argument with the value “\\MyServer\Test”.

Click to show or hide information. To make a global parameter available within a job

  1. Create or edit a job.
  2. On the Parameters tab in the bottom pane of the New Job window, select the Global tab.
    All of the global parameters that have been defined on the controller are displayed.
  3. Select the global parameter that you will use in this job, and then click Add.
    The global parameter is moved to the right pane.


Executing a Job

When you schedule a job to execute, the DTM controller finds a client computer (or computers) that match the constraints of the job, and then sends the job to the client computers to execute. The client computers execute the job and report their status to the DTM controller. You can schedule jobs to execute by using Job Monitor or Job Explorer, and you can view the status of jobs that are executing or have finished executing by using Job Monitor.

Important Although you can run the “Designed for Windows” logo jobs that are included with DTM by using the procedure in this topic, you must run these jobs by using the procedure described in Using DTM to Test for a ''Designed for Windows'' Logo to submit the results for a logo.

You can modify the job to execute in specific ways when you schedule the job to execute, such as:

  • Restricting the client computers that the job can execute on by selecting the client computers explicitly, or by adding constraints.
  • Overriding values of parameters.
  • Naming the result collection.
  • Specifying when to start trying to execute the job and when to stop trying to execute the job, or cancel the job’s execution.
  • Indicating whether to allow DTM to schedule configuration jobs automatically to satisfy the job’s constraints.
  • Creating multiple instances of the job to execute.
  • Identifying users who should receive e-mail messages when the job finishes executing.

Click to show or hide information. To execute a job

  1. Switch to the Job Explorer window.
    You can also open a new Job Explorer window by clicking Explorers, and then clicking Job Explorer.
  2. Select your DTM controller from the drop-down box in the upper left of the Job Explorer window.
  3. Expand the nodes in the Feature pane until you locate the node that contains the job that you want to execute.
  4. Right-click the job you want to execute, and then select Schedule.

    Note If the Schedule command is unavailable, you do not have permission to execute jobs within the feature node.

  5. Select your controller from the Automation Controller list in the Schedule Jobs window.
  6. If you want to the job to execute on specific client computers, or client computers within a specific machine pool, use the following procedure to identify the allowable client computers:
    1. On the Machines tab, select the machine pool that contains the client computers that the job can execute on.
    2. If you only want the job to execute on specific client computers within the machine pool, select Restrict Machine Selection to Specific Machines in Machine Pool, and then select the client computers that the job can execute on.

      Note The number of client computers that you select will not affect the number of times that the job executes. If you select two client computers, and the job only requires one client computer, then the job will only execute once on one of the client computers that you selected.

  7. If you want to override the values of parameters in the job, then use the following procedure to provide values for the parameters:
    1. Select the Parameters tab.
      A grid that contains all of the parameters whose values you can override is displayed.

      Note If the parameter whose value you want to override is not displayed, then it is probably unable to be changed when the job is scheduled. To override the value of a local parameter when you schedule a job, you must select the Schedule option when you define the job. To override the value of a global parameter when you schedule a job, you must select the IsScheduleDisplay option when you define the global parameter.

    2. Find the name of the parameter whose value you want to override in the JobName column of the grid.
    3. In the Value column, enter a value for the parameter.
    4. To provide values for additional parameters, repeat this procedure beginning at step b.
  8. If you want the job to execute on client computers that match a set of constraints, use the following procedure to define the constraints:
    1. On the Schedule Constraints tab in the bottom pane of the New Job window, move the cursor to the Dimension cell in the first empty row, and then select the dimension from the drop-down list that you want to compare.
    2. In the Operator column, select the operator that you want to use to compare the dimension to its value. The list of operators might vary depending on the dimension you selected:
      • Equals: The value of the dimension is equal to the value that you specify in the constraint.
      • Not Equals: The value of the dimension is not equal to the value that you specify in the constraint.
      • Less Than: The value of the dimension is less than the value that you specify in the constraint.
      • Greater Than: The value of the dimension is greater than the value that you specify in the constraint.
      • Less Than or Equal To: The value of the dimension is less than or equal to the value that you specify in the constraint.
      • Greater Than or Equal To: The value of the dimension is greater than or equal to the value that you specify in the constraint.
      • Contains: The value of the dimension contains the string that you specify in the constraint.
      • Not Contains: The value of the dimension does not contain the string that you specify in the constraint.
      • Within: The value of the dimension is one of the values that you specify in the constraint.
      • Not Within: The value of the dimension is not one of the values that you specify in the constraint.
      • Exists: The dimension is defined on the client computer.
      • Not Exists: The dimension is not defined on the client computer.
    3. In the Value column, enter the value to compare the dimension to.

      Note If the operator is Within or Not Within, you must select the value from a list. If the operator is Exists or Not Exists, then do not enter a value.

  9. If you want the job to execute on multiple computers that match different sets of constraints, use the following procedure to provide values for the parameters:

    1. Select Add Mix on the Schedule Constraints tab.

      Note You might have to expand the Schedule Job window to see the Add Mix button.

    2. In the Choose Mix Source dialog box, select Local for the Mix Source, select Simple for the Type, and then click OK.
    3. In the New Mix dialog box, type a name for the mix.
    4. In the Contexts tab, click Add.
    5. Type a name for the context in the Add Context dialog box.
      You should use a meaningful name for the context. When you examine the progress of the job by using Job Monitor, the context name for each instance of the job that is executing will be displayed.
    6. On the Constraints tab in the bottom pane of the Add Context dialog box, place the cursor in the Dimension cell in the first empty row and select the dimension that you want to compare from the drop-down list.
    7. In the Operator column, select the operator that you want to use to compare the dimension to its value. The list of operators might vary depending on the dimension you selected.
      • Equals: The value of the dimension is equal to the value that you specify in the constraint.
      • Not Equals: The value of the dimension is not equal to the value that you specify in the constraint.
      • Less Than: The value of the dimension is less than the value that you specify in the constraint.
      • Greater Than: The value of the dimension is greater than the value that you specify in the constraint.
      • Less Than or Equal To: The value of the dimension is less than or equal to the value that you specify in the constraint.
      • Greater Than or Equal To: The value of the dimension is greater than or equal to the value that you specify in the constraint.
      • Contains: The value of the dimension contains the string that you specify in the constraint.
      • Not Contains: The value of the dimension does not contain the string that you specify in the constraint.
      • Within: The value of the dimension is one of the values that you specify in the constraint.
      • Not Within: The value of the dimension is not one of the values that you specify in the constraint.
      • Exists: The dimension is defined on the client computer.
      • Not Exists: The dimension is not defined on the client computer.
    8. In the Value column, enter the value to compare the dimension.

      Note If the operator is Within or Not Within, you must select the value from a list. If the operator is Exists or Not Exists, do not enter a value.

    9. To add additional constraints to the context, repeat this procedure beginning at step f.
    10. If you want to add parameters to the context, select the Parameters tab and use the following procedure to add the parameters:
      1. Enter a name for the parameter in the Name column.
      2. In the Type column, select String.

        Note Parameters can also have the type FileData. A FileData parameter represents a file whose contents you specify in the job. A separate instance of the file is copied to the client computer each time the job is executed. FileData parameters are used primarily to copy a script to a client computer and to reference the script in the task that runs it. For more information about using FileData parameters, see Using FileData Parameters.

      3. Type a description of what this parameter is used for in the Description column.
      4. If you want the user to be able to override the value of this parameter when the job is scheduled, select the ScheduleDisplay check box.
      5. In the Value column, enter the default value for this parameter. If you do not enter a value, the default will be an empty string.

        Tip Parameters can be nested. For example, you could define a parameter named ServerName and give it the value of “MyServer”. You could define a second parameter named DataFileLocation and give it the value “\\[ServerName]\Test”. You could then use DataFIleLocation within a task, for example, by using the command line:
        TestProgram.exe /datafile=[ DataFileLocation]

        When the task was executed, TestProgram.exe would receive a datafile argument with the value “\\MyServer\Test”.

    11. When you have added all of the constraints and parameters to the context, click OK.
    12. To add each additional context, repeat this procedure beginning at step d.
    13. When you have added all of the contexts, click OK in the New Mix dialog box.

  10. To specify the result collection that should contain the job’s results, in the Result Collection section of the Schedule Options tab, either type the name of the result collection or click … to select an existing result collection.
  11. To control when the job executes, use the following procedure to provide the timing information:
    1. Click the Schedule Options tab.
    2. To execute the job immediately, select As soon as Possible as the value of Start trying to schedule this Job.
    3. To execute the job at a specific time, select No sooner Than as the value of Start trying to schedule this Job, and then enter the date and time at which to begin executing the job in the Date field.
    4. If you want DTM to stop trying to find a client computer on which to execute the job after a certain amount of time, enter the number of days, hours, and minutes after which to cancel the job in the Give up trying to schedule after fields.
    5. To automatically cancel the job if it is still executing after a certain amount of time, enter the number of days, hours, and minutes after which to cancel the job in the Time out and cancel any job in this schedule if it runs for more than field. If you don’t want the job to time out, enter 0 days, 0 hours, and 0 minutes.
  12. If you want DTM to automatically execute configuration jobs to satisfy this job’s constraints, select Use Smart Scheduler to dynamically add jobs to satisfy constraints of the Schedule Options tab.
  13. If you want to create an instance of the job to execute, but you want to trigger the job to execute at an arbitrary time in the future, select Manual in the Schedule Behavior section of the Schedule Options tab.

    Note To release a job that has been scheduled as Manual and allow it to execute, right-click the job in Job Monitor and select Trigger Execution.

  14. To execute multiple instances of the job, select Multiplier count, and then enter a value greater than one.
  15. To have the results of this job excluded from the statistics that are displayed in the Result Rollup window, select This is a private run in the Additional Options section of the Schedule Options tab
  16. If you want DTM to send e-mail messages as the job executes, use the following procedure to provide details about the messages and recipients:
    1. Select the Mailing Options tab.
    2. In the Email field, type the e-mail address of the person to receive the e-mail message, for example, someone@example.com.
    3. If you want a second person to receive the e-mail message, type that person’s e-mail address in the CC field, for example someone@example.com.

      Note You can only enter one e-mail address in the Email field and one e-mail address in the CC field.

    4. Select all of the following situations in which you want to receive an e-mail message:
      • Result Collection completed to receive an e-mail message when the job finishes executing.
      • Job completed successfully to receive an e-mail message when all of the tasks in the job have finished running, if the job’s status is Pass.
      • Job completed with Investigate status to receive an e-mail message when all of the tasks in the job have finished running, if the job’s status is not Pass.
      • Infrastructure failure Notification to receive an e-mail message if the job could not be executed.

    Important E-mail notifications will not work until you have configured the account from which the notifications will be sent. A procedure has not yet been provided to do this.


Troubleshooting DTM Problems

This topic includes tips for troubleshooting common DTM problems.

Click to show or hide information. Remote Desktop will not connect to a client computer

Problem: You are unable to use Remote Desktop to connect to a client computer.

Solution: The client computer must be configured to allow a remote connection. Complete the following procedure on the client computer:

To configure a computer to allow a Remote Desktop connection
  1. Click Start, and then click Control Panel.
  2. In Control Panel, double-click Windows Firewall.
  3. Click the Exceptions tab, select the Remote Desktop check box, and then click OK.

Click to show or hide information. Client computers are unable to communicate with the DTM controller

Problem: Client computers are unable to communicate with the DTM controller.

Solution: There are several scenarios in which it might appear that client computers cannot communicate with their controller:

  • Clients do not appear in the Machine List in Job Monitor.
  • Clients fail to connect to the controller.
  • Clients do not process jobs in the job scheduler in DTM Studio.

If it appears that a client computer cannot communicate with the controller, the necessary port might not be not open in the client computer’s software and/or hardware firewall. Check that the Internet Connection Firewall (ICF) port for DTM is enabled on the client and the controller.

To check the ICF port on a client computer that is running Microsoft Windows XP with Service Pack 2 (SP2)
  1. In Control Panel, double-click Windows Firewall. The Windows Firewall dialog box will appear.

    Client Windows Firewall Dialog Box

  2. Click the Exceptions tab, and do one of the following:
    • If WTT Client appears under Programs and Services, ensure that the WTT Client check box is selected.
    • If WTT Client does not appear under Programs and Services, click the Add Port button and do the following in the Add a Port dialog box:
      1. In the Name box, type WTT Client.
      2. In the Port number box, type 1778.
      3. Select the TCP option button.
      4. Click OK.
  3. Under Programs and Services, ensure that the WTT Client check box is selected, and then click OK.

To check the ICF port on a controller that is running Windows XP with SP2:
  1. In Control Panel, double-click Windows Firewall. The Windows Firewall dialog box will appear.

    Windows Firewall

  2. Click the Exceptions tab, and do one of the following:
    • If WTT Controller appears under Programs and Services, ensure that the WTT Controller check box is selected.
    • If WTT Controller does not appear under Programs and Services, click the Add Port button and do the following in the Add a Port dialog box:
      1. In the Name box, type WTT Controller.
      2. In the Port number box, type 1778.
      3. Click the TCP option button.
      4. Click OK.
  3. Under Programs and Services, ensure that the WTT Controller check box is selected, and then click OK.

Click to show or hide information. You are unable to change the value of a parameter when you schedule a job

Problem: You are unable to change the value of a parameter when you schedule a job.

Solution: When you define a parameter—either within the job, for a local parameter, or by using Computer Management for a global parameter—you indicate whether that parameter should be displayed when the job is scheduled. If the ScheduleDisplay check box is not selected for a local parameter, or the IsScheduleDisplay check box is not selected for a global parameter, the parameter will not be displayed in the Schedule Jobs window, so the user will be unable to change its value.

To enable a local parameter to be changed when the job is scheduled, edit the job and select the ScheduleDisplay check box. The procedure for editing a job is similar to the procedure for creating a job. For instructions on creating the parameter within the job, see Using Parameters.

To enable a global parameter to be changed when the job is scheduled, edit the global parameter and select the IsScheduleDisplay check box. The procedure for editing a global parameter is similar to the procedure for creating a global parameter. For information on creating the global parameter, see Defining and Modifying Global Parameters.

Click to show or hide information. A configuration job that is supposed to set a dimension fails

Problem: A configuration job that is supposed to set a dimension fails.

Solution: Although there could be many reasons why a job does not run successfully, a common mistake in a configuration job is to neglect to make the task run in the system context. If you have created a task that uses Wttcmd.exe to set the value of the dimension, make sure that the Run in System Context option is selected on the Execution Options tab of the Add Task Details dialog box for the Wttcmd.exe task.

Click to show or hide information. Configuration jobs do not run

Problem: Configuration jobs do not run.

Solution: Machine pools have an option to allow or forbid configuration jobs to run on computers within the machine pool. Ensure that the machine pool that contains the computer on which you expect the job to run supports configuration jobs.

To determine whether computers in a machine pool can run configuration jobs
  1. Switch to the Job Monitor window.
    You can also open a new Job Monitor window by clicking Explorers, and then clicking Job Monitor.
  2. On the Machine Pool tab, right-click the machine pool that contains the computer or computers that you expect your job to execute on, and then select Properties.
  3. On the General tab of the Properties dialog box, ensure that When scheduling, allow the scheduler to search for config jobs to automatically run on the machines to help them match the constraints of the job is selected.

Click to show or hide information. Your job is stuck in the scheduler

Problem: Your job is stuck in the scheduler.

Solution: When you execute a job, DTM’s scheduler searches for a client computer to run the job. The scheduler considers all client computers in the machine pool that both match the constraints of the job and are available to run jobs.

When you use Job Monitor to view the status of your job, the Current Pipeline column of the Job Execution Status pane displays how far the job’s execution has progressed. If the Current Pipeline value for your job is Scheduler, and if this value has not changed for several minutes, then verify that there is a client computer in the machine pool whose status is Ready. If no client computer is ready to execute jobs, see Enabling a Client Computer to Execute Jobs to set a client computer’s status to Ready.

If a client computer is available to execute the job, confirm that one of the available computers satisfies the job’s constraints. Check the dimensions of the client computers and compare them against the dimensions of the job.

It the job contains Logical Machine Sets (LMSes), confirm that there are enough client computers to meet the requirements of all of the LMSes. DTM schedules all of the client computers simultaneously.

To view the dimensions of a job that is executing, or has executed
  1. Switch to the Job Monitor window.
    You can also open a new Job Monitor window by clicking Explorers, and then clicking Job Monitor.
  2. On the Machine Pool tab, select the machine pool that contains the computer that your job is executing on, or executed on. If your job is still being scheduled, or if you do not know which computer your job is executing on, or executed on, select the root of the machine pool hierarchy ($).
  3. Right-click on your job in the Job Execution Status pane and select View Job Report.
  4. The Job Report window contains information about the job’s execution. Search for the Common Context Details section to see a list of the constraints that a client computer must match to be able to execute the job.

Click to show or hide information. No job delivery agents are listed when you try to create a machine pool

Problem: No job delivery agents are listed when you try to create a machine pool.

Solution: When you create a machine pool, you must associate the new machine pool with your DTM controller by selecting the controller as a job delivery agent. If your DTM controller is not in the System machine pool, then it will not be listed as an option for the job delivery agent.

Use the following procedure to move your DTM controller into the System machine pool, if it is not already a member.

To move your controller to the System pool
  1. Switch to the Job Monitor window.
    You can also open a new Job Monitor window by clicking Explorers, and then clicking Job Monitor.
  2. On the Machine Pool tab, select the System machine pool.
    A list of computers in the system machine pool is displayed in the Machines pane.
  3. If your DTM controller is one of the computers in the System pool, this procedure does not apply.
  4. On the Machine Pool tab, select the dollar sign ($) at the root of the machine pool hierarchy.
    A list of all of the computers in all of the machine pools is displayed in the Machines pane.
  5. Find your computer in the Machines list, and drag it to the System machine pool.

    Tip You can sort the list of computers by clicking Name in the top row of the list in the Machines pane.

Click to show or hide information. Error message: X has encountered an error during installation: A connection to the data store could not be established

Problem: You cannot open any windows from within DTM Studio.

Solution: Users of DTM Studio must be members of the Administrators group on the computer that hosts the DTM controller.

To add a user to the Administrators group
  1. Log on to the computer that hosts the DTM controller using an account that is a member of the Administrators group.
  2. Click Start, and then click Control Panel.
  3. In Control Panel, click User Accounts.
  4. If the user already has an account on the computer, use the following procedure to add the user to the Administrators group:
    1. Select the user from the Users for this computer list, and then click Properties.
    2. On the Group Membership tab of the Properties dialog box, select Other, and then select Administrators from the drop-down list.
    3. Click OK.
  5. If the user does not have an account on the computer, use the following procedure to create an account and add the user to the Administrators group:
    1. Click Add.
    2. In the Add New User dialog box, type the user name and domain for the user you want to add, and then click Next.
    3. Select Other, and then select Administrators from the drop-down list.
    4. Click Finish.
  6. Click OK to close the User Accounts dialog box.

Note Running a computer as an administrator can put your system at risk for security breaches.

Click to show or hide information. Error message: Invalid character has been found in ‘MachinePool.Name’ at character position ‘1’. The character ‘$’ is not allowed in this field. The .NET regular expression used to detect this character is ‘[^\w_-]’.

Problem: You get the following error message when you try to add a user to the root of the machine pool hierarchy: Invalid character has been found in ‘MachinePool.Name’ at character position ‘1’. The character ‘$’ is not allowed in this field. The .NET regular expression used to detect this character is ‘[^\w_-]’.

Solution: You cannot add a user to the root of the machine pool hierarchy. Instead, add the user to a machine pool that is not the root of the machine pool hierarchy.

Click to show or hide information. Error message: Skipped as Public key is null for the machine

Problem: When you try to add a local logical user (LLU) to a client computer, the following message appears: Skipped as Public key is null for the machine.

Solution: The DTM client did not install correctly on the client computer. Complete the following procedure on the client computer:

To uninstall and reinstall the DTM client
  1. Set the client computer’s status to “unsafe”.
    1. Switch to the Job Monitor window, or click Explorers and then click Job Monitor.
    2. Select your DTM controller from the list at the top left of the Job Monitor window.
    3. In the left pane of the Job Monitor window, select the machine pool that contains the client computer.
    4. Right-click on the computer in the Machines pane, point to Change Status, and then click Unsafe.
  2. Uninstall the DTM client.
    1. On the client computer, click Start, and then click Control Panel.
    2. In Control Panel, double-click Add or Remove Programs.
    3. In the Add or Remove Programs window, select Driver Test Manager – Client, and then click Remove.
    4. In the Add or Remove Programs dialog box, click Yes.
  3. Reinstall the DTM client.
  4. Indicate that the client computer is available to run tests.

Click to show or hide information. Error message: No Machine Specified

Problem: You receive a "No Machine Specified" error message after you select a driver during the creation of a new submission.

Solution: When you restart a computer that the DTM Client is installed on, a component of the DTM Client takes a snapshot of all of the device drivers that are loaded on the computer.

If you install or update a device driver after you install the DTM Client but without restarting the computer, the driver information that is available to the DTM Client becomes outdated. Then, when you attempt to use DTM to test a device that uses the newly installed or updated driver, the DTM Client will not be able to locate a computer that has the new driver. The DTM Client then displays an error message ("No Machine Specified") to indicate that the DTM Client could not find the computer.

To make the DTM Client recognize new device driver
  1. Close the "No Machine Specified" error message.
  2. If necessary, save any logs or test-related information.
  3. If necessary, cancel any jobs.
  4. Close the DTM Client.
  5. Restart the computer that the DTM Client is installed on.
  6. Reopen the DTM Client. It will now add the newly installed or updated driver to its list of locally installed drivers.
  7. Restart the submission process.


Using DTM for Logo Testing

To qualify for the “Designed for Microsoft Windows” logo products must pass testing with the Driver Test Manager (DTM). DTM supports the following logo testing scenarios:

  • Testing to obtain a logo for a device
  • Testing to obtain a Driver Quality Signature for a driver
  • Testing to obtain a logo for a system

To obtain a device logo, the device must pass tests that verify the reliability the performance of device.

To obtain a driver quality signature, the driver must meet all the criteria and design requirements defined by Microsoft for drivers running on the Windows family of operating systems.

To obtain a system logo, all devices and drivers in the system must have their respective device logos or driver quality signatures, and the system must pass an additional series of tests.


Logo Testing Overview

The following procedure describes how to use DTM to test for a “Designed for Microsoft Windows” logo:

  1. Configuring the Test Environment
  2. Running the Logo Tests
  3. Submitting Logo Test Results


Configuring the Test Environment

Before your can run the logo tests, a DTM administrator must have performed the steps described in DTM Controller and Client Configuration.

You may also need to configure your test clients in a specific manner, depending on the logo tests you plan to run. For example, if you intend to test a specific device then you must ensure that each client has the device connected to it, and the necessary drivers installed and configured.

To configure your test clients to test for a "Designed for Microsoft Windows" logo, read the "Xxx Testing" topic in the WDK documentation that is appropriate for your device class. For example, to learn how to configure a test environment for an iSCSI HBA device, look in the "Storage Testing" topics in the Device and Driver Technologies section of the WDK documentation.

Note The WDK documentation is not typically installed when you choose to install the WDK Driver Test Manager Controller only. If you did not choose to install the WDK documentation (as part of the WDK build environments), you will need to run the WDK setup again and choose to install the WDK documentation.

After you have configured the testing environment that is appropriate for your device, you can run the logo tests.


Running the Logo Tests

To run the logo tests and create a submission cabinet file to send to WHQL for logo approval perform the following steps:

To run logo tests from a previously saved Device Job Schedule File

  1. Switch to the Device Console window.
    You can also open a new Device Console window by clicking Explorers, and then clicking Device Console.
  2. Select your DTM controller from the drop-down box at the upper left of the Device Console window.
  3. Click the Load button at the bottom of the Device Console window.
  4. Select a Device Job Schedule file that you have previously saved.
  5. Skip ahead to the To select and schedule logo tests procedure.

—or—

To use the Create New Submission wizard to select and run logo tests

  1. Switch to the Device Console window.
    You can also open a new Device Console window by clicking Explorers, and then clicking Device Console.
  2. Select your DTM controller from the drop-down box at the upper left of the Device Console window.
  3. Click the Submission radio button in the View By frame.
  4. Select <New Submission> from the Submission drop-down box near the right-side of the Device Console window, and follow the instructions in the Create New Submission wizard that appears.
  5. Choose the logo test(s) to run:
    1. Select the operating system and processor architecture to test, and then click Next.
    2. Select a submission category, and then click Next.
    3a. If you selected a Device Submission, select a logo program, and then click Next.
    3b. If you selected a System Submission, select a sub-category, and then click Next.
    4. Select a Qualification Level, and then click Next.
    5. Enter a name for the submission, and select the machine pool that contains the machine(s) to use for the submission, and then click Next.
    6a. Depending on the logo test, you may need to select a specific machine from the machine pool on which to run the logo test, and then click Finish.
    6b. Depending on the logo test, you may need to select the drivers that are part of the submission by specifying a device installation file (INF file), and then click Finish.

    Note After you click Finish at the end of Step 6a or 6b, a "No Machine Specified" error message might appear. If this message appears, follow the instructions under "Error message: No Machine Specified" in Troubleshooting DTM Problems.

  6. Optional. Click the Save button to create a Device Job Schedule file that you can load in the future to avoid running the Create Submission Wizard again for the same type of submission you selected.

To select and schedule logo tests

  1. Select the displayed logo tests from the filtered list at the bottom of the Device Console window.
  2. Click the Add Selected button.
  3. Click the Schedule Jobs button.

Monitor logo test progress

  • Observe logo test progress using Job Monitor, and manually intervene if required by test. You can force a refresh of the logo tests status in the Device Console window by pressing F5, or clicking View and then Refresh.
  • Examine the results of a job in the Result Explorer and diagnose the source of any errors. Rerun logo tests if necessary until they pass successfully.

After the logo tests have all passed successfully, you can submit the logo test results to WHQL for approval.


Submitting Logo Test Results

The final step required to obtain a “Designed for Microsoft Windows” logo is to submit your successful logo test results to Microsoft’s Windows Hardware Quality Labs (WHQL).

To create a package and submit your logo test results

  1. Right-click the main node in tree-view of the Device Console window and select Create Submission Package.
  2. Select a location and name for the cabinet file that contains the results of the successful logo tests.
  3. Click OK to save the file.
  4. Go to the [image] WHQL Web site and follow the instructions there to submit your package.

Note You can check on the status of your submission by logging back into the same website.


Scheduling DTM Jobs

In DTM, Scheduler is responsible for finding physical computers in a machine pool that satisfy all the requirements for all the constraints in a given run, while considering the user's permission on the machine pool and computer.

This section includes:

About Scheduler

Using Scheduler

Smart Scheduler


About Scheduler

This section includes:

Scheduler Terminology

Schedule Toolbar Options

Scheduler Prioritizing

Twin Scheduler


Scheduler Terminology

Heartbeat
A message sent from the test client to the controller that validates the condition of the computer.
Job Delivery Agent
The component responsible for the interaction between the test computers and the controller, sometimes also called the Push Daemon. A datastore can have more than one Job Delivery Agent, depending on the load on the datastore.
Run
A group of job instances that can be scheduled as a unit.

See Also

Scheduling DTM Jobs


Schedule Toolbar Options

The following toolbar buttons are available on the Schedule Jobs form:

Open a saved file

Opens an existing file saved for scheduling. You can update the information again and overwrite it.

Save current component to a file
Saves current schedule data, including all settings.

Print the current component data
Prints current schedule data.

Cut
Cuts the selected information or job from its current location within the scheduler.

Copy
Copies the selected information or result from its current location within the scheduler.

Paste
Pastes cut or copied information or results to a selected location within the scheduler.

Create schedule
Creates the new schedule.

See Also

Scheduling DTM Jobs


Scheduler Prioritizing

Scheduler is a backend component in DTM, and is invoked every 10 seconds, attempting to allocate computers for runs that need to be executed.

Scheduler will find the runs that need to be scheduled based on the schedule start time and try to schedule them in the machine pool in which they need to be run. The machine pool in which the jobs need to be run may have individual computers (called free pool computers) and child pools attached to it. Scheduler would considers the following when scheduling a run:

  • Does the user have Execute permissions on the computers or machine pools to be used?
  • Are the computers within a machine pool marked as Reserve machines in this pool as one atomic unit?

Consider the following scenario: Machine Pool MP1 contains computers M1, M2, M3 and sub pool MP2. MP2 in turn contains computers M4, M5, M6, M7 and sub pool MP3. MP3 contains computers M8, M9, M10, M11, M12 and MP3 is marked to reserve only as one atomic unit. This can be seen in the following diagram:

Scheduler will give highest priority to free pool computers within the machine pools. Computers in a machine pool that are reserved as one atomic unit are given the lowest priority.

In this scenario, Scheduler would attempt to schedule the run in the following order:

  1. In the computers of MP1 and MP2 (M1, M2, M3, M4, M5, M6, M7).
  2. In the computers of MP3 (M8, M9, M10, M11, M12).

Scheduler will schedule a run across machine pools/child pools if the machine pool does not have the Reserve machine in this pool as one atomic unit flag set. If this flag is set, then the computers in that machine pool will be reserved exclusively for the run. In this case, Scheduler will either schedule a run among computers M1, M2, M3, M4, M5, M6, M7, or computers M8, M9, M10, M11, M12, but not across both sets.

Additional scheduler considerations

  • Scheduler will schedule runs only on computers that have public key.
  • Scheduler will schedule runs only on computers that have a heartbeat registered in the last 30 minutes.
  • Scheduler will schedule runs only on computers that are in a Ready state and not executing any other run.
  • Scheduler will schedule runs on computers having Is Explicit dimensions only if that dimension is asked for by the run.

See Also

Scheduling DTM Jobs


Twin Scheduler

Twin Scheduler is a backend component within Scheduler that is invoked by Job Delivery Agent. Once a run is executed and Job Delivery Agent returns with the run data, instead of freeing the computers used by the run, Job Delivery Agent will invoke Twin Scheduler. Twin Scheduler will check if any other run having the same constraint(s) is waiting to be scheduled. If it finds any run matching this criteria, it will schedule the run on the same set of computers.

Twin Scheduler considerations

  • Twin scheduling can be done only if the computers still satisfy the run constraints.
  • Twin scheduling can be done only if all the computers are still associated to the same machine pool(s).
  • Twin scheduling can be done only if the machine configurations remain unchanged after executing the previous run.

See Also

Scheduling DTM Jobs


Using Scheduler

DTM Scheduler is used to run a single job or a group of jobs. Scheduler is accessed through Job Explorer, by right-clicking a job (or group of jobs), and then clicking the shortcut menu when you click a job in the Job Explorer (test cases) query list view.

During scheduling, various constraints and options can be applied to selected jobs. Based on these options, DTM Scheduler creates a result, which is a scheduled instance of a job. Each result generated by the Scheduler is associated with specific information, including the computers on which the job will run, parameters being used, and the Result Collection associated with the result.

Note: A controller must be selected prior to scheduling jobs, because DTM Scheduler cannot schedule across multiple controllers.

This section includes:

Creating a Schedule

Adding Constraints to a Schedule

Setting Schedule Options

Setting Mailing Options for a Schedule


Creating a Schedule

As a first step in using Scheduler, you must create a schedule.

To create a schedule

  1. On the Explorers menu, click Job Explorer.
  2. Select your datastore from the Datastore drop-down list.
  3. Select the Feature or Category tab, click the appropriate node and then click the Refresh button.
  4. Right-click the job to schedule, and then click Schedule.

    Note: More than one job may be scheduled at a time by holding down the CTRL - key, and then clicking each job to be scheduled.

  5. On the Machines tab, select a machine pool in which to schedule this job from the drop-down list.

    Note: You must have Execute permissions for a machine pool in order to schedule jobs to it.

    Machine pools set to schedule all computers as an atomic unit are prefixed with *. This means that if a computer from a machine pool with that property is selected, then all computers in that pool are reserved, but the deployment will only be on the selected computers.

  6. To schedule the job only on specific computers within this machine pool, select the Restrict Machine Selection to Specific Machines in Machine Pool check box, and then select the check boxes for the specific computers to use. In the list view select the computers to be scheduled and clear those not to be scheduled.

    Note: The list of client computers originally selected for the schedule is not maintained by DTM. Therefore, if a client is moved out of a machine pool and then later brought back in, the client is identified as a valid client for the schedule only if the Restrict Machine Selection to Specific Machines in Machine Pool option is NOT selected.

  7. On the Jobs Added tab, review the list of mix contexts which are selected. Specific mix contexts may be deselected if any context is not needed.
  8. On the Schedule Options tab, review the options for the Result Collection to group results by, timing, and schedule behavior.

    Note: If you increment the Multiplier count option beyond the default value of 1, this will simply add more instances of the jobs to the schedule. These additional instances will run on any computer possible within the machine pool, including the same computer.

  9. When all options have been set, click the Create Schedule button.

See Also

Using Scheduler


Adding Constraints to a Schedule

Constraints can also be added within a schedule, in addition to any constraints attached to the job when it was created. You can add common contexts and global or custom mixes the same way.

Note: Conflicts can occur between a job’s constraints and those of the schedule if they are contradictory. These conflicts can be viewed by clicking the Conflicts button shown on the Schedule Constraints tab when scheduling a job.

To add constraints to a schedule

  1. When creating a job schedule, select the Schedule Constraints tab.
  2. In the empty cell in the Dimension column, select a dimension for this constraint from the drop-down list.
  3. In the Operator column, select an appropriate operator from the drop-down list.
  4. In the Value column, type a value for the dimension.

    Note: The dimension value may be a single value or a list of values, depending on the selected dimension and operator.

  5. Continue creating the job schedule.

See Also

Using Scheduler


Setting Schedule Options

On the Schedule Options tab you can specify run settings and schedule behavior. You can also select the Result Collection to be associated with the results.

To add options to a schedule

  1. When creating a job schedule, select the Schedule Options tab.
  2. Type a name in the Result Collection box or select a file using the Browse button.
  3. From the Start Trying to Schedule this Job drop-down list, select when the Scheduler should start trying to schedule the job. If you choose No Sooner Than, enter a time and date in the Date box as well.
  4. Enter a time limit for the scheduler in the Give up trying to schedule after boxes.
  5. Enter a time-out limit for the job in the Time out boxes.

    Note: Setting the Time Out to 0:0:0 will set the time out period to be infinite.

  6. Select the Schedule Behavior Settings that fit the needs of your test case:
    • Smart Scheduler – The Smart Scheduler will automatically schedule your job, and will use config jobs to modify your test computer to make it fit the job constraints you have set, if necessary.
    • Normal – The normal Scheduler is set to schedule the job, on the timeframe you specified above.
    • Manual – The job result is created in the Manual pipeline. The job may be manually verified by the user and the result edited accordingly, or the Trigger Execution option in Job Monitor can be used to move the job to the Scheduler pipeline, and the job will be scheduled as normal.

    Additional options:

    • Multiplier Count – Selecting this option schedules the job to run more than once with the same constraints applied to all runs. For each result created in the schedule, copies of the result equal to the multiplier count are generated and then scheduled. This count is primarily designed for stress testing.

      Note: If you increment the number of runs beyond the default value of 1, this will simply add more instances of the jobs to the schedule. These additional instances will run on any computer possible within the machine pool, including the same computer.

    • Private run – Allows a job to be run, but results will be marked as Private so reporting is not skewed.
    • Track failures with Resolver – Use Failure Explorer to track failures.

See Also

Using Scheduler


Setting Mailing Options for a Schedule

With Schedule Mailing Options, users can specify who will be notified about the schedule and what information to include in the message.

To set mailing options for a schedule

  1. When creating a job schedule, select the Mailing Options tab.
  2. In the Email and CC boxes, type the e-mail addresses of the users to whom you want to send the messages.

    Note: The Email setting defaults to the e-mail address of the job creator.

  3. Select the information about the job/test case to send by e-mail.
  4. When you finish scheduling the job, click the Create Schedule button.

See Also

Using Scheduler


Smart Scheduler

In DTM Jobs, testers create jobs to perform a wide variety of common tasks. Some jobs are created to prepare computers to run tests, some are created to cleanup computers after running, some are created to run the tests themselves and some are created to do a combination of the three. These different roles can be classified as setup, cleanup and regular jobs. This distinction is used to help in the organization and the scheduling of jobs.

This approach, however, requires that the correct jobs run in the right order so that the tests may run successfully on a properly prepared computer. Because the setup, regular, and cleanup jobs are not associated with each other, users must use their expert knowledge in order to ensure this. This process is time consuming as well as prone to errors. It also makes sharing tests across teams more difficult.

Additionally, the Smart Scheduler cannot make connections between jobs of different roles and it therefore cannot make optimizations that cut down on the amount of setup and cleanup jobs that get run. For example, two jobs share the same setup and cleanup jobs but run different tests. With an optimized process, these tests could be run one after the other with just one setup and cleanup instead of repeating these steps unnecessarily.

Smart Scheduler addresses such scenarios. Intelligence is built into Smart Scheduler to understand the effect on the dimensions on computers due to running a particular job (known as config jobs). Smart Scheduler understands this information and makes decisions accordingly. If a particular dimension value is required, Smart Scheduler can then try to find a computer that already has that dimension value or to locate a job that produces that dimension value. In the latter case, Smart Scheduler will automatically execute the job on that computer so that the original chosen job is executed. In addition to this, if multiple jobs that require that dimension are queued then the Smart Scheduler can optimize the process by ensuring that the jobs run on the same computer and thus avoid running the same setup job again and again.

The Smart Scheduler uses the config jobs to prepare the computers as per the requirements of the run. The config jobs may be either Set Operations or Delete Operations:

  • Set Operation – A parameter needs to be associated with each dimension. The parameter value passed to the test machine will be the dimension value requested by the job that initiated the setup job. This allows the job itself to dereference the requested value in command lines.
  • Delete Operation – If a dimension is specified, then this job will be run when the dimension needs to be deleted from the computer. This setting is used when for example, after a proprietary application is installed and tests run using it, additional jobs should not be scheduled on that computer until the application has been removed.

See Also

Scheduling DTM Jobs

Using Scheduler

Smart Scheduler Considerations


Smart Scheduler Considerations

  • Smart scheduling is done only if the smart scheduling option is enabled for the given machine pool.
  • Smart scheduling is done only if the smart scheduling is enabled for the schedule.
  • During smart scheduling, preference is given to computer(s) that have been idle for the longest period of time.
  • During smart scheduling, preference is given to computer(s) having Is Explicit dimensions.

See Also

Smart Scheduler


Managing DTM Jobs

This section includes procedures for performing common job-management tasks in DTM:

  • Manual Tasks
  • Using Job Monitor
  • Examining the Result of Executing a Job
  • Deleting a Job


Manual Tasks

Jobs can include manual tasks and automated tasks. Automated tasks are performed in the correct order when you execute a job. If you execute a job that includes a manual task, however, you will be prompted to perform the manual task. The prompt will appear on the client computer that is executing the job.

The following are examples of manual tasks:

  • Inserting a CD
  • Reviewing an image and responding to questions regarding the image
  • Entering a username and password


Using Job Monitor

You can use Job Monitor to manage machine pools and the client computers that they contain and to view the status of jobs and tasks as they execute.

Figure 1 below shows the Job Monitor window after a sample job (test job) has finished executing.

Figure 1: The Job Monitor window

The Job Monitor window includes the following information:

  • Machine Pool tab: A list of machine pools. You can use the machine pool list to create machine pools and move computers into machine pools. You can also give users permission to create jobs within machine pools.

  • Machines pane: A list of the computers that are contained in the machine pool. You can use the Machines pane to view the status of a computer, to modify a computer’s status, and to connect to the remote computer using [image] Remote Desktop.
  • Job Execution Status pane: A list of the jobs that are executing or have completed on the selected computer. You can use the job list in the Job Execution Status pane to view the status of a job.
  • Task Execution Status pane: A list of tasks that are included in the selected job. You can use the Task Execution Status pane task list to view the status of a task within a job.


Monitoring Job Status

The Job Monitor window displays the status of jobs that have been scheduled to execute, as well as the status of tasks within those jobs. When a job has completed, Job Monitor displays the number of tasks within the job that completed successfully, the number of tasks within the job that failed, and the number of tasks within the job that were not executed.

Click to show or hide information. To view the status of a job

  1. Switch to the Job Monitor window.
    You can also open a new Job Monitor window by clicking Explorers, and then clicking Job Monitor.
  2. In the Machine Pool tab of the Job Monitor window, select the machine pool that contains the computer on which the job is executing.
    A list of computers in the machine pool appears in the Machines pane.
  3. In the Machines pane, select the computer on which the job is executing.
    A list of jobs that are executing on the specified computer appears in the Job Execution Status pane.
  4. To view the status of the tasks within the job, in the Job Execution Status pane, select the job whose tasks you want to view.
    A list of tasks within the job appears in the Task Execution Status pane.

Note Job Monitor provides a static display of data. To refresh the data, on the View, menu, click Refresh. You can also refresh the display by pressing the F5 key or by clicking the Refresh icon ( [image]).

Click to show or hide information. To interpret the Job Execution Status pane information

You can review the Job Execution Status pane for information regarding your job.

Figure 2: The Job Execution Status pane of the Job Monitor window

The values in the default columns in the Job Execution Status pane have the following meanings:

  • The first column is unnamed and shows the following icons to indicate the status of the job.
    • : The job is executing.
    • : The job has ended and passed.
    • : The job has ended and failed.
    • : The job has been canceled.
  • Job Name: The name of the job.
  • Job Type: One of the following values:
    • Automated: The job executes automatically.
    • Manual: The job requires manual intervention.
  • Job Context: If a context was specified when the job was created, that value is listed.
  • Scheduled By: The user name of the person who executed the job.
  • Start Time: The date and time the job started executing.
  • Last Updated: The last date and time the job’s status changed.
  • Current Pipeline: One of the following values:
    • Scheduler: The job is being queued to execute.
    • PD: The request to schedule the job is being processed.
    • EA: The job is executing.
    • Manual: The job is executing, but you must perform a manual action on the client computer for the job to proceed.
    • Mail: The job has finished executing, and an e-mail message is being sent to the person who executed the job.
    • Log Result: The job has finished executing, and a log is being written.
    • -: The job has completed.
  • Pass: The number of tasks in the job that have ended with status ”Pass”. This value is not updated until the job has finished executing.
  • Fail: The number of tasks in the job that have ended with status ”Fail”. This value is not updated until the job has finished executing.

    • Note The number of tasks that have passed, failed, and have not been performed might not add up to the total number of tasks in the job. Some tasks are defined, by design, not to roll-up their results into the total number of tasks in the job.


Monitoring Task Status

The Job Monitor window displays the status of jobs that have been scheduled to execute, as well as the status of tasks within those jobs. When a job has completed, Job Monitor displays the number of tasks within the job that completed successfully, the number of tasks within the job that failed, and the number of tasks within the job that were not executed.

Click to show or hide information. To view the status of a task

  1. Switch to the Job Monitor window.

    You can also open a new Job Monitor window by clicking Explorers, and then clicking Job Monitor.
  2. In the Machine Pool tab of the Job Monitor window, select the machine pool that contains the computer on which the job is executing.
    A list of computers in the machine pool appears in the Machines pane.
  3. In the Machines pane, select the computer on which the job is executing.
    A list of jobs that are executing on the specified computer appears in the Job Execution Status pane.
  4. In the Job Execution Status pane, select the job whose tasks you want to view.
    A list of tasks within the job appears in the Task Execution Status pane.

Note Job Monitor provides a static display of data. To refresh the data, on the View menu, click Refresh. You can also refresh the display by pressing the F5 key or by clicking the Refresh icon ( [image]).

Click to show or hide information. To interpret the Task Execution Status pane information

You can review the Task Execution Status pane for information regarding your task.

Figure 3: The Task Execution Status pane of the Job Monitor window

The default columns in the Task Execution Status pane include the following information:

  • The first column is unnamed and shows the following icons to indicate the status of a task:
    • : The task has been created and has not finished executing.
    • : The task has ended and passed.
    • : The task has ended and failed.
    • : The task has been canceled.
  • Task Name: The name of the task.
  • Task Type: One of the following values:
    • Execute: The task runs an executable file.
    • Copy File: The task copies files from a remote location to the computer that is executing the job.
    • Copy Results: The task copies log files from the computer that is executing the job to a remote location.
    • Run Job: The task executes a library job.
    • Manual Prompt: The task is waiting for user input.
  • Task Execution Phase: The phase of the job to which this task belongs. The task execution phase has one of the following values:
    • Setup: A task that is performed during the setup phase. All setup tasks are performed before tasks in other phases.
    • Regular: A task that is performed after setup tasks, but before cleanup tasks.
    • Cleanup: A task that executes during the cleanup phase. Cleanup tasks are performed after all tasks in other phases.
  • Machine: The computer that the task is executing on, executed on, or will execute on.
  • Start Time: Shows one of the following values, depending on the status of the task:
    • If the task is currently being performed, the start time is the date and time that the task started.
    • If the task has not yet been performed, the start time is the date and time that the instance of the task was created.
  • End Time: Shows one of the following values, depending on the status of the task.
    • If the task has ended, the end time is the date and time that the task completed.
    • If the task is being performed, the end time is a dash (“-“).
    • If the task has not started performing, the end time is the same as the start time.
  • Last Updated: The last time the task’s status changed.
  • Exit Status: One of the following values:
    • 0: The task completed successfully.
    • 1: The task completed but returned a failure code.
    • -: The task is still executing.


Monitoring Client Computer Status

The Job Monitor window displays the status of client computers in a machine pool, as well as the status of jobs and their tasks. By using the Machines pane of the Job Monitor window, you can determine whether a computer is available to execute jobs, not able to execute jobs, or currently executing a job.

Click to show or hide information. To view the status of client computers

  1. Switch to the Job Monitor window.

    You can also open a new Job Monitor window by clicking Explorers, and then clicking Job Monitor.
  2. In the Machine Pool tab of the Job Monitor window, select the machine pool that contains the computer.
    A list of computers in the machine pool appears in the Machines pane.
  3. In the Machines pane, select the computer.
    The first column shows the following icons to indicate the status of the job.
    Icon | Status | Can execute jobs? | Notes
    Ready | Yes | The computer is available and ready to execute jobs.
    Executing | No | A job is currently executing on the computer.
    Manual | No | A user put the job into this state by using DTM Studio.
    Debug | No | A job that specifies “FailStopFreeze” has failed, or DTM encountered a problem with the computer.
    Reset | No | DTM is trying to restore the computer to its original state.
    Unsafe | No | The DTM client has been uninstalled from the computer.

Note Job Monitor provides a static display of data. To refresh the data, on the View menu, click Refresh. You can also refresh the display by pressing the F5 key, or by clicking the Refresh icon ( [image]).


Enabling a Client Computer to Execute Jobs

The Machines pane of the Job Monitor window displays the status of client computers in a machine pool. You can also change the status of a client computer from the Machines pane.

You can put a client computer into one of four states:

  1. Manual: Jobs will not be executed on this client computer unless you schedule them manually.
  2. Debug: A job that specifies “FailStopFreeze” executed on this computer and failed, or DTM encountered a problem with the computer.
  3. Reset: DTM is trying to restore the computer to its original state.

    Note When DTM has restored the computer to its original state, the computer’s state is changed from Reset, to Ready.

  4. Unsafe: The DTM client has been uninstalled from the computer.

DTM can also put the client computer into these or other states as the result of executing a job. See Monitoring Client Computer Status for more information about the states that a client computer can be in.

Click to show or hide information. To indicate that a client computer is available to execute jobs

  1. Switch to the Job Monitor window.
    You can also open a new Job Monitor window by clicking Explorers, and then clicking Job Monitor.
  2. In the Machine Pool tab of the Job Monitor window, select the machine pool that contains the computer.
    A list of computers in the machine pool appears in the Machines pane.
  3. In the Machines pane, right-click the computer that you want to be able to execute jobs, select Change Status, and then select Reset.


Examining the Result of Executing a Job

You can use Result Explorer to examine the result of executing a job. A result contains the start time, end time, and completion status of the job’s tasks, any error messages, a link to the job’s log files, and more detailed information. You can examine a job’s result while the job is executing or after it has completed. The following illustration shows an example of the Result Explorer window.

The Result Explorer window

When you execute a job, you can specify a result collection to hold the results of the job. By default, each time you execute a job, a new result collection is created. As the job executes, information about the job is added to a result that is part of the result collection. You can create your own result collections and move results from one collection to another collection. You can also delete or edit results.

Note Although you can edit results, the changes that you make to the result will not affect the information if it is part of the logo submission package.

Four reports and logs are associated with each result that is displayed in the Result Explorer window:

  1. Result report: Detailed information about the execution of the job, including the values of parameters, task completion status, and pointers to any task logs. For more information about result reports, see Reviewing the Result Report.
  2. Job report: Descriptions of the parameters and tasks within the job. For more information about job reports, see Reviewing the Job Report.
  3. Job log: Any log files that were created by the tests that were run as part of the job. For more information about job logs, see Reviewing the Job Log.
  4. Machine configuration log: Detailed information about the dimensions of the computer that the job executed on. For more information about machine configuration logs, see Reviewing the Machine Configuration Logs.

Click to show or hide information. To view the result of running a job

  1. Switch to the Result Explorer window.
    You can also open a new Result Explorer window by clicking Explorers, and then clicking Result Explorer.
  2. Select your DTM controller from the drop-down box in the upper left of the Result Explorer window.
  3. In the Feature tab, select the feature node that contains the jobs whose results you want to examine.
    All instances of jobs within the feature node that are executing or have finished executing are listed in the Results pane.

    Note The jobs that you must execute to qualify for a “Designed for Microsoft Windows” logo are usually in a category that has the same name as the type of device or system that you are testing.

Click to show or hide information. To interpret the Results pane information

The default columns in the Results pane include the following information:

  • The first column is unnamed and shows the following icons to indicate the status of the job that is associated with the result.
    • : The job is executing.
    • : The job has ended and passed.
    • : The job has ended and failed.
  • Result Status: One of the following values:
    • In Progress: The job is executing.
    • Resolved: The user can change the job’s status to “resolved” for any reason.
    • Investigate: The client computer on which the job is executing has entered a debug state, or the job completed and failed.
    • Canceled: The user canceled the job manually, or the job was defined to be canceled if it wasn’t executed within a specified amount of time.
    • Completed: The job finished executing and passed.
  • Job Name: The name of the job.
  • Job Execution Type: One of the following values:
    • Automated: The job executes automatically.
    • Manual: The job requires manual intervention.
  • Assigned To: The user name of the person who created the job.
  • Pass: The number of tasks in the job that have ended with status ”Pass”. This value is not updated until the job has finished executing.
  • Fail: The number of tasks in the job that have ended with status ”Fail”. This value is not updated until the job has finished executing.
  • Not Run: The number of tasks in the job that have not yet completed.


Reviewing the Result Report

The Result Report contains the following detailed information about the execution of a job:

  • Timing information about the job’s execution.
  • The number of tasks that passed, failed, or were not run.
  • For each execution phase:
    • Information about the results of running each task, including:
      • Timing information.
      • Task and process exit status.
      • A link to the task’s logs, if the task produced any logs.
    • The dependencies between the tasks in the phase.
  • The names and values of the job’s parameters.

Click to show or hide information. To View the Result Report

  1. Switch to the Result Explorer window.
    You can also open a new Result Explorer window by clicking Explorers, and then clicking Result Explorer.
  2. Select your DTM controller from the drop-down box in the upper left of the Result Explorer window.
  3. In the Feature tab, select the feature node that contains the jobs whose results you want to examine.
    All instances of jobs within the feature node that are executing, or have finished executing, are listed in the Results pane.
  4. Right-click the job whose result report you want to view, and then select View Result Report.
    The Result Report window is displayed.

    Note There might not be a result report for jobs that failed or are still running.


Reviewing the Job Report

The Job Report contains descriptions of the parameters and tasks within the job itself. That is, a job can execute many times, so there might be multiple instances of a result for the same job. The job report only contains information about the job itself, not information about each instance of the job’s execution.

Click to show or hide information. To View the Job Report

  1. Switch to the Result Explorer window.
    You can also open a new Result Explorer window by clicking Explorers, and then clicking Result Explorer.
  2. Select your DTM controller from the drop-down box in the upper left of the Result Explorer window.
  3. In the Feature tab, select the feature node that contains the jobs whose results you want to examine.
    All instances of jobs within the feature node that are executing, or have finished executing, are listed in the Results pane.
  4. Right-click the job whose job report you want to view and select View Job Report.
    The Job Report window is displayed.


Reviewing the Job Logs

Each time a job is executed, a new directory is created to hold the job’s logs that contain files related to the job’s execution. A Copy Results task copies files to the job’s log directory by default. If a task in the job executes the WttCmd tool, a log is created automatically in the directory. If the job runs an executable that uses the logger API, the log will be created in the directory in a format that can be displayed by DTM.

Click to show or hide information. To View a Job’s Logs

  1. Switch to the Result Explorer window.
    You can also open a new Result Explorer window by clicking Explorers, and then clicking Result Explorer.
  2. Select your DTM controller from the drop-down box in the upper left of the Result Explorer window.
  3. In the Feature tab, select the feature node that contains the jobs whose results you want to examine.
    All instances of jobs within the feature node that are executing, or have finished executing, are listed in the Results pane.
  4. Right-click the job whose logs you want to view and select Browse Job Logs.
    A directory that contains the logs that were created for this job is displayed in a Windows Explorer window.

    Note If the job does not create any logs, the Browse Job Log option will not be available.

  5. Navigate through the directories until you find the log you want to view.
  6. Double-click the log you want to view.


Reviewing the Machine Configuration Logs

The Machine Configuration logs provide detailed information about the dimensions of the computer (or computers) that the job executed on. When a job has finished executing, you can examine the job’s machine configuration logs.

Click to show or hide information. To View the Machine Configuration Logs

  1. Switch to the Result Explorer window.
    You can also open a new Result Explorer window by clicking Explorers, and then clicking Result Explorer.
  2. Select your DTM controller from the drop-down box in the upper left of the Result Explorer window.
  3. In the Feature tab, select the feature node that contains the jobs whose results you want to examine.
    All instances of jobs within the feature node that are executing, or have finished executing, are listed in the Results pane.
  4. Right-click the job whose machine configuration report you want to view, select View Machine Configuration Logs, and then select the client computer whose configuration log you want to view. If the job executed on multiple client computers, multiple client computers will be listed.
    The HW Configuration Log View Report window for the client computer that you selected is displayed.


Canceling a Job

To cancel a job from DTM, complete the following steps. After you cancel a job, the job will still appear in the Job Monitor window, in the Job Execution Status (Filtered) pane. However its status icon will have a red cross through it and the job’s results will also appear in the Result Explorer and Result Collection windows.

If the Job Monitor window is already open then skip to Step 4.

To cancel a job
  1. Switch to the Job Monitor window.

    You can also open a new Job Monitor window by clicking Explorers, and then clicking Job Monitor.

  2. Select your DTM controller from the drop-down box in the upper left of the Job Monitor window.
  3. In the Machine Pool tab of the Job Monitor window, expand the machine pool hierarchy, and then select the machine pool that contains the client computer on which the job is executing.

    If the Job Execution Status (Filtered) pane does not immediately show the job or jobs running on the selected computer, press the F5 function key to refresh the pane.

  4. Determine the status of the job. In other words, make sure the job has not run to completion. If the job's status icon consists of two blue arrows, then the job is still executing.
  5. If the job is still executing then, in the Machines pane, set the status of the client computer to Unsafe or Manual.

    If the job has already run to completion and you would like to delete it then follow the steps for deleting a job.

  6. Right-click the job in the Job Execution Status (Filtered) pane and select Cancel.

    Note: For multiple jobs, you must first select all the relevant jobs by applying the usual combinations of Shift keys, Control keys and mouse clicks.

  7. Click Yes to confirm that you want to cancel the selected job.


Deleting a Job

To delete a job from DTM, complete the following steps. After you delete a job, the job will not appear in Job Monitor, and the job’s results will not appear in Results Explorer.

To delete a job

  1. Determine the status of the job, and then cancel the job if it is still executing.

    Note You can determine if a job is still executing by examining the icon in the first column of the Job Execution Status pane. If the icon consists of two blue arrows ( [image]), then the job is still executing.

    1. Switch to the Job Monitor window.

      You can also open a new Job Monitor window by clicking Explorers, and then clicking Job Monitor.
    2. Select your DTM controller from the drop-down box in the upper left of the Job Monitor window.
    3. In the Machine Pool tab of the Job Monitor window, expand the machine pool hierarchy, and then select the machine pool that contains the client computer that the job executed on or is executing on.
      A list of jobs that are executing on client computers in the machine pool appears in the Job Execution Status pane.
    4. If the job is still executing, right-click the job and select Cancel.

  2. Delete the result collection.
    1. Switch to the Result Collection window.

      You can also open a new Result Collection window by clicking Explorers, and then clicking Result Collection.
    2. In the upper left of the Result Collection window, select your DTM controller from the drop-down box.
    3. In the Result Collection pane, right-click the result collection for your job, and then select Delete.
      Each result collection is named user_computer_ResultCollectiondate where:

      User is the user name of the person who scheduled the job.

      Computer is the name of the client computer on which the job executed.

      Date is the date and time that the job started executing.

    4. Click Yes to confirm that you want to delete the result collection.
  3. Delete the individual results.
    1. Switch to the Result Explorer window.

      You can also open a new Result Explorer window by clicking Explorers, and then clicking Result Explorer.
    2. In the upper left of the Result Explorer window, select your DTM controller from the drop-down box.
    3. In the left pane of the Result Explorer window, on either the Feature or Category tab, locate your job feature or job category that contains your job.
    4. In the Results pane, right-click the results for your job, and then click Delete.
    5. Click Yes to confirm that you want to delete the result.
  4. Delete the job.
    1. Switch to the Job Monitor window.

      You can also open a new Job Monitor window by clicking Explorers, and then clicking Job Monitor.
    2. In the upper left of the Job Monitor window, select your DTM controller from the drop-down box.
    3. In the Machine Pool tab in the left pane of the Job Monitor window, expand the machine pool hierarchy, and then select the machine pool that contains the client computer on which the job executed or is in the process of executing.
      A list of jobs that are executing on client computers in the machine pool appears in the Job Execution Status pane.
    4. Right-click the job that you want to delete in the Job Execution Status pane, and then select Delete.
    5. Click Yes to confirm that you want to delete the job.

      Note The confirmation message will ask if you want to delete the result, not the job. Clicking Yes will delete the job, in addition to any of its job results.


Defining and Viewing Dimensions

A dimension describes a characteristic of a client computer, such as the computer’s processor architecture or the version of the operating system that is installed on the computer. Dimensions are defined on the DTM controller, and then values are given to the dimension on each client computer.

If a dimension and its value are stored in a client computer’s registry, then the value of the dimension will be restored when the client computer restarts.

To set the value of a dimension from the command line, see Appendix A: WttCmd.

Click to show or hide information. To view the dimensions that are defined on the DTM controller

  1. Switch to the Management Console window.
    You can also open a new Management Console window by clicking Tools, and then clicking Management Console.
  2. In the left pane of the Management Console window, expand Enterprises, expand your DTM controller, expand Datastores, expand your DTM controller again, and then select Dimensions.

    A list of the dimensions that are defined on the controller is displayed in the right pane.

Click to show or hide information. To define a new dimension on the DTM controller

  1. Switch to the Management Console window.
    You can also open a new Management Console window by clicking Tools, and then clicking Management Console.
  2. In the left pane of the Management Console window, expand Enterprises, expand your DTM controller, expand Datastores, expand your DTM controller again, right-click Dimensions, and then select New Dimension.
  3. In the Add Dimension dialog box, select the type of dimension that you are defining, and then click Next. The type of the dimension can be:
    • String: The value of this dimension will be a string of fifty or fewer characters.
    • Numeric: The value of this dimension will be a number.
    • List: The value of this dimension will be one of a set of predefined strings.
    • Machine Configuration Query: The value of this dimension will be populated automatically by a gatherer each time the client computer restarts. Machine configuration queries are used in advanced situations and are not yet described in this procedure.
  4. Type a name for the dimension.
  5. Select Is Explicit if you want DTM to schedule only jobs that require this dimension on a client computer that has this dimension defined.
  6. If you are defining a string or numeric dimension, click Finish.
  7. If you are defining a list dimension, click Next, enter one of the valid values for the dimension, and then click Add. Continue entering values and clicking Add until you have entered the last valid value for the dimension, and then click Finish.

Click to show or hide information. To view the values of dimensions on a client computer

  1. Switch to the Job Monitor window.
    You can also open a new Job Monitor window by clicking Explorers, and then clicking Job Monitor.
  2. In the Machine Pool tab of the Job Monitor window, select the machine pool that contains the computer whose dimensions you want to view.
    A list of computers in the machine pool appears in the Machines pane.
  3. Double-click the computer whose dimensions you want to view.
  4. Select the Machine Details tab.
    Every dimension that is defined for this client computer is listed in the Dimension column. The value of each dimension is presented in the corresponding entry in the Value column.

Click to show or hide information. To provide a value for a dimension on a client computer

  1. Switch to the Job Monitor window.
    You can also open a new Job Monitor window by clicking Explorers, and then clicking Job Monitor.
  2. In the Machine Pool tab of the Job Monitor window, select the machine pool that contains the computer whose dimensions you want to edit.
    A list of computers in the machine pool appears in the Machines pane.
  3. Right-click the computer whose dimension you want to edit, and then select Edit.
  4. Select the Machine Dimensions tab.
  5. Double-click the cell in the Dimension column of the first empty row. An arrow will appear to the right of the cell.
    A list of all of the dimensions that are defined on the DTM controller is displayed.
  6. Select the name of the dimension that you want to define, and then press the TAB key to move the cursor to the Value column.
  7. If this is a string or numeric dimension, type the value for the dimension in the Value cell.
  8. If this is a list dimension, click the arrow at the end of the Value cell, and then select the value for the dimension from the list.
  9. Click Save ( [image]) to save the dimension and its value.


Defining and Modifying Global Parameters

A parameter is a variable that provides information to a task within a job. Global parameters are defined on the DTM controller and can be used by any job.

For more information about parameters, see Using Parameters.

Click to show or hide information. To create a new global parameter

  1. Switch to the Management Console window.
    You can also open a new Management Console window by clicking Tools, and then clicking Management Console.
  2. In the left pane of the Management Console window, expand Enterprises, expand your DTM controller, expand Datastores, expand your DTM controller again, right-click Global Parameters, and then select New Global Parameter.
  3. In the Add Parameter dialog box, type a name for the global parameter.
  4. To provide a default value for the global parameter, enter the value in the Value field.
  5. Type a description of what the global parameter represents in the Description field.
  6. If you want the user to be able to override the value of this parameter when the job is scheduled, select the IsScheduleDisplay check box.
  7. Click OK.

Click to show or hide information. To modify the value of a global parameter

You can modify the value of a global parameter in two different ways. First, you can provide a new default value that will be used in all jobs that use the global parameter. Second, if you selected IsScheduleDisplay when you defined the global parameter, then you can override the value of the global parameter when you schedule a job, and the new value will be used only during the current execution of the job.

This procedure describes how to modify the default value of a global parameter. To override the value of a global parameter when you schedule a job to execute, see Executing a Job.

  1. Switch to the Management Console window.
    You can also open a new Management Console window by clicking Tools, and then clicking Management Console.
  2. In the left pane of the Management Console window, expand Enterprises, expand your DTM controller, expand Datastores, expand your DTM controller again, and then select Global Parameters.
    A list of all of the global parameters that are defined on the DTM controller is displayed in the right pane.
  3. In the right pane, double-click the global parameter whose default value you want to change.
  4. In the Value field of the Edit Parameter dialog box, enter the new default value for the global parameter, and then click OK.


Using FileData Parameters

A FileData parameter represents a file whose contents you specify in the job. A separate instance of the file is copied to the client computer each time the job is executed. FileData parameters are used primarily to copy a script to a client computer and to reference the script in the task that runs it.

FileData parameters are rarely used.


Logging in DTM

DTM Logger is an XML-based logging tool for the Driver Test Manager (DTM). It is designed around a publisher-subscriber model—also known as a producer-consumer model—in which output is made available to all interested parties and can be retrieved at their convenience. This enables asynchronous interaction with log data. DTM Logger can send output to multiple interfaces simultaneously, such as to a file, the console, and a debugger. You can also extend DTM Logger to accommodate your needs, such as outputting to an encrypted log file.

Changes in WTT 2.1

The rollup information in the DTM Studio reported by the job or task now includes the out of context error, blocked, warned, and skipped traces.

Topics in this section

Introduction to DTM Logger

Getting Started

Sample Code

Logger Troubleshooting

Logger Reference


Introduction to DTM Logger

For a description of DTM Logger's features and its integration with DTM, see the following topics:

Summary of Logging Functions

Programming Support

Using Error Lists

Integration with DTM Jobs


Summary of Logging Functions

The functionality of DTM Logger can be loosely divided into the following categories:

  • Topology configuration – Manages how log devices connect and controls how they are organized. This allows you to pass a configuration string to a log device to describe a desired topology for a test run.

  • Test case management – Manages all test cases in a test run. This includes the following:
    • Marking the start and end of each test case
    • Creating and closing the test context
    • Setting up auto-logging by setting test case-specific and test computer-specific information
    • Generating the pass-fail results for the test case

  • Program flow control – Checks and handles test errors in a consistent way. This makes it possible to triage test failures automatically.

  • Tracing – Creates and logs trace messages and converts them to XML.


Programming Support

DTM Logger offers native support for C/C++, COM, and .NET. If you will be using ether C++ or COM, you can access the logging engine through a top-level object interface—the CWTTLogger class for C++, and the IWTTLog interface for COM. If you will be using C, you can access the logging engine using the WTTLog functions. For .NET, DTM Logger offers classes in the Microsoft.Wtt.Log namespace.


Using Error Lists

DTM Logger has built-in support for error checking. This is very useful when dealing with expected errors in your application, which are errors that are intentional or desired. You can use expected errors to show that a testing configuration gives negative results when it should, as when an access restriction prevents an unauthorized user from completing a test.

While expected errors are valuable for verifying an intended behavior, they are not a basis for causing a test to fail. Therefore, DTM Logger uses error lists to encapsulate the details of error checking, and to determine which error codes are expected and should not cause the test to fail. DTM Logger makes the following error lists available:

  • List of expected errors
  • List of break-on errors

An error list is a collection of errors that have both a value and a type. If the error being checked matches any error in the expected error list for both value and type, then the error is considered a valid error and does not cause the test to fail. If the error being checked matches any error in the break-on error list for both value and type, then DTM Logger will try to break into the debugger on behalf of the application.

S_OK error code

DTM Logger treats the S_OK error code different than other error codes. If the error list is empty, Logger considers S_OK a valid error. However, if the list is not empty and S_OK is not in the error lists, Logger considers S_OK a failure.

For more information on how to use error lists, see the following topics:

Maintaining Error Lists Checking the Test Results

Note: If you do not want to deal with error lists, call the CheckResultEx function instead of the CheckResult function.

See Also

Getting Started, Error List Sample Using C++


Maintaining Error Lists

You can add an error to either list, remove an error from either list, or clear all errors of a specific type from either list. The error lists have a global scope on a per-logger-object basis. Therefore, if one thread adds an error to the list, other threads that share the same logger object will be affected.

  • To maintain an error list using C
    • Add an error to the list by calling the WTTLogAddErrorToErrorList function.
    • Remove an error from the list by calling the WTTLogRemoveErrorFromErrorList function.
    • Clear all errors of a specified type from the list by calling the WTTLogClearErrorList function.

  • To maintain an error list using C++
    • Add an error to the list by calling the CWTTLogger::AddErrorToErrorList method.
    • Remove an error from the list by calling the CWTTLogger::RemoveErrorFromErrorList method.
    • Clear all errors of a specified type from the list by calling the CWTTLogger::ClearErrorList method

  • To maintain an error list using COM
    • Add an error to the list by calling the IWTTLog::AddErrorToErrorList method.
    • Remove an error from the list by calling the IWTTLog::RemoveErrorFromErrorList method.
    • Clear all errors of a specified type from the list by calling the IWTTLog::ClearErrorList method.

  • To maintain an error list using .NET
    • Add an error to the list by calling the ErrorList.Add method.
    • Remove an error from the list by calling the ErrorList.Remove method.
    • Clear all errors of a specified type from the list by calling the ErrorList.Clear method.


Checking the Test Results

After a test run, you can check the results against either list of errors to determine if the test passed or failed. The error type and error code of the result are compared with the errors on the list. If the error is on the list, the test passes. If the error is not on the list, the test fails.

  • To check test results using C
    • Call the WTTLogCheckResult function or the WTTLogCheckResultEx function.

  • To check test results using C++
    • Call the CWTTLogger::CheckResult method or the CWTTLogger::CheckResultEx method.

  • To check test results using COM
    • Call the IWTTLog::CheckResult method or the IWTTLog::CheckResultEx method.

  • To check test results using .NET
    • Call the WTTLogger.CheckResult method.


Integration with DTM Jobs

Test software executed by a DTM job's tasks may use DTM Logger as the logging service to record information and results of executing the test software. Two log files result from the creation of a DTM Logger instance:

  • The test software's log file. For an example file, see TraceAll.wtl.
  • A pass-fail rollup log file. For an example file, see TaskGUID.xml.

If the Task's Execution Option "Task Failure Conditions" is set to "Declare task failure based on results from log," DTM will determine the pass/fail status for the task based on the contents of the pass-fail rollup log file created by DTM Logger.

The pass-fail rollup file is created when the DTM Logger object is closed by the test software (Logger.CloseLogDevice(NULL, hDevice)). The rollup file is stored in a file named <Taskguid>.xml and is copied to the DTM Controller's log file share.

Test software may be implemented in such a way that out-of-context errors can occur. In addition, test software may call for OS reboots during the execution of the test. In the case where the task executes once (no reboot) and the test software does NOT record out-of-context errors, the pass-fail rollup file will be similar to the following:

<TaskResult Total="1" Pass="1" Failed="0" Blocked="0" Warned="0" Skipped="0"
            StartTime="2/11/2005 1:6:7" EndTime="2/11/2005 1:6:7">
    <LogFileList>
        <File Name=" TraceAll.wtl" />
    </LogFileList>
</TaskResult>

The attributes of the TaskResult element contain the values passed to the EndTest method.

When a task executes once, without a reboot, and the test software records out-of-context errors, the resulting pass-fail rollup file will look similar to the following:

<TaskResult Total="1" Pass="1" Failed="0" Blocked="0" Warned="0" Skipped="0"
            StartTime="2/11/2005 1:6:7" EndTime="2/11/2005 1:6:7">
    <LogFileList>
        <File Name=" TraceAll.wtl" />
    </LogFileList>
    <AdditionalResultList>
        <AdditionalResult Total="6" Pass="0" Failed="3" Blocked="2" Warned="1" Skipped="0"
                          StartTime="2/11/2005 1:6:7" EndTime="2/11/2005 1:6:7" />
    </AdditionalResultList>
</TaskResult>

The AdditionalResults element represents each of the calls to the Trace method with an error of some kind.

Note: This is an added feature for WTT 2.1 and later. WTT 2.0 did not provide the ability to log out-of-context errors.

If the test software calls for a reboot and the task is configured to re-run after the reboot, other AdditionalResult elements will be added to the pass-fail rollup file, one for the out-of-context errors and one that calls the EndTest method. The log file would look similar to the following:

<TaskResult Total="1" Pass="1" Failed="0" Blocked="0" Warned="0" Skipped="0"
            StartTime="2/11/2005 1:6:7" EndTime="2/11/2005 1:6:7">
    <LogFileList><File Name=" TraceAll.wtl" /></LogFileList>
    <AdditionalResultList>
        <AdditionalResult Total="6" Pass="0" Failed="3" Blocked="2" Warned="1" Skipped="0"
                          StartTime="2/11/2005 1:6:7" EndTime="2/11/2005 1:6:7" />
        <AdditionalResult Total="1" Pass="1" Failed="0" Blocked="0" Warned="0" Skipped="0"
                          StartTime="2/11/2005 2:6:7" EndTime="2/11/2005 2:6:7" />
        <AdditionalResult Total="6" Pass="0" Failed="3" Blocked="2" Warned="1" Skipped="0"
                          StartTime="2/11/2005 2:6:7" EndTime="2/11/2005 2:6:7" />
    </AdditionalResultList>
</TaskResult>

Note: This is an added feature for WTT 2.1 and later. WTT 2.0 only reported the results for the last iteration of a Task that performed a reboot.

The DTM backend performs two operations on the information provided in the pass-fail rollup file:

  • Map "Blocked" to "Not Run" and "Skipped" to "Not Applicable"
  • Does a Sum of the Pass, Failed, Not Run and Not Applicable attributes of the TaskResult and AdditionalResult elements. Note that the "Warned" attribute is NOT used by DTM.

See Also

Getting Started


TraceAll.wtl

Example test software log file:

<?xml version="1.0" ?>
<WTT-Logger>
<RTI ID="2925006503" Machine="DEVMACHINE" ProcessName="TraceAll.exe" ProcessID="3376"
     ThreadID="3332" BaseTime="2005:2:11 1:6:7:757" Frequency="3579545" />
<CTX ID="384048256" Current="WTTLOG" Parent="ROOT" />
<Machine
        Build="2600.00"
        Platform="x86"
        OS="Microsoft Windows XP"
        ServicePack="Service Pack 2"
        Version="5.1"
        BuildLab="xpsp_sp2_rtm"
        BuildDate="040803-2158"
        Language="English (US) (REDMOND)"
        Config="n/a" CA="1214554" LA="1215986" >
        <rti id="2925006503" />
        <ctx id="384048256" />
</Machine>
<Msg
        UserText="This is a message" CA="1218459" LA="1264742" >
        <rti id="2925006503" />
        <ctx id="384048256" />
</Msg>
<Msg
        UserText="This is a message with parameter 1234 string" CA="1218611" LA="1266841" >
        <rti id="2925006503" />
        <ctx id="384048256" />
</Msg>
<Msg
        UserText="This is a message with user XML" CA="1218721" LA="1268051" >
        <Data>
            <MyXML>DTM Logger trace all unit test</MyXML>
        </Data>
        <rti id="2925006503" />
        <ctx id="384048256" />
</Msg>
<Msg
        UserText="This is a message with user XML and parameter 1234 string" CA="1218842" LA="1320897" >
        <Data>
            <MyXML>DTM Logger trace all unit test</MyXML>
        </Data>
        <rti id="2925006503" />
        <ctx id="384048256" />
</Msg>
<Error
        File="e:\21\sdktools\wtt\jobs\sdk\logger\unittest\cpp\traceall\main.cxx"
        Line="125"
        ErrCode="0x2"
        ErrType="HRESULT"
        ErrorText="The system cannot find the file specified."
        UserText="This is a Win32 error" CA="1218971" LA="1354358" >
        <rti id="2925006503" />
        <ctx id="384048256" />
</Error>
<Error
        File="e:\21\sdktools\wtt\jobs\sdk\logger\unittest\cpp\traceall\main.cxx"
        Line="136"
        ErrCode="0x0"
        ErrType="BOOL"
        ErrorText="Error 0x00000000"
        UserText="This is a boolean error" CA="1219322" LA="1355913" >
        <rti id="2925006503" />
        <ctx id="384048256" />
</Error>
<Error
        File="e:\21\sdktools\wtt\jobs\sdk\logger\unittest\cpp\traceall\main.cxx"
        Line="147"
        ErrCode="0x1"
        ErrType="NT_STATUS"
        ErrorText="Error 0x00000001"
        UserText="This is a NT_STATUS error" CA="1219467" LA="1432323" >
        <rti id="2925006503" />
        <ctx id="384048256" />
</Error>
<Assert
        File="e:\21\sdktools\wtt\jobs\sdk\logger\unittest\cpp\traceall\main.cxx"
        Line="160"
        UserText="This is an assert" CA="1220942" LA="1434368" >
        <rti id="2925006503" />
        <ctx id="384048256" />
</Assert>
<Warn
        File="e:\21\sdktools\wtt\jobs\sdk\logger\unittest\cpp\traceall\main.cxx"
        Line="173"
        UserText="This is a warning" CA="1221069" LA="1488933" >
        <rti id="2925006503" />
        <ctx id="384048256" />
</Warn>
<Bug
        DB="WTT"
        ID="12345"
        Type="Non-Blocking" CA="1221199" LA="1490651" >
        <rti id="2925006503" />
        <ctx id="384048256" />
</Bug>
<Bug
        DB="WTT"
        ID="12345"
        Type="Blocking" CA="1221247" LA="1544909" >
        <rti id="2925006503" />
        <ctx id="384048256" />
</Bug>
<CTX ID="1505448945" Current="9b18233d-10c4-4491-ae70-1f89b00402a0" Parent="WTTLOG" />
<StartTest
        Title="StartTestEx and EndTestExDemo"
        TUID="9b18233d-10c4-4491-ae70-1f89b00402a0" CA="1221484" LA="1546563" >
        <rti id="2925006503" />
        <ctx id="1505448945" />
</StartTest>
<EndTest
        Title="StartTestEx and EndTestExDemo"
        TUID="9b18233d-10c4-4491-ae70-1f89b00402a0"
        Result="Pass"
        Repro="C:\Testing\AlexDu\TraceAll.exe " CA="1221641" LA="1548422" >
        <rti id="2925006503" />
        <ctx id="1505448945" />
</EndTest>
<PFRollup
        Total="1"
        Passed="1"
        Failed="0"
        Blocked="0"
        Warned="0"
        Skipped="0" CA="1221728" LA="1599782" >
        <rti id="2925006503" />
        <ctx id="384048256" />
</PFRollup>
</WTT-Logger>


TaskGUID.xml

Example pass-fail rollup file:

<TaskResult Total="1" Pass="1" Failed="0" Blocked="0" Warned="0" Skipped="0"
            StartTime="2/11/2005 1:6:7" EndTime="2/11/2005 1:6:7">
    <LogFileList>
        <File Name=" TraceAll.wtl" />
    </LogFileList>
    <AdditionalResultList>
        <AdditionalResult Total="6" Pass="0" Failed="3" Blocked="2" Warned="1" Skipped="0"
                          StartTime="2/11/2005 1:6:7" EndTime="2/11/2005 1:6:7" />
    </AdditionalResultList>
</TaskResult>


Getting Started

Whether your tests are coded in C, C++, COM, or .NET, the basic process of using DTM Logger in your code is essentially the same. To add logging to your test program, include these elements:

  • Initialize logging by creating a log device, which sets up your desired outputs. For more information about creating a log device, see Initializing a log device.
  • Manage test cases by marking the start and end of each test case in your code. A test case is a set of traces grouped by a defined context. For more information about managing your test cases, see Managing a test case.
  • Trace application errors during the test run by adding traces to your test cases. For more information about performing a trace, see Performing a trace.
  • Clean up after the test run.
  • Post-process the log files using XML transformation templates. For more information about post-processing log files, see Post-processing log files.

Logging engine

There are three versions of the logging engine:

  • WttLog.dll for C/C++. This DLL has minimal dependencies.
  • WttLogCM.dll for COM and scripting.
  • Microsoft.DistributedAutomation.log.dll for .NET.

If you want to statically link to the target DLL during compilation, use the library files WttLog.lib for C/C++.

Scripting the Logger

If you want to access the logging engine through a script, you must do the following:

  1. Register the COM version of the logging engine (WttLogCM.dll).
  2. Use the WttLogger object as you would use any ActiveX object.

Topics in this section

Initializing a log device

Managing a test case

Performing a trace

Post-processing log files

See Also

Logging in DTM, Logger Reference


Initializing a Log Device

This topic shows how to initialize a log device and set up your desired logging output. Initializing a log device requires that you create a device string that defines the logging output. For information about creating a device string, see Device string.

To initialize a log device using C

Call the WTTLogCreateLogDevice function and pass it a device string and the handle to the log device.

To initialize a log device using C++

  1. Instantiate a CWTTLogger object.
  2. Call the CWTTLogger::CreateLogDevice method and pass it a device string and the handle to the log device.

To initialize a log device using COM

  1. Instantiate a WTTLogger object.
  2. Call the IWTTLog::CreateLogDevice method and pass it a device string and the handle to the log device.

To initialize a log device using .NET

  1. Use the Microsoft.WTT.Log namespace.
  2. Create a new WTTLogger object and pass it a device string.

Topics in this section

Device String

Log Device Types

See Also

Getting Started, Sample Code


Device String

A device string is made up of parameters that describe how log devices are configured for a test, thus defining the log device topology. The string is passed to the CreateLogDevice function when the user application first starts.

Device string syntax

A device string has three parts—device type, parameter list, and topology configuration. These parts are shown below in the device string syntax.

    $<device_type>:<parameter_list>($<child_device1>[; $<child_device2>; ...])

For information about device types, see Log Device Types.

Example of a device string

Suppose we want to create a device string that describes a topology in which a local publisher has three subscribers—a log file, a console, and a debugger. We do not need to include the device type or parameter list for a local publisher because the device string is added automatically. Therefore, the resulting device string, which is shown below, only contains the child devices.

    $logfile:file=log.xml,encoding=UNICODE;$console;$debugger

The following example demonstrates a typical call to the CreateLogDevice function.

    hr = CWTTLogger::CreateLogDevice(L"$logfile:file=log.xml,encoding=UNICODE;$console;$debugger", &hDevice);

The call returns a handle so that your application can refer to this configuration later.

Distributed topologies

To test a client-server configuration, you will need two device strings—describing the server-side topology and the client-side topology. The following list shows examples of the two device strings.

  • Server-side: $logfile;$netsub:port=2204
  • Client-side: $netpub:server=myserver,port=2204

These strings enable the client application to send its traces to the server application via TCP/IP on port 2204.

Setting device strings outside an application

There may be times when you want to change the topology for a test. For example, you may want a test to look different when it's being written than when it's being run. You can allow for topology changes by passing a null device string to the CreateLogDevice funtion. This enables the device string to be overridden, in order of precedence, from the command line, an environment variable, or the registry.

  • From the command line, you can set the device string by adding a WTTLogDevStr argument to the launch command. For a topology with a local publisher, a log file, and a console, the argument would appear as follows:

        /WTTLogDevStr:$LogFile;$Console

  • You can create an environmental variable named WTTLogDevStr and set it to the device string.
  • Your application can set the device string in the registry. Use the following registry location:

    Use a key that is of type string, named WTTLogDevStr and with its value set to the device string.

    You can also create other keys at this registry location to store predefined device strings. You could then pass WTTLogDevStrPredefine:somepredefinedname to a function in place of the device string. Logger will look up somepredefinedname in the registry to get the device string.

See Also

Initializing a log device, Log Device Types.


Log Device Types

The DTM Logger defines a log device as an object that can process a trace from a test job. Logger supports the following device types for use in device strings:

  • $LocalPub – local publisher
  • $LogFile – XML log file
  • $PlainLog – plain text log file
  • $Console – computer display
  • $Debugger – debug console
  • $NetPub – network publisher that sends traces
  • $NetSub – network publisher that receives traces
  • $Tactics – tactics database logger

Each device type has a number of options that you can specify when you set up the device. Some options are common to all device types. All device options are described in the following sections:

  • Common Options
  • $LocalPub Options
  • $LogFile Options
  • $PlainLog Options
  • $Console options
  • $Debugger Options
  • $NetPub Options
  • $NetSub Options
  • $Tactics Options

See Also

Initializing a log device, Device string


Common Options

The following table shows the options that are common to all devices types.

Option | Syntax | Description
TraceLvl | TraceLvl=sometracelevel | Trace level (in hexadecimal) to which this device will respond. By default, it will trace everything (0xFFFFFFFF).
TracePri | TracePri=sometracepriority | Trace priority (in hexadecimal) to which this device will respond. By default, it will trace everything (0xFFFF0000).
EnableLvl | EnableLvl=somelvl|someotherlvl | Trace levels that the user application wants to enable. Each level is a string with levels separated by “|”. For example, EnableLvl=Msg|Error will enable the message and error levels. It also applies to user-defined levels. If a level is specified in both EnableLvl and DisableLvl options, the EnableLvl has higher precedence. User defined levels must be enabled in order for them to be traced in the log. Otherwise, they will not be output.
DisableLvl | DisableLvl=somelvl|someotherlvl | Trace levels that the user application wants to disable. Each level is a string with levels separated by “|”. For example, DisableLvl=Msg|Error will disable the message and error levels. It also applies to user-defined levels. If a level is specified in both EnableLvl and DisableLvl options, the EnableLvl has higher precedence.


$LocalPub Options

You will normally not need to specify the $LocalPub device; it is created automatically by the Logger. However, the following table shows the available options.

Option | Syntax | Description
IfError | IfError=[true|false] | Logs traces in the log device only if the test fails. Default = false This option can reduce the size of the log file. For passing tests, it just logs StartTest and EndTest.
QSize | QSize=some integer value | Internal queue size. Default = 50 If this is set to 0, Logger will not buffer any trace message internally.
WTTLogAssertMode | WTTLogAssertMode=[true|false] | Specifies whether Logger is in assert mode. Default = false
WTTLogAssertDLL | WTTLogAssertDLL=[path to DLL] | Directory path to DLL.
WTTLogPFMode | WTTLogPFMode=[auto|user] | Specifies whether Logger will validate pass-fail results. Auto means yes, and user means no. Default = auto This option is equivalent to the /WTTLogPFMode:auto|user global flag.


$LogFile Options

The following table shows the options for the $LogFile device type.

Option | Syntax | Description
file | file=somefilename | File name. By default, this will be the name of the EXE file with .WTL extension. If you want to specify the full path name, you need to escape the file name with double-quote. For example: file="c:\temp\myxmllog.xml"
Maxsize | Maxsize=someinteger | Maximum file size in bytes. If Writemode does not equal overwrite, Maxsize is ignored.
encoding | encoding=[ANSI|UNICODE] | Encoding scheme of the file. Default = ANSI
InRollup | InRollup=[true|false] | Specifies whether the file will be added to the list of log files in DTM EA/Logger rollup file. Default = false
Shared | Shared=[true|false] | Specifies whether the log file is shared between more than one process. This option introduces a minor performance degradation. The log file is always open/created with shared access level in the OS. Default = false
Compressed | Compressed=[true|false] | Specifies whether the log file is compressed. Default = true if the file is created on an NTFS volume.
Encrypted | Encrypted=[true|false] | Specifies whether the log file needs to be encrypted. Default = false
CRC | CRC=[true|false] | Specifies whether the log file needs to be CRC’d at the end. Default = false
Writemode | Writemode=[overwrite|append] | How the log file should be opened. Default = append
Nofscache | Nofscache=[true|false] | Specifies whether the file system cache needs to be turned off. Default = false Warning: if this option is specified, logging will become extremely slow.
XSLT | XSLT=some_XSLT_file_name | XSLT file that will be used as an XML style sheet for this log file. Default = null This option adds an xml-stylesheet element to the log file.


$PlainLog Options

The following table shows the options for the $PlainLob device type.

Option | Syntax | Description
file | file=somefilename | File name. By default, this will be the name of the EXE file with .LOG extension. If you want to specify the full path name, you need to escape the file name with double-quote. For example: file="c:\temp\myxmllog.log"
Maxsize | Maxsize=someinteger | Maximum file size in bytes. If Writemode does not equal overwrite, Maxsize is ignored.
encoding | encoding=[ANSI|UNICODE] | Encoding scheme of the file. Default = ANSI
Shared | Shared=[true|false] | Specifies whether the log file is shared between more than one process. This option introduces a minor performance degradation. The log file is always open/created with shared access level in the OS. Default = false
Compressed | Compressed=[true|false] | Specifies whether the log file is compressed. Default = true if the file is created on an NTFS volume.
Encrypted | Encrypted=[true|false] | Specifies whether the log file needs to be encrypted. Default = false
CRC | CRC=[true|false] | Specifies whether the log file needs to be CRC’d at the end. Default = false
Writemode | Writemode=[overwrite|append] | How the log file should be opened. Default = append
Nofscache | Nofscache=[true|false] | Specifies whether the file system cache needs to be turned off. Default = false Warning: if this option is specified, logging will become extremely slow.
Verbose | Verbose=[true|false] | Specifies whether to turn on the verbose mode. If so, the PID and GMT timestamps will be added to every trace message.


$Console options

For the $Console device type, only the common options can be specified.


$Debugger Options

For the $Debugger device type, only the common options can be specified.


$NetPub Options

Option | Syntax | Description
server | server=servername | Name of the remote server. This must be set for the device to work properly.
port | port=portnumber | Port number of the remote server. Default = 2204


$NetSub Options

Option | Syntax | Description
port | port=portnumber | Port number of the remote server. Default = 2204


$Tactics Options

Option | Syntax | Description
logmode | logmode=[offline|realtime] | Specifies whether to log to the Tactics database in realtime. Default = offline
sqlfile | sqlfile=somefilename | Name of the SQL file generated by this device. Default = Sql.txt


Managing a Test Case

A test case is a set of traces grouped by a defined context. A test case begins when the StartTest function or method is called, and ends when the EndTest function or method is called.

Note: Context changes within the StartTest and EndTest events have a global effect regardless of the device handle passed to the functions. Therefore, make certain that your code has matching StartTest and EndTest function calls.

To manage a test case using C

  1. Mark the beginning of the test case by calling the WTTLogStartTest function or the WTTLogStartTestEx function.
  2. Trace application errors.
  3. Mark the end of the test case by calling the WTTLogEndTest function or the WTTLogEndTestEx function.

To manage a test case using C++

  1. Mark the beginning of the test case by calling the CWTTLogger::StartTest method or the CWTTLogger::StartTestEx method.
  2. Trace application errors.
  3. Mark the end of the test case by calling the CWTTLogger::EndTest method or the CWTTLogger::EndTestEx method.

To manage a test case using COM

  1. Mark the beginning of the test case by calling the IWTTLog::StartTest method or the IWTTLog::StartTestEx method.
  2. Trace application errors.
  3. Mark the end of the test case by calling the IWTTLog::EndTest method or the IWTTLog::EndTestEx method.

To manage a test case using .NET

  1. Mark the beginning of the test case by calling the WttLogger.StartTest method.
  2. Trace application errors.
  3. Mark the end of the test case by calling the WTTLogger.EndTest method.

Topics in this section

Logger modes and test case results

Selective roll up of test case results

See Also

Getting Started, Sample Code


Logger Modes and Test Case Results

There are two modes in which the Logger can be working when it determines the test case result—auto mode or user mode.

Auto Mode

If auto mode is set, the test case results provided by the user may be overridden according to the previous traces. In this case, one of the following types of test case results may be logged:

  • Passed – if no error, assert, invalid parameter, break, warning, or bug traces occurred during the test case.
  • Warned – if a warning trace occurred, but no error, assert, invalid parameter, break, or bug trace occurred during the test case.
  • Failed – if an error, assert, invalid parameter, or break trace occurred, but no bug trace occurred during the test case.
  • Blocked – if a bug trace occurred during the test case, or the user application declares the test case blocked.
  • Skipped – if the user application declares the test case skipped.

Note: The logger keeps track of the test case results and provides a rollup of them if the following conditions are met:

  • The Logger is running under DTM.
  • The DTM Task is set to Rollup result to job.
  • In Task Failure Conditions, Declare task failure based on results from log is set to WTTLog.

User Mode

If user mode is set, the Logger will not override the test case result that is set by the EndTest function. This mode is used primarily for advanced users to allow better test result handling and for backward compatibility with existing user applications where only the StartTest and EndTest functions are called without any other traces.

To set Logger to user mode, add $LocalPub:WTTLogPFMode=user to the logger device string or pass /WTTLogPFMode:User from the application command line.

See Also

Getting Started, Managing a test case


Selective Roll Up of Test Case Results

DTM Logger enables you to selectively include test-case results in the rolled-up results for the collection. This effectively excludes any other test cases from the result totals. A failure in a test case that is not explicitly included will not affect the overall results for the collection.

To selectively roll up test case results

  1. Create a resource DLL and add it to the project for your test executable.
  2. To this DLL, add a string table with an entry for each test case you want to include in the rolled-up results. Each entry must consist of two parts separated by a semicolon (;). The first part must be the test case GUID, and the second part must be the test case name. The following example shows a typical string table entry:

  3. For the $LocalPub log device type, set the WTTLogAssertMode option to true. For more information about the $LocalPub options, see Log Device Types.
  4. Set the WTTLogAssertDLL option to the path of the resource DLL containing your string table.
  5. In your test code, start the test using WTTLogger.StartTest(String, Guid) (.NET) or CWTTLogger::StartTestWithResID (C++).
  6. End the test using WTTLogger.EndTest(String, String, Guid) (.NET) or CWTTLogger::EndTestWithResID (C++).

When DTM Logger makes the pass/fail decision for a particular test case, it first looks for the test case in the resource string table. If an entry for the test case is found in the table, DTM Logger counts the test case towards the final result. If the test case is not found in the table, DTM Logger omits it from the roll up.

See Also

Getting Started, Managing a test case


Performing a Trace

The purpose of the DTM Logger is to log messages from your test program to various logging devices. A trace is a log entry.

The following attributes are associated with a trace:

  • Run time information (RTI) – Information about who generated the trace.
  • Trace context – Information about the logical environment of the trace. For more information about defining a trace context, see Trace context.
  • Trace level – Defines the purpose or type of the trace. For more information about available trace levels, see Trace level.
  • Trace priority – Determines the relative importance of the trace. For more information about available trace priorities, see Trace Priority.
  • Trace message – Defines the message to be logged. For more information about trace message limitations, see Trace message.

To perform a trace using C

Call one of the following functions: WTTLogTrace, WTTLogTraceEx, or WTTLogUserDefinedTraceEx.

To perform a trace using C++

Call one of the following methods:

  • CWTTLogger::Trace
  • CWTTLogger::TraceEx
  • CWTTLogger::TraceExV
  • CWTTLogger::TraceMsg
  • CWTTLogger::TraceV
  • CWTTLogger::UserDefinedTrace
  • CWTTLogger::UserDefinedTraceEx
  • CWTTLogger::UserDefinedTraceExV
  • CWTTLogger::UserDefinedTraceV.

To perform a trace using COM

Call one of the following methods: IWTTLog::Trace or IWTTLog::UserDefinedTrace.

To perform a trace using .NET

  1. Create the appropriate trace level object. For more information about creating .NET trace level objects, see Trace level.
  2. Call the WTTLogger.Trace method passing the trace level object.

Topics in this section

Trace context

Trace level

Trace Priority

Trace message

See Also

Getting Started, Sample Code


Trace Context

A trace context is a tag that can be applied to traces to organize them into groups or trees. A context consists of two components—a current context and a parent context. When both values are specified, an XSLT can construct a context tree that groups traces according to their contexts.

Context can be used to tag messages that span across multiple machines, processes, or threads. This becomes particularly useful when you want to do client-server testing.

Your application may call the SetContext function or method to switch from one context to another. However, you must take care when choosing the context to which you switch, because DTM Logger cannot prevent you from switching to an invalid context.

To switch contexts using C

Call the WTTLogSetContext function, and pass it the current context and the parent context.

To switch contexts using C++

Call the CWTTLogger::SetContext method, and pass it the current context and the parent context.

To switch contexts using COM

Call the IWTTLog::SetContext method, and pass it the current context and the parent context.

To switch contexts using .NET

Call the WTTLogger.SetContext method.

Context XML element

A typical context element in an XML log file looks like this:

    <CTX ID="139721409" Current="Test1" Parent="WTTLOG" />

For more information about the context element, see Logger XML Schema.

See Also

Performing a trace, Trace level, Trace Priority


Trace Level

A trace level defines the type of information to be logged by DTM Logger. There are many trace levels available for your use. For example, trace levels exist for logging errors, bugs, warnings, computer information, messages, and so forth.

The way trace levels are defined in managed code is very different from the way it is done in unmanaged code. The following sections provide the information you need to a trace level:

Trace Levels in Managed Code (.NET) Trace Levels in Unmanaged Code (C, C++, COM)

See Also

Performing a trace, Trace Priority, Trace context


Trace Levels in Managed Code (.NET)

In .NET code, a trace level object is created and passed to the WTTLogger.Trace method. The following table shows the available trace levels and the associated classes:

Trace level | Trace level class
Assertion | LevelAssert
Debug break | LevelBreak
Known bug | LevelBug
Custom-defined trace level | LevelCustom
Error | LevelError
Invalid parameter | LevelInvalidParam
Message | LevelMessage
Test suite rollup information | LevelRollup
Tactics fields | LevelTCMInfo
Warning message | LevelWarning

Enabling and disabling trace levels

Trace levels are enabled by default, however you can programmatically enable and disable trace levels if desired.

To disable trace levels

Call the WTTLogger.DisableTraceLevels method.

To enable trace levels

Call the WTTLogger.EnableTraceLevels method.


Trace Levels in Unmanaged Code (C, C++, COM)

In unmanaged code, a trace level tells DTM Logger two things: the type of information to be logged, and what additional data is required. The trace level is passed to the Trace function or method, which takes a variable number of additional parameters. The number and type the parameters depend on the trace level value.

Level-dependent parameter examples

In the following C++ example, a Message trace accepts one additional string parameter as shown below.

CWTTLogger.Trace(
   WTT_LVL_MSG,
   hDevice,
   L"This is a unit test."
);

However, a Bug trace accepts two additional parameters, a string (the bug database) and an integer (the bug number), as shown below.

CWTTLogger.Trace(
   WTT_LVL_BUG,
   hDevice,
   L"BugDB",
   890403
);

Trace level and Trace function parameters

The following table shows the predefined trace levels and the additional parameters required by the Trace and UserDefinedTrace functions for each trace level. For more information about Trace function parameters, see CWTTLogger::Trace (C++), WTTLogTrace (C), or IWTTLog::Trace (COM).

Level | Purpose | C/C++ parameters | COM parameters
WTT_LVL_MSG | Message | LPWSTR – printf-style format string ... – printf-style variable args | BSTR – the message string
WTT_LVL_ERR See the note below | Error | DWORD – error code DWORD – error type LPWSTR – source file name ULONG – source file line LPWSTR – additional user-supplied message | DWORD – error code DWORD – error type BSTR – source file name ULONG – source file line BSTR – additional user-supplied message
WTT_LVL_ASSERT | Assertion | LPWSTR – source file name ULONG – source file line LPWSTR – additional user-supplied message | BSTR – source file name ULONG – source file line BSTR – additional user-supplied message
WTT_LVL_INVALID_PARAM | Invalid parameter | LPWSTR – source file name ULONG – source file line | BSTR – source file name ULONG – source file line
WTT_LVL_BUG | Known bug | LPWSTR – bug management database name ULONG – bug ID DWORD – bug type Where available bug types are: WTT_BUG_TYPE_BLOCKING – Bug blocking the test pass WTT_BUG_TYPE_NONBLOCKING – Bug non-blocking the test pass Any other value is treated as an unknown bug type. | BSTR – bug management database name ULONG – bug ID DWORD – bug type Where available bug types are: WTT_BUG_TYPE_BLOCKING – Bug blocking the test pass WTT_BUG_TYPE_NONBLOCKING – Bug non-blocking the test pass Any other value is treated as an unknown bug type.
WTT_LVL_BREAK | Debug break | DWORD – error code DWORD – error type LPWSTR – source file name ULONG – source file line LPWSTR – additional user-supplied message | DWORD – error code DWORD – error type BSTR – source file name ULONG – source file line BSTR – additional user-supplied message
WTT_LVL_WARN | Warning message | LPWSTR – source file name ULONG – source file line LPWSTR – additional user-supplied message | BSTR – source file name ULONG – source file line BSTR – additional user-supplied message
WTT_LVL_FUNCTION | Function entry or exit points | LPWSTR – function name LPWSTR – source file name | BSTR – function name BSTR – source file name
WTT_LVL_START_TEST | Start of a test case | Use StartTest or StartTestEx wrapper function instead | Use StartTest or StartTestEx wrapper function instead
WTT_LVL_END_TEST | End of a test case | Use EndTest or EndTestEx wrapper function instead | Use EndTest or EndTestEx wrapper function instead
WTT_LVL_TCMINFO | Tactics fields | int – Test case ID, usually set to -1 LPWSTR – Node path LPWSTR – Test case title – set later LPWSTR – Hash key LPWSTR – Created by LPWSTR – Modified by LPWSTR – Assigned to LPWSTR – Test type LPWSTR – Result type LPWSTR – Milestone ULONG – Priority ULONG – Test time LPWSTR – Comments LPWSTR – Method LPWSTR – Frequency LPWSTR – Description LPWSTR – Scripts LPWSTR – Log file path LPWSTR – Suite LPWSTR – Area LPWSTR – Component LPWSTR – Sub component LPWSTR – Dev LPWSTR – Test lead LPWSTR – Log table BOOL – Create only BOOL – Log only BOOL – Recursive | int – Test case ID, usually set to -1 BSTR – Node path BSTR – Test case title – set later BSTR – Hash key BSTR – Created by BSTR – Modified by BSTR – Assigned to BSTR – Test type BSTR – Result type BSTR – Milestone ULONG – Priority ULONG – Test time BSTR – Comments BSTR – Method BSTR – Frequency BSTR – Description BSTR – Scripts BSTR – Log file path BSTR – Suite BSTR – Area BSTR – Component BSTR – Sub component BSTR – Dev BSTR – Test lead BSTR – Log table BOOL – Create only BOOL – Log only BOOL – Recursive
WTT_LVL_MACHINEINFO | Machine-related test case fields for Tactics | LPWSTR – OS LPWSTR – Service Pack LPWSTR – Platform (processor architecture) LPWSTR – Version (upgrade path) LPWSTR – VBL (build lab) LPWSTR – build number LPWSTR – build date LPWSTR – language LPWSTR – config | BSTR – OS BSTR – Service Pack BSTR – Platform (processor architecture) BSTR – Version (upgrade path) BSTR – VBL (build lab) BSTR – build number BSTR – build date BSTR – language BSTR – config
WTT_LVL_ROLLUP See the note below | Test suite roll-up information | ULONG – number of passed test cases ULONG – number of warned test cases ULONG – number of failed test cases ULONG – number of blocked test cases ULONG – number of skipped test cases | ULONG – number of passed test cases ULONG – number of warned test cases ULONG – number of failed test cases ULONG – number of blocked test cases ULONG – number of skipped test cases

Note about WTT_LVL_ERR

If the message string argument of the WTT_LVL_ERR trace level contains a string variable (%s), an error is thrown. To use a string variable, make it the first string of the argument list and make your message the second string of the argument list.

Note about WTT_LVL_ROLLUP

In order for a PFRollup node to be added to the log file, you must call the Trace method with the WTT_LVL_ROLLUP trace level before closing the log device. In the managed interface, such a call is automatically provided for the user, but in unmanaged interfaces it is not provided. That is why the user must explicitly make this call.


Trace Priority

A trace priority indicates to the Logger the relative importance of the trace entry. Your application can dynamically set priority masks to filter traces based on their priority. Trace priority can be very useful when you call the UserDefinedTrace method.

Using trace priorities allows certain traces to be blocked or filtered based on their importance during run-time. If user-defined trace levels are used, then the trace priority can be used to determine the urgency for logging those user traces in the log file. If, on the other hand, predefined trace levels are used, then the trace priorities are fixed and your application cannot override them. In either case, you can benefit from filtering based on priority.

For implementations of trace priorities in specific technologies, see the following topics:

Trace Priorities in Managed Code (.NET)

Trace Levels in Unmanaged Code (C, C++, COM)

See Also

Performing a trace, Trace level, Trace context


Trace Priorities in Managed Code (.NET)

The following list shows the available trace priorities for .NET:

  • High – high priority traces
  • Medium – medium priority traces
  • Low – low priority traces
  • UserDefined – user-defined priority traces


Trace Priorities in Unmanaged Code (C, C++, COM)

The following list shows the available trace priorities for C, C++, and COM:

  • WTT_TRACE_PRIORITY_HIGH – high priority traces
  • WTT_TRACE_PRIORITY_MEDIUM – medium priority traces
  • WTT_TRACE_PRIORITY_LOW – low priority traces
  • WTT_TRACE_PRIORITY_USER – user-define priority traces

Trace priorities for predefined trace levels

The following list shows each of the predefined trace levels and the trace priority assigned to them:

  • WTT_PRI_MSG has WTT_TRACE_PRIORITY_MEDIUM priority
  • WTT_PRI_USER has WTT_TRACE_PRIORITY_USER priority
  • WTT_PRI_ERR has WTT_TRACE_PRIORITY_HIGH priority
  • WTT_PRI_ASSERT has WTT_TRACE_PRIORITY_HIGH priority
  • WTT_PRI_INVALID_PARAM has WTT_TRACE_PRIORITY_HIGH priority
  • WTT_PRI_BUG has WTT_TRACE_PRIORITY_HIGH priority
  • WTT_PRI_BREAK has WTT_TRACE_PRIORITY_HIGH priority
  • WTT_PRI_WARN has WTT_TRACE_PRIORITY_MEDIUM priority
  • WTT_PRI_FUNCTION_ENTRY has WTT_TRACE_PRIORITY_LOW priority
  • WTT_PRI_FUNCTION_EXIT has WTT_TRACE_PRIORITY_LOW priority
  • WTT_PRI_START_TEST has WTT_TRACE_PRIORITY_HIGH priority
  • WTT_PRI_END_TEST has WTT_TRACE_PRIORITY_HIGH priority
  • WTT_PRI_TCMINFO has WTT_TRACE_PRIORITY_MEDIUM priority
  • WTT_PRI_MACHINEINFO has WTT_TRACE_PRIORITY_MEDIUM priority
  • WTT_PRI_ROLLUP has WTT_TRACE_PRIORITY_HIGH priority


Trace Message

A Logger trace message is an XML-formatted string of Unicode characters. This string is strictly limited to 4096 characters (8 KB). Strings longer than 4096 characters will be truncated.

If your message string includes XML escaped characters such as '&', '<', or '>', limit your string to approximately 3900 characters.

You can also print messages directly to the log file using the wprintf function. However, your message will still be limited to 4096 characters.

See Also

Performing a trace, Trace level, Trace Priority


Post-Processing Log Files

One of the great advantages of having XML-based log files is being able to process them through a standard XSL Transformation (XSLT).

DTM Logger provides the following standard XML transformation templates:

  • Normalise.xslt – Converts the flat raw XML traces to a test->machine->process->thread hierarchy.
  • Visualise.xslt – Converts the normalized XML log file to an HTML file that shows the test results.

To perform the transformation you can use the [image] Msxsl.exe program, which is a free download from Microsoft.com. You can also design your own [image] .NET transformation program.

Example transformation

The following command line transforms a log file to a normalized view of the test case in which the traces are organized in a test->machine->process->thread hierarchy:

    msxsl.exe mytest.m.xml normalise.xslt /o normalised.xml

See Also

DTM Logger overview, Getting started with Logger, Logger XML Schema


Sample Code

The DTM Logger sample code is divided into the following groups:

Managed Samples (.NET)

Unmanaged Samples (C/C++, COM, scripting)

See Also

Logger XML Schema, Logger Reference, DTM Logger overview


Managed Samples (.NET)

The following code samples show the basics of using the DTM Logger for .NET programs written in C#.

Complete Sample Using C#

Logger Sample Using C#

Logger Sample Using C# (Legacy)

See Also

Logger XML Schema, Sample Code


Complete Sample Using C#

The following sample shows a typical use of the managed logger to log the start of a test case, a message, an error, and the end of a test case.

using System;
using System.IO;

//for logger namespace
using Microsoft.Wtt.Log;

namespace testApp
{
    class TestCase
    {
        public TestCase(){}
        public bool InitializeTestCase(string initializationFileName)
        {
            //do initialization
            return true;
        }
    }

    class MainClass
    {
        [STAThread]
        static void Main(string[] args)
        {
            WttLogger Logger = new WttLogger("$LogFile;$Console");

            //start a test case
            Logger.StartTest("Test 1 - Testing Tracing functions");

            Logger.Trace(new LevelError(0x3,ErrorType.Win32,"break"));

            //trace machine info
            Logger.TraceMachineInfo();

            //trace a message using message string
            Logger.Trace(new LevelMessage("Testing Tracing Messages"));

            //trace a message using user object only
            TestCase userObject = new TestCase();

            Logger.Trace(new LevelMessage(userObject));

            //trace a message using user object and a message string
            Logger.Trace(new LevelMessage("Testing Tracing Messages with user Ojects",userObject));

            //trace a normal error
            Logger.Trace(new LevelError(0x3,ErrorType.Win32, "Testing Tracing Errors"));

            try
            {
                //generate IOException
                File.Open("c:\toot.txt",FileMode.Open,FileAccess.Read,FileShare.Read);
            }
            catch(Exception exp)
            {
                //trace an exception error
                Logger.Trace(new LevelError(exp));
            }

            //end test case
            Logger.EndTest("Test 1 - Testing Tracing functions", 0, null);
        }
    }
}

See Also

Sample Code


Logger Sample Using C#

The following code shows how to use the DTM Logger in a C# program.

using System;
using System.IO;
using System.Runtime.Serialization;
using System.Xml.Serialization;
using Microsoft.Wtt.Log;

...

    void DoSampleTest()
    {
        string deviceString = "$logfile:file=WTTLOGTest.xml,Writemode=overwrite";
        m_Logger = new WttLogger(deviceString);

        //start a test case
        m_Logger.StartTest("Test 1 - Testing Tracing functions");

        m_Logger.Trace(new LevelError(0x3,ErrorType.Win32,"break"));
        //trace machine info
        m_Logger.TraceMachineInfo();

        //trace a message using message string
        m_Logger.Trace(new LevelMessage("Testing Tracing Messages"));

        //trace a message using user object only
        Test1 userObject = new Test1();
        m_Logger.Trace(new LevelMessage(userObject));

        //trace a message using user object and a message string
        m_Logger.Trace(new LevelMessage("Testing Tracing Messages with user Ojects",userObject));

        //trace a normal error
        m_Logger.Trace(new LevelError(0x3,ErrorType.Win32,
            "Testing Tracing Errors"));

        try
        {
            //generate IOException
            File.Open("c:\toot.txt",FileMode.Open,FileAccess.Read,FileShare.Read);
        }
        catch(Exception exp)
        {
            //trace an exception error
            m_Logger.Trace(new LevelError(exp));
        }
        //end test case
        m_Logger.EndTest("Test 1 - Testing Tracing functions",0,null);
    }

See Also

Sample Code


Logger Sample Using C# (Legacy)

Deprecated: This example uses a legacy namespace. For new applications, use the Microsoft.WTT.Log namespace.

The following code demonstrates how to implement logging for a simple test case with only one variation using the WTTLogger .NET classes.

using System;
using Microsoft.Wtt.Log;

/// <summary>
/// Test case.
/// <summary>
class TestCase
{
  public void Run ()
  {
    // Using Trace makes it easier to do logging.
    Trace.Write( Level.Info, "Test case 1 is executing." );
    // We intentionally cause exception to demonstrate exception handling.
    ((string)null).ToString();
  }
}

/// <summary>
/// Sample with one test case without variations.
/// <summary>
class MainClass
{
    /// <summary>
    /// The main entry point for the application.
    /// <summary>
    [STAThread]
    static void Main(string[] args)
    {
        // Create new logging object.
        // Using 'using' guarantees that log.Dispose() will be called at the end.
        using ( WttLog log = new WttLog( "$console" ) )
        {
          IContext testContext = log.StartTest( "Test case 1" );

          try
          {
            // Create test case object.
            TestCase test = new TestCase();
            // Execute test case.
            test.Run();
          }
          catch ( Exception exception )
          {
            // Using CheckResult(...) is equivalent to Serialize( Level.Fail, ... )
            // but it makes code more readable since all check points are clearly
            // marked.
            log.CheckResult( "Unexpected exception: "+exception.Message, exception );
          }

          log.EndTest( testContext );
        }
    }
}

See Also

Sample Code


Unmanaged Samples (C/C++, COM, scripting)

The following samples show the basics of using the DTM Logger for programs written in C/C++, COM, and Tactics scripting.

Logger Sample Using C

Logger Sample Using C++

Error list Sample Using C++

Logger Sample Using COM

Logger Sample Using Tactics Scripting

See Also

Logger XML Schema, Sample Code


Logger Sample Using C

The following C language code logs several different trace levels.

void __cdecl main (int argc, char *argv[])
{
    HRESULT hr = S_OK;
    LONG hDevice = 0;

    hr = WTTLogCreateLogDevice(
        L"$LocalPub($LogFile:file=\"foo.xml\",writemode=overwrite;$Console)",
        &hDevice
    );

    hr = WTTLogTrace(
        hDevice,
        WTT_LVL_FUNCTION_ENTRY,
        __WFILE__,
        L"main"
    );

    hr = WTTLogTrace(
        hDevice,
        WTT_LVL_MACHINEINFO,
        NULL,          // OS
        L"Windows XP",          // platform
        L"5.1",          // version (upgrade path)
        L"Main",          // VBL
        L"3615.00",    // build number
        L"20050229",          // build date
        L"EN-US",          // language
        NULL           // config
    );

    hr = WTTLogTrace(
        hDevice,
        WTT_LVL_TCMINFO,
        -1,                            // Test case ID
        L"$\\\\DTM Logger\\COM Test",  // node path
        NULL,                          // Test case title -- set later
        NULL,                          // Hash key
        NULL,                          // Created by
        NULL,                          // Modified by
        NULL,                          // Assigned to
        NULL,                          // Test type
        NULL,                          // Result type
        NULL,                          // Milestone
        NULL,                          // Priority
        NULL,                          // Test time
        NULL,                          // Comments
        NULL,                          // Method
        NULL,                          // Frequency
        NULL,                          // Description
        NULL,                          // Scripts
        NULL,                          // Log file path
        NULL,                          // Suite
        NULL,                          // Area
        NULL,                          // Component
        NULL,                          // Sub component
        NULL,                          // Dev
        NULL,                          // Test lead
        FALSE,                         // Create only
        TRUE,                          // Log only
        FALSE                          // Recursive
    );

    hr = WTTLogStartTest(
        hDevice,
        L"DTM Logger Test"
    );

    hr = WTTLogTrace(
        hDevice,
        WTT_LVL_MSG,
        L"This is a unit test."
    );

    hr = WTTLogAddErrorToErrorList(
        S_OK,
        WTT_ERROR_TYPE_HRESULT,
        WTT_ERROR_LIST_EXPECTED
    );

    hr = WTTLogCheckResult(
        hDevice,
        S_OK,
        WTT_ERROR_TYPE_HRESULT,
        __WFILE__,
        __LINE__,
        L"This should pass, and does not log"
    );

    hr = WTTLogRemoveErrorFromErrorList(
        S_OK,
        WTT_ERROR_TYPE_HRESULT,
        WTT_ERROR_LIST_EXPECTED
    );

    hr = WTTLogCheckResult(
        hDevice,
        S_OK,
        WTT_ERROR_TYPE_HRESULT,
        __WFILE__,
        __LINE__,
        L"This should fail, and it should log"
    );

    hr = WTTLogTrace(
        hDevice,
        WTT_LVL_ERR,
        E_POINTER,
        WTT_ERROR_TYPE_HRESULT,
        __WFILE__,
        __LINE__,
        L"This is an error"
    );

    hr = WTTLogTrace(
        hDevice,
        WTT_LVL_INVALID_PARAM,
        __WFILE__,
        __LINE__
    );

    hr = WTTLogTrace(
        hDevice,
        WTT_LVL_BUG,
        L"BugDB",
        890403
    );

    hr = WTTLogTrace(
        hDevice,
        WTT_LVL_BREAK,
        E_POINTER,
        WTT_ERROR_TYPE_HRESULT,
        __WFILE__,
        __LINE__,
        L"This is a break"
    );

    hr = WTTLogTrace(
        hDevice,
        WTT_LVL_WARN,
        __WFILE__,
        __LINE__,
        L"This is a warning message"
    );

    hr = WTTLogUserDefinedTrace(
        hDevice,
        L"MyLvl",
        WTT_LVL_MSG,
        100000,
        L"%s",
        L"This is a user defined trace."
    );

    hr = WTTLogAssert(
        hDevice,
        FALSE,
        __WFILE__,
        __LINE__,
        L"This is an assert"
    );

    hr = WTTLogEndTest(
        hDevice,
        L"DTM Logger COM Test",
        WTT_TESTCASE_RESULT_PASS,
        L"This is the repro line"
    );

    hr = WTTLogTrace(
        hDevice,
        WTT_LVL_FUNCTION_EXIT,
        __WFILE__,
        L"main"
    );

    hr = WTTLogPFRollup(
        hDevice,
        0,
        0,
        0,
        0,
        0
    );

    hr = WTTLogCloseLogDevice(
        hDevice,
        NULL
    );

    // Mandatory call to destroy the global Logger
    WTTLogUninit();

    return;
}

See Also

Sample Code


Logger Sample Using C++

The following C++ code shows the basics of using the DTM Logger, including how to create and close a log device, how to start and end a test case, and how to log a trace message.

#include "WTTlogger.h"
#include <stdio.h>

int __cdecl main (int argc, char *argv[])
{

    HRESULT hr      = S_OK;
    LONG    hDevice = NULL;
    CLogger Logger;

    //
    //  Set the outputs
    //
    hr = Logger.CreateLogDevice(
        NULL,
        &hDevice
    );

    //
    //  Collect machine information
    //
    hr = Logger.TraceMachineInfo(
        hDevice,
        NULL
    );

    //
    //  Trace some message
    //
    hr = Logger.Trace(
        WTT_LVL_MSG,
        hDevice,
        L"This is a message"
    );

    hr = Logger.Trace(
        WTT_LVL_MSG,
        hDevice,
        L"This is a message with parameter %d %s",
        1234,
        L"string"
    );

    //
    //  Trace some message with user defined XML
    //
    hr = Logger.TraceEx(
        WTT_LVL_MSG,
        WTT_PRI_MSG,
        hDevice,
        L"<MyXML>DTM Logger trace all unit test<MyXML>>",
        L"This is a message with user XML"
    );

    hr = Logger.TraceEx(
        WTT_LVL_MSG,
        WTT_PRI_MSG,
        hDevice,
        L"<MyXML>DTM Logger trace all unit test<MyXML>",
        L"This is a message with user XML and parameter %d %s",
        1234,
        L"string"
    );

    //
    //  Trace an error
    //
    hr = Logger.Trace(
        WTT_LVL_ERR,
        hDevice,
        ERROR_FILE_NOT_FOUND,
        WTT_ERROR_TYPE_WIN32,
        __WFILE__,
        __LINE__,
        L"This is a Win32 error"
    );

    hr = Logger.Trace(
        WTT_LVL_ERR,
        hDevice,
        FALSE,
        WTT_ERROR_TYPE_BOOL,
        __WFILE__,
        __LINE__,
        L"This is a boolean error"
    );

    hr = Logger.Trace(
        WTT_LVL_ERR,
        hDevice,
        E_ACCESSDENIED,
        WTT_ERROR_TYPE_HRESULT,
        __WFILE__,
        __LINE__,
        L"This is a HRESULT error"
    );

    hr = Logger.Trace(
        WTT_LVL_ERR,
        hDevice,
        STATUS_ACCESS_VIOLATION,
        WTT_ERROR_TYPE_NTSTATUS,
        __WFILE__,
        __LINE__,
        L"This is a NTSTATUS error"
    );

    //
    //  Trace an assert
    //
    hr = Logger.Trace(
        WTT_LVL_ASSERT,
        hDevice,
        __WFILE__,
        __LINE__,
        L"This is an assert"
    );

    //
    //  Trace a warning
    //
    hr = Logger.Trace(
        WTT_LVL_WARN,
        hDevice,
        __WFILE__,
        __LINE__,
        L"This is a warning"
    );

    //
    //  Trace a bug
    //
    hr = Logger.Trace(
        WTT_LVL_BUG,
        hDevice,
        L"WTT",
        12345,
        WTT_BUG_TYPE_NONBLOCKING
    );

    hr = Logger.Trace(
        WTT_LVL_BUG,
        hDevice,
        L"WTT",
        12345,
        WTT_BUG_TYPE_BLOCKING
    );

    //
    // Trace a user defined trace
    //
    DWORD dwBaseLevel = WTT_LVL_MSG;
    DWORD dwPriority = WTT_TRACE_PRIORITY_MEDIUM_CLASS;
    hr = Logger.UserDefinedTrace(
        L"MPSTRACE3469856450648956845068459860549864586",
        hDevice,
        dwBaseLevel,
        dwPriority,
        L"Hello World...! %d", 1
    );

    //
    //  Start the test
    //
    hr = Logger.StartTestEx(
        L"9b18233d-10c4-4491-ae70-1f89b00402a0",
        L"StartTestEx and EndTestExDemo",
        WTTLOG_TESTCASE_TYPE_NOPARENT,
        NULL,
        NULL,
        hDevice
    );

    //
    //  Mark the end of the test
    //
    hr = Logger.EndTestEx(
        WTT_TESTCASE_RESULT_PASS,
        L"9b18233d-10c4-4491-ae70-1f89b00402a0",
        L"StartTestEx and EndTestExDemo",
        NULL,
        NULL,
        hDevice
    );

    //
    //  Trace out the test roll up information
    //
    hr = Logger.Trace(
        WTT_LVL_ROLLUP,
        NULL,
        0,
        0,
        0,
        0,
        0
    );

    //
    //  Close all the outputs
    //
    hr = Logger.CloseLogDevice(
        NULL,
        hDevice
    );

    return 1;
} // main

See Also

Sample Code


Error List Sample Using C++

The following code segment shows how error lists are typically used.

CWTTLogger.AddErrorToErrorList(
   E_ACCESSDENIED,
   WTT_ERROR_TYPE_HRESULT,
   WTT_ERROR_LIST_EXPECTED
);

CWTTLogger.CheckResult(
   E_ACCESSDENIED,
   WTT_ERROR_TYPE_HRESULT,
   __WFILE__,
   __LINE__,
   L"This should pass, and does not log",
   NULL
);

CWTTLogger.RemoveErrorFromErrorList(
   E_ACCESSDENIED,
   WTT_ERROR_TYPE_HRESULT,
   WTT_ERROR_LIST_EXPECTED
);

CWTTLogger.CheckResult(
   E_ACCESSDENIED,
   WTT_ERROR_TYPE_HRESULT,
   __WFILE__,
   __LINE__,
   L"This should fail, and it should log",
   NULL
);

When the CWTTLogger::CheckResult method is first called, E_ACCESSDENIED is considered a valid error code, and Logger log nothing. However, on the second call to the CWTTLogger::CheckResult method, E_ACCESSDENIED is logged as a failure because it is not in the known error list.

See Also

Sample Code, Error lists


Logger Sample Using COM

The following code shows the basics of using the DTM Logger in a COM program.

const WTT_TRACE_LVL_MSG             =268435456
const WTT_TRACE_LVL_USER            =536870912
const WTT_TRACE_LVL_ERR             =16777216
const WTT_TRACE_LVL_ASSERT          =33554432
const WTT_TRACE_LVL_INVALID_PARAM   =67108864
const WTT_TRACE_LVL_BUG             =134217728
const WTT_TRACE_LVL_BREAK           =1048572
const WTT_TRACE_LVL_WARN            =2097152
const WTT_TRACE_LVL_FUNCTION        =65536
const WTT_TRACE_LVL_PARAM           =131072
const WTT_TRACE_LVL_START_TEST      =256
const WTT_TRACE_LVL_END_TEST        =512
const WTT_TRACE_LVL_TCMINFO         =1024
const WTT_TRACE_LVL_MACHINEINFO     =2048
const WTT_TRACE_LVL_ROLLUP          =16

const WTT_TESTCASE_RESULT_PASS      =1
const WTT_TESTCASE_RESULT_FAIL      =2
const WTT_TESTCASE_RESULT_BLOCKED   =3
const WTT_TESTCASE_RESULT_WARN      =4
const WTT_TESTCASE_RESULT_SKIPPED   =5

dim NameObj
dim Handle

Set NameObj = CreateObject("WTTLogger.Logger")

Handle = NameObj.CreateLogDevice("$Logfile;$Console")

NameObj.StartTest "DTM Logger COM Test", Handle

NameObj.Trace WTT_TRACE_LVL_ASSERT, Handle, "test.vbs", 12, "This is an assert"

NameObj.EndTest "DTM Logger COM Test", WTT_TESTCASE_RESULT_PASS, "This is the repro line", Handle

NameObj.CloseLogDevice NULL, Handle

See Also

Sample Code


Logger Sample Using Tactics Scripting

The following code shows the basics of using DTM Logger in Tactics scripting.

dim NameObj
dim Handle

Set NameObj = CreateObject("WTTLogger.Logger")

Handle = NameObj.CreateLogDevice("$LocalPub($LogFile:file=comtest;$Console;$Tactics)")

'  Test case ID
'  node path
'  Test case title -- set later
'  Hash key
'  Created by
'  Modified by
'  Assigned to
'  Test type
'  Result type
'  Milestone
'  Priority
'  Test time
'  Comments
'  Method
'  Frequency
'  Description
'  Scripts
'  Log file path
'  Suite
'  Area
'  Component
'  Sub component
'  Dev
'  Test lead
'  Create only
'  Log only
'  Recursive

NameObj.Trace               _
    1024,                   _
    0,                      _
    -1,                     _
    "$\\DTM Logger\COM Test", _
    NULL,                   _
    NULL,                   _
    NULL,                   _
    NULL,                   _
    NULL,                   _
    NULL,                   _
    NULL,                   _
    NULL,                   _
    NULL,                   _
    NULL,                   _
    NULL,                   _
    NULL,                   _
    NULL,                   _
    NULL,                   _
    NULL,                   _
    NULL,                   _
    NULL,                   _
    NULL,                   _
    NULL,                   _
    NULL,                   _
    NULL,                   _
    NULL,                   _
    0,                      _
    1,                      _
    0

NameObj.Trace               _
    2048,                   _
    0,                      _
    NULL,                   _
    NULL,                   _
    NULL,                   _
    NULL,                   _
    "3655.00",              _
    NULL,                   _
    NULL,                   _
    NULL

NameObj.StartTest "DTM Logger COM Test", 0

NameObj.Trace 33554432, 0, "test.vbs", 12, "This is an assert"

NameObj.EndTest "DTM Logger COM Test", 1, "This is the repro line", 0

NameObj.CloseLogDevice NULL, Handle

See Also

Logger code samples


Logger Troubleshooting

The following topics provide tips for solving problems you might encounter when using DTM Logger:

Test Shows Out-of-Context Errors

Tests that Formerly Passed Now Fail


Tests that Formerly Passed Now Fail

If your test passed in versions of DTM prior to 2.2 and now fails, it may have zero returns or out-of-context errors. The way that DTM Logger handles these test results has been changed for the following reasons:

Zero-Return Failures

With the release of DTM 2.2, logs with all zero counts (0 pass, 0 fail, 0 skip, 0 block) will now be considered a failure rather than a pass. This is because an all-zero return usually implies that something is wrong with a test or the test has had an early catastrophic failure. This is the same behavior found in logs elsewhere in DTM.

Out-of-Context Failures

Previously, DTM ignored DTM Logger failures that were reported out of context. This would cause a log with out-of-context failures to still report a pass in DTM. With DTM 2.2, this behavior has changed so that DTM now reports a failure in the case of out-of-context failures. By considering out-of-context failures as failures in DTM, test status can now be reported with greater accuracy.

To solve this problem, you will need to re-evaluate your driver on the basis of a failed test result.


Test Shows Out-of-Context Errors

The rollup information in the DTM Studio reported by the job or task includes the out-of-context error, blocked, warned, and skipped traces. If your test logs such traces outside of the StartTest/EndTest context, these traces will be reported.

The suggested approach for working with out-of-context errors is:

  • Fix all out of context errors or find a way to handle them using the CheckResult or CheckResultEx methods and error lists.
  • Do better handling on unexpected warnings, blocking issues, and skipped traces.
  • Fix the problems as soon as they show up in the rollup in DTM Studio.


Logger Reference

This reference contains DTM Logger XML schema and API interfaces for C/C++, COM, and .NET.

Logger XML Schema

CWTTLogger Class (C++)

IWTTLog Interface (COM)

WTTLog Functions (C)


Logger XML Schema

When a test run is completed, DTM Logger generates two XML files—*.m.xml and *.t.xml. The m.xml file is the master file which you should use for displaying or parsing. It stores the entries (XML entities) for the contexts and run-time-information blocks. The actual traces in XML format are contained in the t.xml file.

The Logger XML schema defines the format of these files. Each XML element (tag) contains a number of attributes and encloses sub-elements.

Common Attributes and Sub-Elements

The following attributes are common to all Logger elements:

  • CA – This attribute is the called-at time-stamp, which is relative to the beginning of the test run.
  • LA – This attribute is the logged-at time-stamp, which is relative to the beginning of the test run.

The following sub-elements are common to all Logger elements:

  • RTI – This sub-element is the index to the runtime-information table in the m.xml file, which describes the runtime information of each trace.

    Attributes:

    • ID – Identifier of the runtime-information table.
    • Machine – Name of the computer being used.
    • ProcessName – Name of the test being run.
    • ProcessID – Identifier of the test being run.
    • ThreadID – Identifier of the thread.

      Example:

      <RTI ID="1207879918" Machine="WEIYOU-WIS5" ProcessName="CTLUnitTest.exe"
           ProcessID="2824" ThreadID="2740" />

  • CTX – This sub-element is the index to the context table in the m.xml file, which describes the context of each trace.

    Attributes:

    • ID – Identifier of the context table.
    • Current – Name of the current context.
    • Parent – Name of the parent context.

      Example:

      <CTX ID="1637872268" Current="DTM Logger COM Test" Parent="WTTLOG" />

Note: The RTI and CTX elements contain all attributes the only first time they are logged. Every other logging contains just the their ID.

Example:

<RTI ID="1207879918" />
<CTX ID="1637872268" />

Logger element formats

The following topics describe the available XML elements for DTM Logger.

Assert Element

Break Element

Bug Element

EndTest Element

Entry Element

Error Element

Exit Element

InvalidParam Element

Machine Element

Msg Element

PFRollup Element

StartTest Element

TCM Element

Warn Element

See Also

DTM Logger overview, Getting started with Logger


Assert Element

Represents a logged trace for an assertion.

Attributes

Attribute | Description
File | Full filename to the source file where assert is reported.
Line | Line number of the assert.
UserText | Text message for the assert.

Example

<Assert File="c:\tests\unittest\main.cxx" Line="233"
        UserText="This is an assert" CA="35926" LA="2715741">

    <RTI ID="1207879918" />

    <CTX ID="1637872268" />

</Assert>

See Also

Logger XML Schema


Break Element

Represents a logged trace for a break into the debugger.

Attributes

Attribute | Description
File | Full filename to the source file where break is reported.
Line | Line number where the error occurred.
ErrorCode | Identifier code for the error.
ErrorType | Type of error that occurred. This should be one of the following: WIN32, BOOL, HRESULT, NT_STATUS.
ErrorText | Description of the error for Win32 and HResult errors. For boolean and NTStatus errors the this text will be in the following format: ErrorText="Error 0xc0000005"
UserText | Additional text message.

Example

<Break File="c:\tests\unittest\main.cxx" Line="194" ErrorCode="5"
       ErrorType="HRESULT" ErrorText="Access is denied."
       UserText="This is a break" CA="34076" LA="2153166">

    <RTI ID="1207879918" />

    <CTX ID="1637872268" />

</Break>

See Also

Logger XML Schema


Bug Element

Represents a logged trace for a known bug.

Attributes

Attribute | Description
DB | Name of the bug database.
ID | Identifier of the bug.
Type | Type of the bug: blocking or non-blocking.

Example

<Bug DB="BugDB" ID="890403" Type="Unknown Bug Type" CA="33796" LA="2016936">

    <RTI ID="1207879918" />

    <CTX ID="1637872268" />

</Bug>

See Also

Logger XML Schema


EndTest Element

Represents a logged trace for the end of a test case.

Attributes

Attribute | Description
Title | Name of the test.
Result | Result of running the test: pass or fail.
Repro | Reproduction line.
TUID | Test unique identifier.

Example

<EndTest Title="DTM Logger C++ Test" Result="Pass" Repro="This is the repro line"
         TUID="2FB85927-DFEB-4EBE-B5F0-738717943B03" CA="38129" LA="3283832">

    <RTI ID="1207879918" />

    <CTX ID="1748231519" />

</EndTest>

See Also

Logger XML Schema


Entry Element

Represents a logged trace for a function entry point.

Attributes

Attribute | Description
Function | Name of the entry-point function of the test.
File | Source file name containing the function code.

Example

<Entry Function="main" File="c:\tests\unittest\main.cxx" CA="30805"
       LA="135480">

    <RTI ID="1207879918" />

    <CTX ID="384048256" />

</Entry>

See Also

Logger XML Schema


Error Element

Represents a logged trace for an error.

Attributes

Attribute | Description
File | Full filename to the source file where the error is reported.
Line | Line number where the error occurred.
ErrCode | Error code.
ErrType | Type of error that occurred. This should be one of the following: WIN32, BOOL, HRESULT, NT_STATUS.
ErrorText | Description of the error for Win32 and HResult errors. For boolean and NTStatus errors the this text will be in the following format: ErrorText="Error 0xc0000005"
UserText | Addition text message.

Example

<Error File="c:\tests\unittest\main.cxx" Line="155" ErrCode="0"
       ErrType="HRESULT" ErrorText="The operation completed successfully."
       UserText="This should fail, and it should log" CA="32448" LA="1479820">

    <RTI ID="1207879918" />

    <CTX ID="1637872268" />

</Error>

See Also

Logger XML Schema


Exit Element

Represents a logged trace for a function exit point.

Attributes

Attribute | Description
Function | Name of the exit-point function for the test.
File | Source file name containing the function code.

Example

<Exit Function="main" File="c:\tests\unittest\main.cxx" CA="30805"
      LA="135480">

    <RTI ID="1207879918" />

    <CTX ID="384048256" />

</Exit>

See Also

Logger XML Schema


InvalidParam Element

Represents a logged trace for an error caused by an invalid parameter.

Attributes

Attribute | Description
File | Full filename to the source file where the invalid parameter is reported.
Line | Line number that contains the invalid parameter.

Example

<InvalidParam File="c:\tests\unittest\main.cxx" Line="176" CA="33511"
              LA="1908364">

    <RTI ID="1207879918" />

    <CTX ID="1637872268" />

</InvalidParam>

See Also

Logger XML Schema


Machine Element

Represents logged information about a test computer.

Attributes

Attribute | Description
Build | Build number of the OS where the application test runs.
Platform | CPU type in the computer.
OS | Operating system in the computer.
ServicePack | Service pack if present on the OS.
Version | Version of the OS.
BuildLab | Virtual Build lab where OS was built.
BuildDate | Date when the OS was built.
Language | Currently set language in the OS.
Config | Information about the computer configuration.

Example

<Machine Build="2600.00" Platform="x86" OS="Microsoft Windows XP"
         ServicePack="Service Pack 2" Version="5.1" BuildLab="xpsp_sp2_rtm"
         BuildDate="040803-2158" Language="English (US) (REDMOND)"
         Config="n/a" CA="472909" LA="474351">

    <RTI ID="716423222" />

    <CTX ID="384048256" />

</Machine>

See Also

Logger XML Schema


Msg Element

Represents a logged trace for a message.

Attributes

Attribute | Description
UserText | Contents of the text message.

Example

<Msg UserText="<This is a unit test.>" CA="32040" LA="1398461">

    <RTI ID="1207879918" />

    <CTX ID="1637872268" />

</Msg>

See Also

Logger XML Schema


PFRollup Element

Represents a logged summary of pass-fail roll-up information.

Attributes

Attribute | Description
Total | Total number of test runs.
Passed | Number of tests that completed successfully.
Failed | Number of tests that failed.
Blocked | Number of tests that were blocked and did not complete.
Warned | Number of tests that ended with a warning.
Skipped | Number of tests to were skipped and did not run.

Example

<PFRollup Total="1" Passed="1" Failed="0" Blocked="0" Warned="0" Skipped="0"
          CA="39205" LA="3416962">

    <RTI ID="1207879918" />

    <CTX ID="384048256" />

</PFRollup>

See Also

Logger XML Schema


StartTest Element

Represents a logged trace for the start of a test case.

Attributes

Attribute | Description
Title | Name of the test.
TUID | Test unique identifier.

Example

<StartTest Title="DTM Logger COM Test" TUID="2FB85927-DFEB-4EBE-B5F0-738717943B03"
           CA="31762" LA="1317698">

    <RTI ID="1207879918" />

    <CTX ID="1637872268" />

</StartTest>

See Also

Logger XML Schema


TCM Element

Represents logged information for test case management.

Attributes

Attribute | Description
TestCase | Identifier for the test case.
Path | Directory path to the test case.
Title | Name of the test case.
HashKey | Handle to the hash table entry for this test case.
CreatedBy | Name of the person that created the test case.
ModifiedBy | Name of the person that last modified the test case.
AssignedTo | Name of the person to whom the test case is assigned.
Type | Type of test.
ResultType | Type of the result returned by the test case.
Milestone | Project milestone for the test case.
Priority | Priority level assigned to the test case.
TestTime | Time in seconds to run the test case.
Comments | Remarks about the test case.
Method | Test case type (automated or manual).
Frequency | Number of times the test case is run.
Description | Description of the test case to be displayed.
Script | Names of the test scripts.
LogPath | Directory path to the log file.
Suite | Name of the test suite.
Area | Name of the project area.
Component | Name of the component under test.
SubComponent | Name of the subcomponent under test.
Dev | Name of the test case developer.
TestLead | Name of the test lead assigned to the test case.
LogTable | Name of the table that contains the log results.
CreateOnly | Indicates whether the test case is marked "create only".
LogOnly | Indicates whether the test case is marked "log only".
Recursive | Indicates whether the test case calls itself recursively.

Example

<TCM TestCase="-1" Path="$\\'My Logger'\COM Test" Title="(null)"
     HashKey="(null)" CreatedBy="PCHLAB" ModifiedBy="PCHLAB"
     AssignedTo="PCHLAB" Type="Special" ResultType="(null)"
     Milestone="Release" Priority="0" TestTime="0" Comments="No comments"
     Method="Automated" Frequency="(null)" Description="(null)"
     Script="(null)" LogPath="UNC Path to Log File goes here: NO LOG!"
     Suite="(null)" Area="(null)" Component="(null)" SubComponent="(null)"
     Dev="(null)" TestLead="(null)" LogTable="LogTbl_Results" CreateOnly="0"
     LogOnly="1" Recursive="0" CA="31410" LA="515169">

    <RTI ID="1207879918" />

    <CTX ID="384048256" />

</TCM>

See Also

Logger XML Schema


Warn Element

Represents a logged trace for a warning.

Attributes

Attribute | Description
File | Full filename to the source file where the warning is reported.
Line | Line number where the warning occurred.
UserText | Text message for the warning.

Example

<Warn File="c:\tests\unittest\main.cxx" Line="203" UserText="This is a warning message"
      CA="34558" LA="2367255">

    <RTI ID="1207879918" />

    <CTX ID="1637872268" />

</Warn>

See Also

Logger XML Schema


CWTTLogger Class (C++)

Encapsulates C++ methods for logging messages and errors.

public class CWTTLogger

Public Methods

SetDeviceOption
~CWTTLogger | Destroys and cleans up after this instance of the CWTTLogger class.
AddErrorToErrorList | Adds a specified error to a list of known errors.
Assert | Checks the specified condition and, if the condition is false, fails the test case unless a trace is logged or the user specifically declares the test case to be skipped.
CheckResult | Checks a specified result and logs an error if the result shows a failure.
CheckResultEx | Checks a specified result against a target result and logs an error if both the value and type match.
ClearContext | Clears the current context of the logger object.
ClearErrorList | Removes all errors of the specified type from a given list of known errors.
CloseLogDevice | Closes a log device topology specified by either the device string or the handle.
CreateLogDevice | Creates a log device topology according to the device string.
CreateLogDeviceCallback | Called by the parser after servicing the CreateLogDevice method.
CWTTLogger | Initializes a new instance of the CWTTLogger class.
DisableTraceLevels | Disables the specified set of device trace levels.
EnableTraceLevels | Enables the specified set of device trace levels.
EndTest | Traces the end of a test case, clears current test case context, and sets it to the parent context.
EndTestEx | Traces the end of a test case, and allows the user to specify a GUID-based test ID and a test hierarchy.
EndTestWithResID | Traces the end of a test case using the specified resource ID.
GetPFRollupStats | Retrieves the current pass-fail statistics.
RemoveErrorFromErrorList | Deletes the specified error from a list of known errors.
SetContext | Sets the current context of the logger object for all subsequent traces.
Sets the given options for the specified device.
SetDeviceTraceLevel | Sets the specified device trace level for all subsequent traces.
SetDeviceTracePriority | Sets the specified device trace priority for all subsequent traces.
StartTest | Traces the start of a test case.
StartTestEx | Traces the start of a test case and allows the user to specify a GUID-based test ID and a test hierarchy.
StartTestWithResID | Traces the start of a test case using the specified resource ID.
Trace | Logs a trace of the specified device at the given trace level.
TraceEx | Logs a trace of the specified device at the given trace level using an XML-formatted data string.
TraceExV | Logs a trace of the specified device at the given trace level using an XML-formatted data string and a prepared argument list.
TraceMachineInfo | Logs a trace of the the OS where the test is run.
TraceMsg | Logs a trace of the specified device at the user-defined trace level and a given priority.
 | Logs a trace of the specified device at the user-defined trace level and a given priority using a prepared argument list.
TraceV | Logs a trace of the specified device at the given trace level using a prepared argument list.
UserDefinedTrace | Logs trace data using a user-defined trace level.
UserDefinedTraceEx | Logs trace data using a user-defined trace level and an XML-formatted data string.
UserDefinedTraceExV | Logs trace data using a user-defined trace level and an XML-formatted data string.
UserDefinedTraceV | Logs trace data using a user-defined trace level and a prepared argument list.

Requirements

Header: Wttlogger.h

Library: WTTLog.dll

See Also

WTTLog Functions (C), IWTTLog Interface (COM)


CWTTLogger::~CWTTLogger

Destroys and cleans up after this instance of the CWTTLogger class.

public  ~CWTTLogger();

Parameters

Return Value

None

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++), CWTTLogger


CWTTLogger::AddErrorToErrorList

Adds the specified error type and error code to the given list of known errors.

HRESULT AddErrorToErrorList (
   DWORD dwErrorToAdd,
   DWORD dwErrorType,
   DWORD dwErrorList
);

Parameters

dwErrorToAdd
[in] Error code to add.

dwErrorType
[in] Type of the error. This is one of the following values:
WTT_ERROR_TYPE_HRESULT
WTT_ERROR_TYPE_NTSTATUS
WTT_ERROR_TYPE_WIN32
WTT_ERROR_TYPE_BOOL

dwErrorList
[in] Identifies the list to which the error will be added. This is one of the following values:
WTT_ERROR_LIST_EXPECTED
WTT_ERROR_LIST_BREAKON

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

Comments

DTM Logger uses the Error lists to allow a test to pass even though the return value from a test function is an error. The CheckResult function compares the error type and error code passed to it with the know errors on the list. If the error is on the list, CheckResult returns S_OK indicating the test passed. If the error is not on the list, the test fails.

See Also

CWTTLogger Class (C++), CWTTLogger::RemoveErrorFromErrorList, CWTTLogger::ClearErrorList, Error lists


CWTTLogger::Assert

Checks the specified condition and, if the condition is false, fails the test case unless a trace is logged or the user specifically declares the test case to be skipped.

HRESULT Assert (
   BOOL fCondition,
   LPWSTR pwszFile,
   UINT uiLine,
   LPWSTR pwszAssertMsg,
   LONG hDevice
);

Parameters

fCondition
[in] If true, prevents the test case from failing if the bug trace is not logged. If false, fails the test case unless the bug trace is logged.

pwszFile
[in] Name of the source file where the assert happened.

uiLine
[in] Line number within the source file where the assert happened.

pwszAssertMsg
[in] Text message of the assertion.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++), Trace


CWTTLogger::CheckResult

Checks a specified result and logs an error if the result shows a failure.

HRESULT CheckResult (
   DWORD dwResultToCheck,
   DWORD dwResultType,
   LPWSTR pwszFile,
   ULONG ulLine,
   LPWSTR pwszErrMsg,
   LONG hDevice
);

Parameters

dwResultToCheck
[in] Result to check.

dwResultType
[in] Type of the result. This is one of the following values:
WTT_ERROR_TYPE_HRESULT
WTT_ERROR_TYPE_NTSTATUS
WTT_ERROR_TYPE_WIN32
WTT_ERROR_TYPE_BOOL

pwszFile
[in] Name of the source file where the assert happened.

ulLine
[in] Line number within the source file where the assert happened.

pwszErrMsg
[in] Text of the error message.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++), CWTTLogger::CheckResultEx, Error lists


CWTTLogger::CheckResultEx

Checks a specified result against a target result and logs an error if both the value and type match.

HRESULT CheckResultEx (
   DWORD dwResultToCheck,
   DWORD dwResultType,
   DWORD dwTargetResult,
   DWORD dwTargetResultType,
   LPWSTR pwszFile,
   ULONG ulLine,
   LPWSTR pwszErrMsg,
   LONG hDevice
);

Parameters

dwResultToCheck
[in] Identifies the result to check.

dwResultType
[in] Type of the result. This is one of the following values:
WTT_ERROR_TYPE_HRESULT
WTT_ERROR_TYPE_NTSTATUS
WTT_ERROR_TYPE_WIN32
WTT_ERROR_TYPE_BOOL

dwTargetResult
[in] Target result against which to check.

dwTargetResultType
[in] Type of the target result. This is one of the following values:
WTT_ERROR_TYPE_HRESULT
WTT_ERROR_TYPE_NTSTATUS
WTT_ERROR_TYPE_WIN32
WTT_ERROR_TYPE_BOOL

pwszFile
[in] Name of the source file where the assert happened.

ulLine
[in] Line number within the source file where the assert happened.

pwszErrMsg
[in] Text message for the error.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++), CWTTLogger::CheckResult, Error Element


CWTTLogger::ClearContext

Clears the current context of the logger object.

HRESULT ClearContext (
   LPWSTR pwszCurrentContext,
   LPWSTR pwszParentContext
);

Parameters

pwszCurrentContext
[in] Current context of the logger object.

pwszParentContext
[in] Parent context of the logger object.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++), CWTTLogger::SetContext


CWTTLogger::ClearErrorList

Removes all errors of the specified type from a given list of known errors.

HRESULT ClearErrorList (
   DWORD dwErrorList,
   DWORD dwErrorType
);

Parameters

dwErrorList
[in] Error list to clear. This is one of the following values:
WTT_ERROR_LIST_EXPECTED
WTT_ERROR_LIST_BREAKON

dwErrorType
[in] Type of the error to remove. This is one of the following values:
WTT_ERROR_TYPE_HRESULT
WTT_ERROR_TYPE_NTSTATUS
WTT_ERROR_TYPE_WIN32
WTT_ERROR_TYPE_BOOL

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++), CWTTLogger::AddErrorToErrorList, CWTTLogger::RemoveErrorFromErrorList, Error lists


CWTTLogger::CloseLogDevice

Closes a log device topology specified by either the device string or the handle.

HRESULT CloseLogDevice (
   LPWSTR pwszLogDeviceName,
   LONG hDevice
);

Parameters

pwszLogDeviceName
[in] Log device string, which has the following syntax:
$<device_type>:<parameter_list>($<child_device1>[; $<child_device2>; ...])
For more information about constructing a device string, see Device string.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++), CWTTLogger::CreateLogDevice


CWTTLogger::CreateLogDevice

Creates a log device topology according to the device string.

HRESULT CreateLogDevice (
   LPWSTR pwszLogDeviceName,
   LONG* phDevice
);

Parameters

pwszLogDeviceName
[in] Log device string, which has the following syntax:
$<device_type>:<parameter_list>($<child_device1>[; $<child_device2>; ...])
For more information about constructing a device string, see Device string.

phDevice
[out] Pointer to a handle that represents the device tracing topology.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++), CWTTLogger::CloseLogDevice, CWTTLogger::CreateLogDeviceCallback


CWTTLogger::CreateLogDeviceCallback

Called by the parser after servicing the CreateLogDevice method.

static HRESULT CreateLogDeviceCallback (
   PVOID pvObj,
   DWORD tnNav,
   DWORD wttDevType,
   PVOID pParams
);

Parameters

pvObj
[in] Pointer to the callback object.

tnNav
[in] Tree navigation command. This is one of the following values:
TREE_NAV_CREATE_CHILD
TREE_NAV_SKIP_CHILD
TREE_NAV_GOTO_PARENT

wttDevType
[in] Log device type. This is one of the following values:
WTT_LOGDEVICE_LOCALPUB
WTT_LOGDEVICE_FILE
WTT_LOGDEVICE_CONSOLE
WTT_LOGDEVICE_DEBUGGER
WTT_LOGDEVICE_SPYWIN
WTT_LOGDEVICE_NETPUB
WTT_LOGDEVICE_NETSUB
WTT_LOGDEVICE_FILTER
WTT_LOGDEVICE_TACTICS
WTT_LOGDEVICE_PLAINLOG
WTT_LOGDEVICE_SECURELOG
WTT_LOGDEVICE_CUSTOM

pParams
[in] Array of named parameters.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++), CWTTLogger::CreateLogDevice


CWTTLogger::CWTTLogger

Initializes a new instance of the CWTTLogger class.

public  CWTTLogger();

Parameters

Return Value

None

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++), CWTTLogger::~CWTTLogger


CWTTLogger::DisableTraceLevels

Disables the specified set of device trace levels.

HRESULT DisableTraceLevels (
   LPWSTR pwszTraceLevels,
   LONG hDevice
);

Parameters

pwszTraceLevels
[in] String containing a list of trace levels to be disabled.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++), CWTTLogger::EnableTraceLevels


CWTTLogger::EnableTraceLevels

Enables the specified set of device trace levels.

HRESULT EnableTraceLevels (
   LPWSTR pwszTraceLevels,
   LONG hDevice
);

Parameters

pwszTraceLevels
[in] String containing a list of trace levels to be enabled.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++), CWTTLogger::DisableTraceLevels, CWTTLogger::SetDeviceTraceLevel


CWTTLogger::EndTest

Traces the end of a test case, clears current test case context, and sets it to the parent context.

HRESULT EndTest (
   LPWSTR pwszTestName,
   DWORD dwResult,
   LPWSTR pwszRepro,
   LONG hDevice
);

Parameters

pwszTestName
[in] Name of the test case.

dwResult
[in] Test case result. This must be one of the following values:
  • WTT_TESTCASE_RESULT_PASS – This value does NOT guarantee that the logger will log the test case as passed. If traces are logged that indicate an error, a warning, or so forth, the logger will automatically override this value.
  • WTT_TESTCASE_RESULT_WARN – This value does NOT guarantee that the logger will log the test case as warned. If traces are logged that indicate an error or so forth, the logger will automatically override this value.
  • WTT_TESTCASE_RESULT_FAIL – This value does NOT guarantee that the logger will log the test case as failed. If traces are logged that indicate a bug or if no error trace is logged, the logger will automatically override this value.
  • WTT_TESTCASE_RESULT_BLOCKED – This value guarantees that the logger will log the test case as blocked.
  • WTT_TESTCASE_RESULT_SKIPPED – This value guarantees that the logger will log the test case as skipped.

pwszRepro
[in] Repro line number rerunning the test. If NULL, DTM Logger will try to get the command line for the current process.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++), CWTTLogger::EndTestEx, CWTTLogger::StartTest, CWTTLogger::EndTestWithResID


CWTTLogger::EndTestEx

Traces the end of a test case, and allows the user to specify a GUID-based test ID and a test hierarchy.

HRESULT EndTestEx (
   DWORD dwResult,
   LPWSTR pwszTUID,
   LPWSTR pwszTestName,
   LPWSTR pwszParentTUID,
   LPWSTR pwszParentTestName,
   LONG hDevice
);

Parameters

dwResult
[in] Test case result. This must be one of the following values:
  • WTT_TESTCASE_RESULT_PASS – This value does NOT guarantee that the logger will log the test case as passed. If traces are logged that indicate an error, a warning, or so forth, the logger will automatically override this value.
  • WTT_TESTCASE_RESULT_WARN – This value does NOT guarantee that the logger will log the test case as warned. If traces are logged that indicate an error or so forth, the logger will automatically override this value.
  • WTT_TESTCASE_RESULT_FAIL – This value does NOT guarantee that the logger will log the test case as failed. If traces are logged that indicate a bug or if no error trace is logged, the logger will automatically override this value.
  • WTT_TESTCASE_RESULT_BLOCKED – This value guarantees that the logger will log the test case as blocked.

  • WTT_TESTCASE_RESULT_SKIPPED – This value guarantees that the logger will log the test case as skipped.

pwszTUID
[in] GUID (global universal identification) for the test case.

pwszTestName
[in] Name of the test case.

pwszParentTUID
[in] GUID for the parent test case.

pwszParentTestName
[in] Name of the parent test case.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Example

Log.StartTestEx (

L"b55de776-ea89-4dbe-9abd-df2041040cd7", // GUID of the test case

L"This is a sample test," // optional test case name,

WTTLOG_TESTCASE_TYPE_NOPARENT, // this is an independent test case

NULL, // GUID of the parent test case

NULL, // optional name of the parent test case

hDevice

);

Log.EndTestEx (

WTT_TESTCASE_RESULT_PASS, // test case result

L"b55de776-ea89-4dbe-9abd-df2041040cd7", // GUID of the test case

L"This is a sample test", // optional test case name,

NULL, // GUID of the parent test case

NULL, // optional name of the parent test case

hDevice

);

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++), CWTTLogger::EndTest, CWTTLogger::StartTestEx


CWTTLogger::EndTestWithResID

Traces the end of a test case using the specified resource ID.

HRESULT EndTestWithResID (
   UINT uiResID,
   DWORD dwResult,
   LPWSTR pwszRepro,
   LONG hDevice
);

Parameters

uiResID
[in] Identifier of the resource.

dwResult
[in] Test case result. This must be one of the following values:
  • WTT_TESTCASE_RESULT_PASS – This value does NOT guarantee that the logger will log the test case as passed. If traces are logged that indicate an error, a warning, or so forth, the logger will automatically override this value.
  • WTT_TESTCASE_RESULT_WARN – This value does NOT guarantee that the logger will log the test case as warned. If traces are logged that indicate an error or so forth, the logger will automatically override this value.
  • WTT_TESTCASE_RESULT_FAIL – This value does NOT guarantee that the logger will log the test case as failed. If traces are logged that indicate a bug or if no error trace is logged, the logger will automatically override this value.
  • WTT_TESTCASE_RESULT_BLOCKED – This value guarantees that the logger will log the test case as blocked.
  • WTT_TESTCASE_RESULT_SKIPPED – This value guarantees that the logger will log the test case as skipped.

pwszRepro
[in] Repro line number for the result.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++), CWTTLogger::EndTest, CWTTLogger::StartTestWithResID


CWTTLogger::GetContext

Retrieves the current context of the logger object.

HRESULT GetContext (
   LPWSTR pwszContext,
   LPWSTR pwszParentContext
);

Parameters

pwszContext

[in] Current context of the logger object.

pwszParentContext

[in] Parent context of the logger object.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Header

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++) CWTTLogger::ClearContext CWTTLogger::SetContext


CWTTLogger::GetPFRollupStats

Retrieves the current pass-fail statistics.

HRESULT GetPFRollupStats (
   PWTTLOGROLLUPINFO pWTTPFStats
);

Parameters

pWTTPFStats
[in] Pointer to a structure containing the statistics. The structure has the following definition:

typedef struct {

ULONG ulTotal; // Total number of test cases

ULONG ulPassed; // Number of test cases that passed

ULONG ulFailed; // Number of test cases that failed

ULONG ulBlocked; // Number of test cases that were blocked

ULONG ulWarned; // Number of warnings

ULONG ulSkipped; // Number of test cases that were skipped

} WTTLOGROLLUPINFO, * PWTTLOGROLLUPINFO;

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

Comments

To retrieve the current pass-fail statistics, you must create an empty structure as defined above and call GetPFRollupStats, which passes DTM Logger a pointer the structure. DTM Logger will then populate the structure.

See Also

CWTTLogger Class (C++)


CWTTLogger::RemoveErrorFromErrorList

Deletes the specified error from a list of known errors.

HRESULT WTTLogRemoveErrorFromErrorList (
   DWORD dwErrorToRemove,
   DWORD dwErrorType,
   DWORD dwErrorList
);

Parameters

dwErrorToRemove
[in] Error code to remove.

dwErrorType
[in] Type of the error. This is one of the following values:
WTT_ERROR_TYPE_HRESULT
WTT_ERROR_TYPE_NTSTATUS
WTT_ERROR_TYPE_WIN32
WTT_ERROR_TYPE_BOOL

dwErrorList
[in] Error list to remove. This is one of the following values:
WTT_ERROR_LIST_EXPECTED
WTT_ERROR_LIST_BREAKON

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++), CWTTLogger::AddErrorToErrorList, CWTTLogger::ClearErrorList, Error lists


CWTTLogger::SetContext

Sets the current context of the logger object for all subsequent traces.

HRESULT SetContext (
   LPWSTR pwszCurrentContext,
   LPWSTR pwszParentContext
);

Parameters

pwszCurrentContext
[in] Current context of the logger object.

pwszParentContext
[in] Parent context of the logger object.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++)

CWTTLogger::ClearContext

CWTTLogger::GetContext


CWTTLogger::SetDeviceOption

Sets the given options for the specified device.

HRESULT SetDeviceOption (
   LONG hDevice,
   LPWSTR pwszDeviceName,
   LPWSTR pwszDeviceOptions
);

Parameters

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1 | hDevice2
pwszDeviceName

[in] Name of the device.

pwszDeviceOptions
[in] String containing the options to set.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library: WTTLog.dll

See Also

CWTTLogger Class (C++)

CWTTLogger::SetDeviceTraceLevel

CWTTLogger::SetDeviceTracePriority


CWTTLogger::SetDeviceTraceLevel

Sets the specified device trace level for all subsequent traces.

HRESULT SetDeviceTraceLevel (
   DWORD dwTraceLvl,
   LONG hDevice
);

Parameters

dwTraceLvl
[in] Trace level to be set. This should be one of the following values:
  • WTT_LVL_MSG – Trace a user-define message. This is the most commonly used trace. If all traces within the context of a particular test case are messages, function entry, function exit, TCM information, or machine information, the test case will pass.
  • WTT_LVL_ERR – Trace an error. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_ASSERT – Trace an assertion. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_INVALID_PARAM – Trace an invalid parameter. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_BUG – Trace a known bug. This causes the logger (in the user mode) to log a test case as blocked, unless the user declares the test case as skipped.
  • WTT_LVL_BREAK – Trace a debug break. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_WARN – Trace a warning message. This causes the logger (in the user mode) to log the test case as warned, unless an error or bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_FUNCTION_ENTRY – Trace the function entry point. It has no effect on the test case result.
  • WTT_LVL_FUNCTION_EXIT – Trace the function exit point. It has no effect on the test case result.
  • WTT_LVL_START_TEST – Trace the start of a test case. This marks the beginning of a test case and sets a new context whose name is the current test case name. However, it is recommended that the user should call the StartTest method instead of using this level.
  • WTT_LVL_END_TEST – Trace the end of a test case. This marks the end of a test case and clears a new context whose name is the current test case name. It also updates the internal pass-fail counter according to the pass-fail mode and the previous traces. However, it is recommended that user should call the EndTest method instead of using this level.
  • WTT_LVL_TCMINFO – Sets the Tactics fields. It has no effect on the test case result.
  • WTT_LVL_MACHINEINFO – Sets machine-related test case fields for Tactics. It has no effect on the test case result
  • WTT_LVL_ROLLUP – Trace the test suite roll-up information. If the pass-fail mode is set to user, then the user plug-in must provide its own pass-fail count. Otherwise, DTM Logger will overwrite the counters provided by the user and use its internal counts. However, this does not cause the WTT execution agent (job agent) to perform a rollup operation.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

Comments

CWTTLogger Class (C++), CWTTLogger::EnableTraceLevels, CWTTLogger::DisableTraceLevels, CWTTLogger::SetDeviceTracePriority

See Also

© 2006 Microsoft Corporation
Send feedback on this topic
DTM Releases
Built on April 19, 2006
Build machine: CAPEBUILD


CWTTLogger::SetDeviceTracePriority

Sets the specified device trace priority for all subsequent traces.

HRESULT SetDeviceTracePriority (
   DWORD dwTracePri,
   LONG hDevice
);

Parameters

dwTracePri
[in] Priority of the trace. This should be one of the following values:
WTT_TRACE_PRIORITY_HIGH_CLASS
WTT_TRACE_PRIORITY_MEDIUM_CLASS
WTT_TRACE_PRIORITY_LOW_CLASS
WTT_TRACE_PRIORITY_RESERVED_CLASS
WTT_TRACE_PRIORITY_USER_CLASS

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++), CWTTLogger::SetDeviceTraceLevel


CWTTLogger::StartTest

Traces the start of a test case.

HRESULT StartTest (
   LPWSTR pwszTestName,
   LONG hDevice
);

Parameters

pwszTestName
[in] Name of the test case.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++), CWTTLogger::EndTest, CWTTLogger::StartTestEx, CWTTLogger::StartTestWithResID


CWTTLogger::StartTestEx

Traces the start of a test case and allows the user to specify a GUID-based test ID and a test hierarchy.

HRESULTStartTestEx (
   LPWSTR pwszTUID,
   LPWSTR pwszTestName,
   DWORD dwTestType,
   LPWSTR pwszParentTUID,
   LPWSTR pwszParentTestName,
   LONG hDevice
);

Parameters

pwszTUID
[in] GUID (global universal identification) for the test case.

pwszTestName
[in] Name of the test case.

dwTestType
[in] Type of the test case. This is one of the following values:
WTTLOG_TESTCASE_TYPE_NOPARENT
WTTLOG_TESTCASE_TYPE_ISCHILD
WTTLOG_TESTCASE_TYPE_ISSIBLING
WTTLOG_TESTCASE_TYPE_SPECIFYPARENT

pwszParentTUID
[in] GUID for the parent test.

pwszParentTestName
[in] Name of the parent test.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Example

Log.StartTestEx (

L"b55de776-ea89-4dbe-9abd-df2041040cd7", // GUID of the test case

L"This is a sample test," // optional test case name,

WTTLOG_TESTCASE_TYPE_NOPARENT, // this is an independent test case

NULL, // GUID of the parent test case

NULL, // optional name of the parent test case

hDevice

);

Log.EndTestEx (

WTT_TESTCASE_RESULT_PASS, // test case result

L"b55de776-ea89-4dbe-9abd-df2041040cd7", // GUID of the test case

L"This is a sample test", // optional test case name,

NULL, // GUID of the parent test case

NULL, // optional name of the parent test case

hDevices

);

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++), CWTTLogger::EndTestEx, CWTTLogger::StartTest


CWTTLogger::StartTestWithResID

Traces the start of a test case using the specified resource ID.

HRESULTStartTestWithResID (
   UINT uiResID,
   LONG hDevice
);

Parameters

uiResID
[in] Identifier of the resource.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++), CWTTLogger::StartTest, CWTTLogger::EndTestWithResID


CWTTLogger::Trace

Logs a trace of the specified device at the given trace level.

HRESULT Trace (
   DWORD dwLevel,
   LONG hDevice,
   ...
);

Parameters

dwLevel
[in] Trace level. This should be one of the following values:
  • WTT_LVL_MSG – Trace a user-define message. This is the most commonly used trace. If all traces within the context of a particular test case are messages, function entry, function exit, TCM information, or machine information, the test case will pass.
  • WTT_LVL_ERR – Trace an error. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_ASSERT – Trace an assertion. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_INVALID_PARAM – Trace an invalid parameter. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_BUG – Trace a known bug. This causes the logger (in the user mode) to log a test case as blocked, unless the user declares the test case as skipped.
  • WTT_LVL_BREAK – Trace a debug break. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_WARN – Trace a warning message. This causes the logger (in the user mode) to log the test case as warned, unless an error or bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_FUNCTION_ENTRY – Trace the function entry point. It has no effect on the test case result.
  • WTT_LVL_FUNCTION_EXIT – Trace the function exit point. It has no effect on the test case result.
  • WTT_LVL_START_TEST – Trace the start of a test case. This marks the beginning of a test case and sets a new context whose name is the current test case name. However, it is recommended that the user should call the StartTest method instead of using this level.
  • WTT_LVL_END_TEST – Trace the end of a test case. This marks the end of a test case and clears a new context whose name is the current test case name. It also updates the internal pass-fail counter according to the pass-fail mode and the previous traces. However, it is recommended that user should call the EndTest method instead of using this level.
  • WTT_LVL_TCMINFO – Sets the Tactics fields. It has no effect on the test case result.
  • WTT_LVL_MACHINEINFO – Sets machine-related test case fields for Tactics. It has no effect on the test case result
  • WTT_LVL_ROLLUP – Trace the test suite roll-up information. If the pass-fail mode is set to user, then the user plug-in must provide its own pass-fail count. Otherwise, DTM Logger will overwrite the counters provided by the user and use its internal counts. However, this does not cause the WTT execution agent (job agent) to perform a rollup operation.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

...
[in] Specifies one or more optional arguments that depends on the trace level specified in the dwLevel parameter. For information about the arguments required for each trace level, see Trace level.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++), CWTTLogger::UserDefinedTrace, CWTTLogger::TraceV, CWTTLogger::TraceEx, CWTTLogger::TraceMsg


CWTTLogger::TraceEx

Logs a trace of the specified device at the given trace level using an XML-formatted data string.

HRESULT TraceEx (
   DWORD dwLevel,
   DWORD dwPriority,
   LONG hDevice,
   LPWSTR pwszUserXML,
   ...
);

Parameters

dwLevel
[in] Trace level. This should be one of the following values:
  • WTT_LVL_MSG – Trace a user-define message. This is the most commonly used trace. If all traces within the context of a particular test case are messages, function entry, function exit, TCM information, or machine information, the test case will pass.
  • WTT_LVL_ERR – Trace an error. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_ASSERT – Trace an assertion. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_INVALID_PARAM – Trace an invalid parameter. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_BUG – Trace a known bug. This causes the logger (in the user mode) to log a test case as blocked, unless the user declares the test case as skipped.
  • WTT_LVL_BREAK – Trace a debug break. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_WARN – Trace a warning message. This causes the logger (in the user mode) to log the test case as warned, unless an error or bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_FUNCTION_ENTRY – Trace the function entry point. It has no effect on the test case result.
  • WTT_LVL_FUNCTION_EXIT – Trace the function exit point. It has no effect on the test case result.
  • WTT_LVL_START_TEST – Trace the start of a test case. This marks the beginning of a test case and sets a new context whose name is the current test case name. However, it is recommended that the user should call the StartTest method instead of using this level.
  • WTT_LVL_END_TEST – Trace the end of a test case. This marks the end of a test case and clears a new context whose name is the current test case name. It also updates the internal pass-fail counter according to the pass-fail mode and the previous traces. However, it is recommended that user should call the EndTest method instead of using this level.
  • WTT_LVL_TCMINFO – Sets the Tactics fields. It has no effect on the test case result.
  • WTT_LVL_MACHINEINFO – Sets machine-related test case fields for Tactics. It has no effect on the test case result
  • WTT_LVL_ROLLUP – Trace the test suite roll-up information. If the pass-fail mode is set to user, then the user plug-in must provide its own pass-fail count. Otherwise, DTM Logger will overwrite the counters provided by the user and use its internal counts. However, this does not cause the WTT execution agent (job agent) to perform a rollup operation.

dwPriority
[in] Priority of the trace. This should be one of the following values:
WTT_TRACE_PRIORITY_HIGH_CLASS
WTT_TRACE_PRIORITY_MEDIUM_CLASS
WTT_TRACE_PRIORITY_LOW_CLASS
WTT_TRACE_PRIORITY_RESERVED_CLASS
WTT_TRACE_PRIORITY_USER_CLASS

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

pwszUserXML
[in] XML-formatted string defined by the user.

...
[in] Specifies one or more optional arguments that depends on the trace level specified in the dwLevel parameter. For information about the arguments required for each trace level, see Trace level.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++), CWTTLogger::Trace, CWTTLogger::TraceExV


CWTTLogger::TraceExV

Logs a trace of the specified device at the given trace level using an XML-formatted data string and a prepared argument list.

HRESULT TraceExV (
   DWORD dwLevel,
   DWORD dwPriority,
   LONG hDevice,
   LPWSTR pwszUserXML,
   va_list VarArgs
);

Parameters

dwLevel
[in] Trace level. This should be one of the following values:
  • WTT_LVL_MSG – Trace a user-define message. This is the most commonly used trace. If all traces within the context of a particular test case are messages, function entry, function exit, TCM information, or machine information, the test case will pass.
  • WTT_LVL_ERR – Trace an error. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_ASSERT – Trace an assertion. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_INVALID_PARAM – Trace an invalid parameter. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_BUG – Trace a known bug. This causes the logger (in the user mode) to log a test case as blocked, unless the user declares the test case as skipped.
  • WTT_LVL_BREAK – Trace a debug break. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_WARN – Trace a warning message. This causes the logger (in the user mode) to log the test case as warned, unless an error or bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_FUNCTION_ENTRY – Trace the function entry point. It has no effect on the test case result.
  • WTT_LVL_FUNCTION_EXIT – Trace the function exit point. It has no effect on the test case result.
  • WTT_LVL_START_TEST – Trace the start of a test case. This marks the beginning of a test case and sets a new context whose name is the current test case name. However, it is recommended that the user should call the StartTest method instead of using this level.
  • WTT_LVL_END_TEST – Trace the end of a test case. This marks the end of a test case and clears a new context whose name is the current test case name. It also updates the internal pass-fail counter according to the pass-fail mode and the previous traces. However, it is recommended that user should call the EndTest method instead of using this level.
  • WTT_LVL_TCMINFO – Sets the Tactics fields. It has no effect on the test case result.
  • WTT_LVL_MACHINEINFO – Sets machine-related test case fields for Tactics. It has no effect on the test case result
  • WTT_LVL_ROLLUP – Trace the test suite roll-up information. If the pass-fail mode is set to user, then the user plug-in must provide its own pass-fail count. Otherwise, DTM Logger will overwrite the counters provided by the user and use its internal counts. However, this does not cause the WTT execution agent (job agent) to perform a rollup operation.

dwPriority
[in] Priority of the trace. This should be one of the following values:
WTT_TRACE_PRIORITY_HIGH_CLASS
WTT_TRACE_PRIORITY_MEDIUM_CLASS
WTT_TRACE_PRIORITY_LOW_CLASS
WTT_TRACE_PRIORITY_RESERVED_CLASS
WTT_TRACE_PRIORITY_USER_CLASS

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

pwszUserXML
[in] XML-formatted string defined by the user.

VarArgs
[in] Prepared list of variable arguments as required for the specified trace level. For information about the arguments required for each trace level, see Trace level.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++), CWTTLogger::Trace, CWTTLogger::TraceEx


CWTTLogger::TraceMachineInfo

Logs a trace of the the OS where the test is run.

HRESULT TraceMsg (
   LONG hDevice,
   LPWSTR pwszUserDefinedData
);

Parameters

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

pwszUserDefinedData
[in] User-defined data. Ignored in the current version.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Example

//

// Collect machine information

//

Log.TraceMachineInfo (

hDevice,

NULL

);

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++), CWTTLogger::Trace


CWTTLogger::TraceMsg

Logs a trace of the specified device at the user-defined trace level and a given priority.

HRESULT TraceMsg (
   LONG hDevice,
   LPWSTR pwszUserDefinedLevel,
   DWORD dwPriority,
   ...
);

Parameters

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

pwszUserDefinedLevel
[in] User-defined trace level.

dwPriority
[in] Priority of the trace. This should be one of the following values:
WTT_TRACE_PRIORITY_HIGH_CLASS
WTT_TRACE_PRIORITY_MEDIUM_CLASS
WTT_TRACE_PRIORITY_LOW_CLASS
WTT_TRACE_PRIORITY_RESERVED_CLASS
WTT_TRACE_PRIORITY_USER_CLASS

...
[in] Specifies one or more optional arguments that depends on the user-define trace level.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++), CWTTLogger::Trace, CWTTLogger::TraceMsg


CWTTLogger::TraceMsgV

Logs a trace of the specified device at the user-defined trace level and a given priority using a prepared argument list.

HRESULT TraceMsgV (
   LONG hDevice,
   LPWSTR pwszUserDefinedLevel,
   DWORD dwPriority,
   va_list VarArgs
);

Parameters

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1 | hDevice2
pwszUserDefinedLevel

[in] User-defined trace level.

dwPriority
[in] Priority of the trace. This should be one of the following values:
WTT_TRACE_PRIORITY_HIGH_CLASS
WTT_TRACE_PRIORITY_MEDIUM_CLASS
WTT_TRACE_PRIORITY_LOW_CLASS
WTT_TRACE_PRIORITY_RESERVED_CLASS
WTT_TRACE_PRIORITY_USER_CLASS
VarArgs

[in] Prepared list of variable arguments as required for the specified trace level. For information about the arguments required for each trace level, see Trace Level.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Header

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++) CWTTLogger::Trace CWTTLogger::TraceMsg


CWTTLogger::TraceV

Logs a trace of the specified device at the given trace level using a prepared argument list.

HRESULT TraceV (
   DWORD dwLevel,
   LONG hDevice,
   va_list VarArgs
);

Parameters

dwLevel
[in] Trace level. This should be one of the following values:
  • WTT_LVL_MSG – Trace a user-define message. This is the most commonly used trace. If all traces within the context of a particular test case are messages, function entry, function exit, TCM information, or machine information, the test case will pass.
  • WTT_LVL_ERR – Trace an error. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_ASSERT – Trace an assertion. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_INVALID_PARAM – Trace an invalid parameter. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_BUG – Trace a known bug. This causes the logger (in the user mode) to log a test case as blocked, unless the user declares the test case as skipped.
  • WTT_LVL_BREAK – Trace a debug break. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_WARN – Trace a warning message. This causes the logger (in the user mode) to log the test case as warned, unless an error or bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_FUNCTION_ENTRY – Trace the function entry point. It has no effect on the test case result.
  • WTT_LVL_FUNCTION_EXIT – Trace the function exit point. It has no effect on the test case result.
  • WTT_LVL_START_TEST – Trace the start of a test case. This marks the beginning of a test case and sets a new context whose name is the current test case name. However, it is recommended that the user should call the StartTest method instead of using this level.
  • WTT_LVL_END_TEST – Trace the end of a test case. This marks the end of a test case and clears a new context whose name is the current test case name. It also updates the internal pass-fail counter according to the pass-fail mode and the previous traces. However, it is recommended that user should call the EndTest method instead of using this level.
  • WTT_LVL_TCMINFO – Sets the Tactics fields. It has no effect on the test case result.
  • WTT_LVL_MACHINEINFO – Sets machine-related test case fields for Tactics. It has no effect on the test case result
  • WTT_LVL_ROLLUP – Trace the test suite roll-up information. If the pass-fail mode is set to user, then the user plug-in must provide its own pass-fail count. Otherwise, DTM Logger will overwrite the counters provided by the user and use its internal counts. However, this does not cause the WTT execution agent (job agent) to perform a rollup operation.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

VarArgs
[in] Prepared list of variable arguments as required for the specified trace level. For information about the arguments required for each trace level, see Trace level.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

Comments

This method is similar to the Trace method, except that it takes a prepared variable argument list as its third variable.

See Also

CWTTLogger Class (C++), CWTTLogger::Trace, CWTTLogger::TraceEx


CWTTLogger::UserDefinedTrace

Logs trace data using a user-defined trace level.

HRESULT UserDefinedTrace (
   LPCWSTR pcwszUserLevel,
   LONG hDevice,
   DWORD dwBaseLevel,
   DWORD dwPriority,
   ...
);

Parameters

pcwszUserLevel
[in] User-defined trace level.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

dwBaseLevel
[in] Base trace level. This should be one of the following values:
  • WTT_LVL_MSG – Trace a user-define message. This is the most commonly used trace. If all traces within the context of a particular test case are messages, function entry, function exit, TCM information, or machine information, the test case will pass.
  • WTT_LVL_ERR – Trace an error. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_ASSERT – Trace an assertion. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_INVALID_PARAM – Trace an invalid parameter. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_BUG – Trace a known bug. This causes the logger (in the user mode) to log a test case as blocked, unless the user declares the test case as skipped.
  • WTT_LVL_BREAK – Trace a debug break. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_WARN – Trace a warning message. This causes the logger (in the user mode) to log the test case as warned, unless an error or bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_FUNCTION_ENTRY – Trace the function entry point. It has no effect on the test case result.
  • WTT_LVL_FUNCTION_EXIT – Trace the function exit point. It has no effect on the test case result.
  • WTT_LVL_START_TEST – Trace the start of a test case. This marks the beginning of a test case and sets a new context whose name is the current test case name. However, it is recommended that the user should call the StartTest method instead of using this level.
  • WTT_LVL_END_TEST – Trace the end of a test case. This marks the end of a test case and clears a new context whose name is the current test case name. It also updates the internal pass-fail counter according to the pass-fail mode and the previous traces. However, it is recommended that user should call the EndTest method instead of using this level.
  • WTT_LVL_TCMINFO – Sets the Tactics fields. It has no effect on the test case result.
  • WTT_LVL_MACHINEINFO – Sets machine-related test case fields for Tactics. It has no effect on the test case result
  • WTT_LVL_ROLLUP – Trace the test suite roll-up information. If the pass-fail mode is set to user, then the user plug-in must provide its own pass-fail count. Otherwise, DTM Logger will overwrite the counters provided by the user and use its internal counts. However, this does not cause the WTT execution agent (job agent) to perform a rollup operation.

dwPriority
[in] Priority of the trace. This should be one of the following values:
WTT_TRACE_PRIORITY_HIGH_CLASS
WTT_TRACE_PRIORITY_MEDIUM_CLASS
WTT_TRACE_PRIORITY_LOW_CLASS
WTT_TRACE_PRIORITY_RESERVED_CLASS
WTT_TRACE_PRIORITY_USER_CLASS

...
[in] Specifies one or more optional arguments that depends on the trace level specified in the dwBaseLevel parameter. For information about the arguments required for each trace level, see Trace level.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Remarks

In order to trace user-defined trace levels in the log, you must first enable them. You enable custom trace levels on a device by using a device string, such as "$LogFile:EnableLvl=MyTrace".

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++), CWTTLogger::Trace, CWTTLogger::UserDefinedTraceV, CWTTLogger::UserDefinedTraceEx


CWTTLogger::UserDefinedTraceEx

Logs trace data using a user-defined trace level and an XML-formatted data string.

HRESULT UserDefinedTraceEx (
   LPCWSTR pcwszUserLevel,
   LONG hDevice,
   DWORD dwBaseLevel,
   DWORD dwPriority,
   LPWSTR pwszUserXML,
   ...
);

Parameters

pcwszUserLevel
[in] User-defined trace level.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

dwBaseLevel
[in] Base trace level. This should be one of the following values:
  • WTT_LVL_MSG – Trace a user-define message. This is the most commonly used trace. If all traces within the context of a particular test case are messages, function entry, function exit, TCM information, or machine information, the test case will pass.
  • WTT_LVL_ERR – Trace an error. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_ASSERT – Trace an assertion. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_INVALID_PARAM – Trace an invalid parameter. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_BUG – Trace a known bug. This causes the logger (in the user mode) to log a test case as blocked, unless the user declares the test case as skipped.
  • WTT_LVL_BREAK – Trace a debug break. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_WARN – Trace a warning message. This causes the logger (in the user mode) to log the test case as warned, unless an error or bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_FUNCTION_ENTRY – Trace the function entry point. It has no effect on the test case result.
  • WTT_LVL_FUNCTION_EXIT – Trace the function exit point. It has no effect on the test case result.
  • WTT_LVL_START_TEST – Trace the start of a test case. This marks the beginning of a test case and sets a new context whose name is the current test case name. However, it is recommended that the user should call the StartTest method instead of using this level.
  • WTT_LVL_END_TEST – Trace the end of a test case. This marks the end of a test case and clears a new context whose name is the current test case name. It also updates the internal pass-fail counter according to the pass-fail mode and the previous traces. However, it is recommended that user should call the EndTest method instead of using this level.
  • WTT_LVL_TCMINFO – Sets the Tactics fields. It has no effect on the test case result.
  • WTT_LVL_MACHINEINFO – Sets machine-related test case fields for Tactics. It has no effect on the test case result
  • WTT_LVL_ROLLUP – Trace the test suite roll-up information. If the pass-fail mode is set to user, then the user plug-in must provide its own pass-fail count. Otherwise, DTM Logger will overwrite the counters provided by the user and use its internal counts. However, this does not cause the WTT execution agent (job agent) to perform a rollup operation.

dwPriority
[in] Priority of the trace. This should be one of the following values:
WTT_TRACE_PRIORITY_HIGH_CLASS
WTT_TRACE_PRIORITY_MEDIUM_CLASS
WTT_TRACE_PRIORITY_LOW_CLASS
WTT_TRACE_PRIORITY_RESERVED_CLASS
WTT_TRACE_PRIORITY_USER_CLASS

pwszUserXML
[in] XML-formatted string defined by the user.

...
[in] Specifies one or more optional arguments that depends on the trace level specified in the dwBaseLevel parameter. For information about the arguments required for each trace level, see Trace level.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Remarks

In order to trace user-defined trace levels in the log, you must first enable them. You enable custom trace levels on a device by using a device string, such as "$LogFile:EnableLvl=MyTrace".

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class, UserDefinedTrace, UserDefinedTraceExV


CWTTLogger::UserDefinedTraceExV

Logs trace data using a user-defined trace level and an XML-formatted data string.

HRESULT UserDefinedTraceExV (
   LPCWSTR pcwszUserLevel,
   LONG hDevice,
   DWORD dwBaseLevel,
   DWORD dwPriority,
   LPWSTR pwszUserXML,
   va_list VarArgs
);

Parameters

pcwszUserLevel
[in] User-defined trace level.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

dwBaseLevel
[in] Base trace level. This should be one of the following values:
  • WTT_LVL_MSG – Trace a user-define message. This is the most commonly used trace. If all traces within the context of a particular test case are messages, function entry, function exit, TCM information, or machine information, the test case will pass.
  • WTT_LVL_ERR – Trace an error. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_ASSERT – Trace an assertion. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_INVALID_PARAM – Trace an invalid parameter. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_BUG – Trace a known bug. This causes the logger (in the user mode) to log a test case as blocked, unless the user declares the test case as skipped.
  • WTT_LVL_BREAK – Trace a debug break. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_WARN – Trace a warning message. This causes the logger (in the user mode) to log the test case as warned, unless an error or bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_FUNCTION_ENTRY – Trace the function entry point. It has no effect on the test case result.
  • WTT_LVL_FUNCTION_EXIT – Trace the function exit point. It has no effect on the test case result.
  • WTT_LVL_START_TEST – Trace the start of a test case. This marks the beginning of a test case and sets a new context whose name is the current test case name. However, it is recommended that the user should call the CWTTLogger::StartTest method instead of using this level.
  • WTT_LVL_END_TEST – Trace the end of a test case. This marks the end of a test case and clears a new context whose name is the current test case name. It also updates the internal pass-fail counter according to the pass-fail mode and the previous traces. However, it is recommended that user should call the CWTTLogger::EndTest method instead of using this level.
  • WTT_LVL_TCMINFO – Sets the Tactics fields. It has no effect on the test case result.
  • WTT_LVL_MACHINEINFO – Sets machine-related test case fields for Tactics. It has no effect on the test case result
  • WTT_LVL_ROLLUP – Trace the test suite roll-up information. If the pass-fail mode is set to user, then the user plug-in must provide its own pass-fail count. Otherwise, DTM Logger will overwrite the counters provided by the user and use its internal counts. However, this does not cause the WTT execution agent (job agent) to perform a rollup operation.

dwPriority
[in] Priority of the trace. This should be one of the following values:
WTT_TRACE_PRIORITY_HIGH_CLASS
WTT_TRACE_PRIORITY_MEDIUM_CLASS
WTT_TRACE_PRIORITY_LOW_CLASS
WTT_TRACE_PRIORITY_RESERVED_CLASS
WTT_TRACE_PRIORITY_USER_CLASS

pwszUserXML
[in] XML-formatted string defined by the user.

VarArgs
[in] Prepared list of variable arguments as required for the specified trace level. For information about the arguments required for each trace level, see Trace level.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Remarks

In order to trace user-defined trace levels in the log, you must first enable them. You enable custom trace levels on a device by using a device string, such as "$LogFile:EnableLvl=MyTrace".

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++), CWTTLogger::UserDefinedTraceV, CWTTLogger::UserDefinedTraceEx


CWTTLogger::UserDefinedTraceV

Logs trace data using a user-defined trace level and a prepared argument list.

HRESULT UserDefinedTraceV (
   LPCWSTR pcwszUserLevel,
   LONG hDevice,
   DWORD dwBaseLevel,
   DWORD dwPriority,
   va_list VarArgs
);

Parameters

pcwszUserLevel
[in] User-defined trace level.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

dwBaseLevel
[in] Base trace level. This should be one of the following values:
  • WTT_LVL_MSG – Trace a user-define message. This is the most commonly used trace. If all traces within the context of a particular test case are messages, function entry, function exit, TCM information, or machine information, the test case will pass.
  • WTT_LVL_ERR – Trace an error. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_ASSERT – Trace an assertion. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_INVALID_PARAM – Trace an invalid parameter. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_BUG – Trace a known bug. This causes the logger (in the user mode) to log a test case as blocked, unless the user declares the test case as skipped.
  • WTT_LVL_BREAK – Trace a debug break. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_WARN – Trace a warning message. This causes the logger (in the user mode) to log the test case as warned, unless an error or bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_FUNCTION_ENTRY – Trace the function entry point. It has no effect on the test case result.
  • WTT_LVL_FUNCTION_EXIT – Trace the function exit point. It has no effect on the test case result.
  • WTT_LVL_START_TEST – Trace the start of a test case. This marks the beginning of a test case and sets a new context whose name is the current test case name. However, it is recommended that the user should call the StartTest method instead of using this level.
  • WTT_LVL_END_TEST – Trace the end of a test case. This marks the end of a test case and clears a new context whose name is the current test case name. It also updates the internal pass-fail counter according to the pass-fail mode and the previous traces. However, it is recommended that user should call the EndTest method instead of using this level.
  • WTT_LVL_TCMINFO – Sets the Tactics fields. It has no effect on the test case result.
  • WTT_LVL_MACHINEINFO – Sets machine-related test case fields for Tactics. It has no effect on the test case result
  • WTT_LVL_ROLLUP – Trace the test suite roll-up information. If the pass-fail mode is set to user, then the user plug-in must provide its own pass-fail count. Otherwise, DTM Logger will overwrite the counters provided by the user and use its internal counts. However, this does not cause the WTT execution agent (job agent) to perform a rollup operation.

dwPriority
[in] Priority of the trace. This should be one of the following values:
WTT_TRACE_PRIORITY_HIGH_CLASS
WTT_TRACE_PRIORITY_MEDIUM_CLASS
WTT_TRACE_PRIORITY_LOW_CLASS
WTT_TRACE_PRIORITY_RESERVED_CLASS
WTT_TRACE_PRIORITY_USER_CLASS

VarArgs
[in] Prepared list of variable arguments as required for the specified trace level. For information about the arguments required for each trace level, see Trace level.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Remarks

In order to trace user-defined trace levels in the log, you must first enable them. You enable custom trace levels on a device by using a device string, such as "$LogFile:EnableLvl=MyTrace".

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

CWTTLogger Class (C++), CWTTLogger::UserDefinedTrace, CWTTLogger::UserDefinedTraceEx


IWTTLog Interface (COM)

Implements a COM interface for logging messages and errors.

Public Methods

AddErrorToErrorList | Adds a specified error to a list of known errors.
Assert | Checks the specified condition and, if the condition is false, fails the test case unless a trace is logged or the user specifically declares the test case to be skipped.
CheckResult | Checks a specified result and logs an error if the result shows a failure.
CheckResultEx | Checks a specified result against a target result and logs an error if both the value and type match.
ClearErrorList | Removes all errors of the specified type from a given list of known errors.
CloseLogDevice | Closes a log device topology specified by either the device string or the handle.
CreateLogDevice | Creates a log device topology according to the device string.
EndTest | Traces the end of a test case, clears current test case context, and sets it to the parent context.
EndTestEx | Traces the end of a test case, and allows the user to specify a GUID-based test ID and a test hierarchy.
GetCurrentContext | Retrieves the current context of the logger object.
RemoveErrorFromErrorList | Deletes the specified error from a list of known errors.
SetContext | Sets the current context of the logger object for all subsequent traces.
SetDeviceOption | Sets the current context of the logger object for all subsequent traces.
StartTest | Traces the start of a test case.
StartTestEx | Traces the start of a test case and allows the user to specify a GUID-based test ID and a test hierarchy.
Trace | Logs a trace of the specified device at the given trace level.
TraceMachineInfo | Sets the given information about the specified trace computer.
UserDefinedTrace | Logs trace data using a user-defined trace level.

Requirements

IDL file: Log.idl

Library: WTTLogCM.dll

See Also

CWTTLogger Class (C++), WTTLog Functions (C)


IWTTLog::AddErrorToErrorList

Adds the specified error type and error code to the given list of known errors.

HRESULT AddErrorToErrorList (
   DWORD dwErrorToAdd,
   WTTLOGGER_ERROR_TYPE dwErrorType,
   WTTLOGGER_ERROR_LIST dwErrorList
);

Parameters

dwErrorToAdd
[in] Error code to add.

dwErrorType
[in] Type of the error. This is one of the following values:
WTTLOG_ERROR_TYPE_HRESULT
WTTLOG_ERROR_TYPE_NTSTATUS
WTTLOG_ERROR_TYPE_WIN32
WTTLOG_ERROR_TYPE_BOOL

dwErrorList
[in] Identifies the list to which the error will be added. This is one of the following values:
WTTLOG_ERROR_LIST_EXPECTED
WTTLOG_ERROR_LIST_BREAKON

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

IDL File

Log.IDL

Library

WTTLogCM.dll

Comments

DTM Logger uses the Error lists to allow a test to pass even though the return value from a test function is an error. The CheckResult function compares the error type and error code passed to it with the know errors on the list. If the error is on the list, CheckResult returns S_OK indicating the test passed. If the error is not on the list, the test fails.

See Also

IWTTLog Interface (COM), IWTTLog::RemoveErrorFromErrorList, IWTTLog::ClearErrorList, Error lists


IWTTLog::Assert

Checks the specified condition and, if the condition is false, fails the test case unless a trace is logged or the user specifically declares the test case to be skipped.

HRESULT Assert (
   VARIANT_BOOL fCondition,
   BSTR bstrFile,
   UINT uiLine,
   BSTR bstrAssertMsg,
   LONG hDevice
);

Parameters

fCondition
[in] If true, prevents the test case from failing if the bug trace is not logged. If false, fails the test case unless the bug trace is logged.

bstrFile
[in] Name of the source file where the assert happened.

uiLine
[in] Line number within the source file where the assert happened.

bstrAssertMsg
[in] Text message of the assertion.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

IDL File

Log.IDL

Library

WTTLogCM.dll

See Also

IWTTLog Interface (COM), IWTTLog::Trace


IWTTLog::CheckResult

Checks a specified result and logs an error if the result shows a failure.

HRESULT CheckResult (
   DWORD dwResultToCheck,
   WTTLOGGER_ERROR_TYPE dwResultType,
   BSTR bstrFile,
   UINT uiLine,
   BSTR bstrErrMsg,
   LONG hDevice
);

Parameters

dwResultToCheck
[in] Identifies the result to check.

dwResultType
[in] Type of the result. This is one of the following values:
WTTLOG_ERROR_TYPE_HRESULT
WTTLOG_ERROR_TYPE_NTSTATUS
WTTLOG_ERROR_TYPE_WIN32
WTTLOG_ERROR_TYPE_BOOL

bstrFile
[in] Name of the source file where the assert happened.

uiLine
[in] Line number within the source file where the assert happened.

bstrErrMsg
[in] Text of the error message.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

IDL File

Log.IDL

Library

WTTLogCM.dll

See Also

IWTTLog Interface (COM), IWTTLog::CheckResultEx, Error lists


IWTTLog::CheckResultEx

Checks a specified result against a target result and logs an error if both the value and type match.

HRESULT CheckResultEx (
   DWORD dwResultToCheck,
   WTTLOGGER_ERROR_TYPE dwResultType,
   DWORD dwTargetResult,
   WTTLOGGER_ERROR_TYPE dwTargetType,
   BSTR bstrFile,
   UINT uiLine,
   BSTR bstrErrMsg,
   LONG hDevice
);

Parameters

dwResultToCheck
[in] Identifies the result to check.

dwResultType
[in] Type of the result. This is one of the following values:
WTTLOG_ERROR_TYPE_HRESULT
WTTLOG_ERROR_TYPE_NTSTATUS
WTTLOG_ERROR_TYPE_WIN32
WTTLOG_ERROR_TYPE_BOOL

dwTargetResult
[in] Target result against which to check.

dwTargetType
[in] Type of the target result. This is one of the following values:
WTTLOG_ERROR_TYPE_HRESULT
WTTLOG_ERROR_TYPE_NTSTATUS
WTTLOG_ERROR_TYPE_WIN32
WTTLOG_ERROR_TYPE_BOOL

bstrFile
[in] Name of the source file where the assert happened.

uiLine
[in] Line number within the source file where the assert happened.

bstrErrMsg
[in] Text message for the error.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

IDL File

Log.IDL

Library

WTTLogCM.dll

See Also

IWTTLog Interface (COM), IWTTLog::CheckResult, Error lists


IWTTLog::ClearErrorList

Removes all errors of the specified type from a given list of known errors.

HRESULT ClearErrorList (
   WTTLOGGER_ERROR_TYPE dwErrorType,
   WTTLOGGER_ERROR_LIST dwErrorList
);

Parameters

dwErrorType
[in] Type of the error to remove. This is one of the following values:
WTTLOG_ERROR_TYPE_HRESULT
WTTLOG_ERROR_TYPE_NTSTATUS
WTTLOG_ERROR_TYPE_WIN32
WTTLOG_ERROR_TYPE_BOOL

dwErrorList
[in] Error list to clear. This is one of the following values:
WTTLOG_ERROR_LIST_EXPECTED
WTTLOG_ERROR_LIST_BREAKON

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

IDL File

Log.IDL

Library

WTTLogCM.dll

See Also

IWTTLog Interface (COM), IWTTLog::AddErrorToErrorList, IWTTLog::RemoveErrorFromErrorList, Error lists


IWTTLog::CloseLogDevice

Closes a log device topology specified by either the device string or the handle.

HRESULT CloseLogDevice (
   BSTR    bstrLogDeviceName,
   LONG    hDevice
);

Parameters

bstrLogDeviceName
[in] Log device string, which has the following syntax:
$<device_type>:<parameter_list>($<child_device1>[; $<child_device2>; ...])
For more information about constructing a device string, see Device string.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

IDL File

Log.IDL

Library

WTTLogCM.dll

Comments

If the handle is specified, then the device string is ignored.

See Also

IWTTLog Interface (COM), IWTTLog::CloseLogDevice


IWTTLog::CreateLogDevice

Creates a log device topology according to the device string.

HRESULT CreateLogDevice (
   VARIANT vtDeviceStr,
   LONG* phDevice
);

Parameters

vtDeviceStr
[in] Log device string, which has the following syntax:
$<device_type>:<parameter_list>($<child_device1>[; $<child_device2>; ...])
For more information about constructing a device string, see Device string.

phDevice
[out] Pointer to a handle that represents the device tracing topology.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

IDL File

Log.IDL

Library

WTTLogCM.dll

See Also

IWTTLog Interface (COM), IWTTLog::CloseLogDevice


IWTTLog::EndTest

Traces the end of a test case, clears current test case context, and sets it to the parent context.

HRESULT EndTest (
   BSTR bstrTestName,
   WTTLOGGER_TEST_RESULT dwResult,
   BSTR bstrRepro,
   LONG hDevice
);

Parameters

bstrTestName
[in] Name of the test case.

dwResult
[in] Test case result. This must be one of the following values:
  • WTT_TESTCASE_RESULT_PASS – This value does NOT guarantee that the logger will log the test case as passed. If traces are logged that indicate an error, a warning, or so forth, the logger will automatically override this value.
  • WTT_TESTCASE_RESULT_WARN – This value does NOT guarantee that the logger will log the test case as warned. If traces are logged that indicate an error or so forth, the logger will automatically override this value.
  • WTT_TESTCASE_RESULT_FAIL – This value does NOT guarantee that the logger will log the test case as failed. If traces are logged that indicate a bug or if no error trace is logged, the logger will automatically override this value.
  • WTT_TESTCASE_RESULT_BLOCKED – This value guarantees that the logger will log the test case as blocked.
  • WTT_TESTCASE_RESULT_SKIPPED – This value guarantees that the logger will log the test case as skipped.

bstrRepro
[in] Repro line number rerunning the test. If NULL, DTM Logger will try to get the command line for the current process.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

IDL File

Log.IDL

Library

WTTLogCM.dll

See Also

IWTTLog Interface (COM), IWTTLog::EndTestEx, IWTTLog::StartTest


IWTTLog::EndTestEx

Traces the end of a test case, and allows the user to specify a GUID-based test ID and a test hierarchy.

HRESULT EndTestEx (
   WTTLOGGER_TEST_RESULT dwResult,
   BSTR bstrTUID,
   BSTR bstrTestName,
   BSTR bstrParentTUID,
   BSTR bstrParentTestName,
   LONG hDevice
);

Parameters

dwResult
[in] Test case result. This must be one of the following values:
  • WTT_TESTCASE_RESULT_PASS – This value does NOT guarantee that the logger will log the test case as passed. If traces are logged that indicate an error, a warning, or so forth, the logger will automatically override this value.
  • WTT_TESTCASE_RESULT_WARN – This value does NOT guarantee that the logger will log the test case as warned. If traces are logged that indicate an error or so forth, the logger will automatically override this value.
  • WTT_TESTCASE_RESULT_FAIL – This value does NOT guarantee that the logger will log the test case as failed. If traces are logged that indicate a bug or if no error trace is logged, the logger will automatically override this value.
  • WTT_TESTCASE_RESULT_BLOCKED – This value guarantees that the logger will log the test case as blocked.
  • WTT_TESTCASE_RESULT_SKIPPED – This value guarantees that the logger will log the test case as skipped.

bstrTUID
[in] GUID (global universal identification) for the test case.

bstrTestName
[in] Name of the test case.

bstrParentTUID
[in] GUID for the parent test case.

bstrParentTestName
[in] Name of the parent test case.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

IDL File

Log.IDL

Library

WTTLogCM.dll

See Also

IWTTLog Interface (COM), IWTTLog::EndTest, IWTTLog::StartTestEx


IWTTLog::GetCurrentContext

Retrieves the current context of the logger object.

HRESULT SetContext (
   BSTR   *pbstrCurrentContext
);

Parameters

pbstrCurrentContext
[out] Current context of the logger object.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

IDL File

Log.idl

Library

WTTLogCM.dll

See Also

IWTTLog Interface (COM)

IWTTLog::SetContext


IWTTLog::RemoveErrorFromErrorList

Deletes the specified error from a list of known errors.

HRESULT RemoveErrorFromErrorList (
   DWORD dwErrorToAdd,
   WTTLOGGER_ERROR_TYPE dwErrorType,
   WTTLOGGER_ERROR_LIST dwErrorList
);

Parameters

dwErrorToRemove
[in] Error code to remove.

dwErrorType
[in] Type of the error. This is one of the following values:
WTTLOG_ERROR_TYPE_HRESULT
WTTLOG_ERROR_TYPE_NTSTATUS
WTTLOG_ERROR_TYPE_WIN32
WTTLOG_ERROR_TYPE_BOOL

dwErrorList
[in] Error list to remove. This is one of the following values:
WTTLOG_ERROR_LIST_EXPECTED
WTTLOG_ERROR_LIST_BREAKON

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

IDL File

Log.IDL

Library

WTTLogCM.dll

See Also

IWTTLog Interface (COM), IWTTLog::AddErrorToErrorList, IWTTLog::ClearErrorList, Error lists


IWTTLog::SetContext

Sets the current context of the logger object for all subsequent traces.

HRESULT SetContext (
   BSTR   bstrContext,
   BSTR   bstrParentCTX
);

Parameters

bstrContext
[in] Current context of the logger object.

bstrParentCTX
[in] Parent context of the logger object.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

IDL File

Log.IDL

Library

WTTLogCM.dll

See Also

IWTTLog Interface (COM)


IWTTLog::SetDeviceOption

Sets the current context of the logger object for all subsequent traces.

HRESULT SetContext (
   LONG   hDevice,
   BSTR   bstrDeviceName,
   BSTR   bstrDeviceOptions
);

Parameters

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1 | hDevice2
bstrDeviceName
[in] Name of the device.
bstrDeviceOptions
[in] String containing the device options to set.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macho to check HRESULT values.

IDL File

Log.idl

Library

WTTLogCM.dll

See Also

IWTTLog Interface (COM)


IWTTLog::StartTest

Traces the start of a test case.

HRESULT StartTest (
   BSTR bstrTestName,
   LONG hDevice
);

Parameters

bstrTestName
[in] Name of the test case.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

IDL File

Log.IDL

Library

WTTLogCM.dll

See Also

IWTTLog Interface (COM), IWTTLog::EndTest, IWTTLog::StartTestEx


IWTTLog::StartTestEx

Traces the start of a test case and allows the user to specify a GUID-based test ID and a test hierarchy.

HRESULTStartTestEx (
   BSTR bstrTUID,
   BSTR bstrTestName,
   DWORD dwTestType,
   BSTR bstrParentTUID,
   BSTR bstrParentTestName,
   LONG hDevice
);

Parameters

bstrTUID
[in] GUID (global universal identification) for the test case.

bstrTestName
[in] Name of the test case.

dwTestType
[in] Type of the test case. This is one of the following values:
WTTLOG_TESTCASE_TYPE_NOPARENT
WTTLOG_TESTCASE_TYPE_ISCHILD
WTTLOG_TESTCASE_TYPE_ISSIBLING
WTTLOG_TESTCASE_TYPE_SPECIFYPARENT

bstrParentTUID
[in] GUID for the parent test.

bstrParentTestName
[in] Name of the parent test.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

IDL File

Log.IDL

Library

WTTLogCM.dll

See Also

IWTTLog Interface (COM), IWTTLog::EndTestEx, IWTTLog::StartTest


IWTTLog::Trace

Logs a trace of the specified device at the given trace level.

HRESULT Trace (
   WTTLOGGER_TRACE_LEVEL dwLevel,
   LONG hDevice,
   SAFEARRAY(VARIANT)* psaVarArgs
);

Parameters

dwLevel
[in] Trace level. This should be one of the following values:
  • WTTLOG_LVL_MSG – Trace a user-define message. This is the most commonly used trace. If all traces within the context of a particular test case are messages, function entry, function exit, TCM information, or machine information, the test case will pass.
  • WTTLOG_LVL_ERR – Trace an error. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTTLOG_LVL_ASSERT – Trace an assertion. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTTLOG_LVL_INVALID_PARAM – Trace an invalid parameter. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTTLOG_LVL_BUG – Trace a known bug. This causes the logger (in the user mode) to log a test case as blocked, unless the user declares the test case as skipped.
  • WTTLOG_LVL_BREAK – Trace a debug break. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTTLOG_LVL_WARN – Trace a warning message. This causes the logger (in the user mode) to log the test case as warned, unless an error or bug trace is logged or the user declares the test case as skipped.
  • WTTLOG_LVL_FUNCTION_ENTRY – Trace the function entry point. It has no effect on the test case result.
  • WTTLOG_LVL_FUNCTION_EXIT – Trace the function exit point. It has no effect on the test case result.
  • WTTLOG_LVL_START_TEST – Trace the start of a test case. This marks the beginning of a test case and sets a new context whose name is the current test case name. However, it is recommended that the user should call the StartTest method instead of using this level.
  • WTTLOG_LVL_END_TEST – Trace the end of a test case. This marks the end of a test case and clears a new context whose name is the current test case name. It also updates the internal pass-fail counter according to the pass-fail mode and the previous traces. However, it is recommended that user should call the EndTest method instead of using this level.
  • WTTLOG_LVL_TCMINFO – Sets the Tactics fields. It has no effect on the test case result.
  • WTTLOG_LVL_MACHINEINFO – Sets machine-related test case fields for Tactics. It has no effect on the test case result
  • WTTLOG_LVL_ROLLUP – Trace the test suite roll-up information. If the pass-fail mode is set to user, then the user plug-in must provide its own pass-fail count. Otherwise, DTM Logger will overwrite the counters provided by the user and use its internal counts. However, this does not cause the WTT execution agent (job agent) to perform a rollup operation.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

psaVarArgs
[in] Array of variable arguments (VARARG) as required for the specified trace level. For information about the arguments required for each trace level, see Trace Level.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

IDL File

Log.IDL

Library

WTTLogCM.dll

See Also

IWTTLog Interface (COM), IWTTLog::UserDefinedTrace


IWTTLog::TraceMachineInfo

Sets the given information about the specified trace computer.

HRESULT TraceMachineInfo (
   BSTR   bstrUserMachineInfo,
   LONG   hDevice
);

Parameters

bstrUserMachineInfo

[in] String containing the computer information to set.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1 | hDevice2

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

IDL File

Log.idl

Library

WTTLogCM.dll

See Also

IWTTLog Interface (COM)


IWTTLog::UserDefinedTrace

Logs trace data using a user-defined trace level.

HRESULT UserDefinedTrace (
   BSTR bstrUserLevel,
   LONG hDevice,
   WTTLOGGER_TRACE_LEVEL dwBaseLevel,
   WTTLOGGER_TRACE_PRIORITY dwPriority,
   SAFEARRAY(VARIANT)* psaVarArgs
);

Parameters

bstrUserLevel
[in] User-defined trace level.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

dwBaseLevel
[in] Base trace level. This should be one of the following values:
  • WTTLOG_LVL_MSG – Trace a user-define message. This is the most commonly used trace. If all traces within the context of a particular test case are messages, function entry, function exit, TCM information, or machine information, the test case will pass.
  • WTTLOG_LVL_ERR – Trace an error. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTTLOG_LVL_ASSERT – Trace an assertion. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTTLOG_LVL_INVALID_PARAM – Trace an invalid parameter. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTTLOG_LVL_BUG – Trace a known bug. This causes the logger (in the user mode) to log a test case as blocked, unless the user declares the test case as skipped.
  • WTTLOG_LVL_BREAK – Trace a debug break. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTTLOG_LVL_WARN – Trace a warning message. This causes the logger (in the user mode) to log the test case as warned, unless an error or bug trace is logged or the user declares the test case as skipped.
  • WTTLOG_LVL_FUNCTION_ENTRY – Trace the function entry point. It has no effect on the test case result.
  • WTTLOG_LVL_FUNCTION_EXIT – Trace the function exit point. It has no effect on the test case result.
  • WTTLOG_LVL_START_TEST – Trace the start of a test case. This marks the beginning of a test case and sets a new context whose name is the current test case name. However, it is recommended that the user should call the StartTest method instead of using this level.
  • WTTLOG_LVL_END_TEST – Trace the end of a test case. This marks the end of a test case and clears a new context whose name is the current test case name. It also updates the internal pass-fail counter according to the pass-fail mode and the previous traces. However, it is recommended that user should call the EndTest method instead of using this level.
  • WTTLOG_LVL_TCMINFO – Sets the Tactics fields. It has no effect on the test case result.
  • WTTLOG_LVL_MACHINEINFO – Sets machine-related test case fields for Tactics. It has no effect on the test case result
  • WTTLOG_LVL_ROLLUP – Trace the test suite roll-up information. If the pass-fail mode is set to user, then the user plug-in must provide its own pass-fail count. Otherwise, DTM Logger will overwrite the counters provided by the user and use its internal counts. However, this does not cause the WTT execution agent (job agent) to perform a rollup operation.

dwPriority
[in] Priority of the trace. This should be one of the following values:
WTTLOG_TRACE_PRIORITY_HIGH_CLASS
WTTLOG_TRACE_PRIORITY_MEDIUM_CLASS
WTTLOG_TRACE_PRIORITY_LOW_CLASS
WTTLOG_TRACE_PRIORITY_RESERVED_CLASS
WTTLOG_TRACE_PRIORITY_USER_CLASS

psaVarArgs
[in] Array of variable arguments (VARARG) as required for the specified trace level. For information about the arguments required for each trace level, see Trace Level.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Remarks

In order to trace user-defined trace levels in the log, you must first enable them. You enable custom trace levels on a device by using a device string, such as "$LogFile:EnableLvl=MyTrace".

IDL File

Log.IDL

Library

WTTLogCM.dll

See Also

IWTTLog Interface, Trace


WTTLog Functions (C)

These C functions represent an interface for logging messages and errors.

Functions

WTTLogAddErrorToErrorList | Add a known error to an error list.
WTTLogAssert | Checks the specified condition and, if the condition is false, fails the test case unless a trace is logged or the user specifically declares the test case to be skipped.
WTTLogCheckResult | Checks a specified result and logs an error if the result shows a failure.
WTTLogCheckResultEx | Checks a specified result against a target result and logs an error if both the value and type match.
WTTLogClearErrorList | Removes all errors of the specified type from a given list of known errors.
WTTLogCloseLogDevice | Closes a log device topology specified by either the device string or the handle.
WTTLogCreateLogDevice | Create a log device topology according to the device string.
WTTLogDisableTraceLevels | Disables the specified set of device trace levels.
WTTLogEnableTraceLevels | Enables the specified set of device trace levels.
WTTLogEndTest | Traces the end of a test case, clears current test case context, and sets it to the parent context.
WTTLogEndTestEx | Traces the end of a test case, and allows the user to specify a GUID-based test ID and a test hierarchy.
WTTLogGetContext | Retrieves the current context of the logger object.
WTTLogGetPFRollupStats | Retrieves the current pass-fail statistics.
WTTLogInit | Initializes the DTM Logger DLL.
WTTLogPFRollup | Initializes the pass-fail statistics to the specified values.
WTTLogRemoveErrorFromErrorList | Deletes the specified error from a list of known errors.
WTTLogSetContext | Sets the current context of the logger object for all subsequent traces.
WTTLogStartTest | Traces the start of a test case.
WTTLogStartTestEx | Traces the start of a test case and allows the user to specify a GUID-based test ID and a test hierarchy.
WTTLogTrace | Logs a trace of the specified device at the given trace level.
WTTLogTraceEx | Logs a trace of the specified device at the given trace level using an XML-formatted data string.
WTTLogTraceMachineInfo | Sets the specified computer as the trace machine.
WTTLogUninit | Removes the DTM Logger DLL from memory.
 | Logs trace data using a user-defined trace level.
WTTLogUserDefinedTraceEx | Logs trace data using a user-defined trace level and an XML-formatted data string.

Requirements

Header: Wttlogger.h

Library: WTTLog.dll

See Also

CWTTLogger Class (C++), IWTTLog Interface (COM)


WTTLogAddErrorToErrorList

Adds the specified error type and error code to the given list of known errors.

HRESULT WTTLogAddErrorToErrorList (
    IN DWORD  dwErrorToAdd,
    IN DWORD  dwErrorType,
    IN DWORD  dwErrorList
    )

Parameters

dwErrorToAdd
[IN][DWORD] – A 32-bit error code to be added to the list.

dwErrorType
[IN][DWORD] – Type of the error. This is one of the following values:
WTT_ERROR_TYPE_HRESULT
WTT_ERROR_TYPE_NTSTATUS
WTT_ERROR_TYPE_WIN32
WTT_ERROR_TYPE_BOOL

dwErrorList
[IN][DWORD] – Identifies the list to which the error will be added. This is one of the following values:
WTT_ERROR_LIST_EXPECTED
WTT_ERROR_LIST_BREAKON

Return Value

HRESULT

Headers

Wttlogger.h

Library

WTTLog.dll

Comments

DTM Logger uses the Error lists to allow a test to pass even though the return value from a test function is an error. The WTTLogCheckResult function compares the error type and error code passed to it with the know errors on the list. If the error is on the list, WTTLogCheckResult returns S_OK indicating the test passed. If the error is not on the list, the test fails.

See Also

WTTLogCheckResult, Error lists


WTTLogAssert

Checks the specified condition and, if the condition is false, fails the test case unless a trace is logged or the user specifically declares the test case to be skipped.

HRESULT WTTLogAssert (
   LONG hDevice,
   BOOL fCondition,
   LPWSTR pwszFile,
   UINT uiLine,
   LPWSTR pwszUserMsg
);

Parameters

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

fCondition
[in] If true, prevents the test case from failing if the bug trace is not logged. If false, fails the test case unless the bug trace is logged.

pwszFile
[in] Name of the source file where the assert happened.

uiLine
[in] Line number within the source file where the assert happened.

pwszUserMsg
[in] Text message of the assertion.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

WTTLog Functions (C), WTTLogTrace


WTTLogCheckResult

Checks a specified result and logs an error if the result shows a failure.

HRESULT WTTLogCheckResult (
   LONG    hDevice,
   DWORD   dwResultToCheck,
   DWORD   dwResultType,
   LPWSTR  pwszFile,
   ULONG   ulLine,
   LPWSTR  pwszErrMsg
);

Parameters

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

dwResultToCheck
[in] Result to check.

dwResultType
[in] Type of the result. This is one of the following values:
WTT_ERROR_TYPE_HRESULT
WTT_ERROR_TYPE_NTSTATUS
WTT_ERROR_TYPE_WIN32
WTT_ERROR_TYPE_BOOL

pwszFile
[in] Name of the source file where the assert happened.

ulLine
[in] Line number within the source file where the assert happened.

pwszErrMsg
[in] Text of the error message.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

WTTLog Functions (C), WTTLogCheckResultEx, Error lists


WTTLogCheckResultEx

Checks a specified result against a target result and logs an error if both the value and type match.

HRESULT WTTLogCheckResultEx (
   LONG hDevice,
   DWORD dwResultToCheck,
   DWORD dwResultType,
   DWORD dwTargetResult,
   DWORD dwTargetResultType,
   LPWSTR pwszFile,
   ULONG ulLine,
   LPWSTR pwszErrMsg
);

Parameters

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

dwResultToCheck
[in] Identifies the result to check.

dwResultType
[in] Type of the result. This is one of the following values:
WTT_ERROR_TYPE_HRESULT
WTT_ERROR_TYPE_NTSTATUS
WTT_ERROR_TYPE_WIN32
WTT_ERROR_TYPE_BOOL

dwTargetResult
[in] Target result against which to check.

dwTargetResultType
[in] Type of the target result. This is one of the following values:
WTT_ERROR_TYPE_HRESULT
WTT_ERROR_TYPE_NTSTATUS
WTT_ERROR_TYPE_WIN32
WTT_ERROR_TYPE_BOOL

pwszFile
[in] Name of the source file where the assert happened.

ulLine
[in] Line number within the source file where the assert happened.

pwszErrMsg
[in] Text message for the error.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

WTTLog Functions (C), WTTLogCheckResult, Error lists


WTTLogClearErrorList

Removes all errors of the specified type from a given list of known errors.

HRESULT WTTLogClearErrorList (
   DWORD dwErrorList,
   DWORD dwErrorType
);

Parameters

dwErrorList
[in] Error list to clear. This is one of the following values:
WTT_ERROR_LIST_EXPECTED
WTT_ERROR_LIST_BREAKON

dwErrorType
[in] Type of the error to remove. This is one of the following values:
WTT_ERROR_TYPE_HRESULT
WTT_ERROR_TYPE_NTSTATUS
WTT_ERROR_TYPE_WIN32
WTT_ERROR_TYPE_BOOL

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

WTTLog Functions (C), WTTLogAddErrorToErrorList, WTTLogRemoveErrorFromErrorList, Error lists


WTTLogCloseLogDevice

Closes a log device topology specified by either the device string or the handle.

HRESULT WTTLogCloseLogDevice (
   LONG hDevice,
   LPWSTR pwszDeviceName
);

Parameters

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

pwszDeviceName
[in] Log device string, which has the following syntax:
$<device_type>:<parameter_list>($<child_device1>[; $<child_device2>; ...])
For more information about constructing a device string, see Device string.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

WTTLog Functions (C), WTTLogCreateLogDevice


WTTLogCreateLogDevice

Create a log device topology according to the device string.

HRESULT WTTLogCreateLogDevice (
   LPWSTR pwszDevStr,
   LONG* phDevice
);

Parameters

pwszDevStr
[in] Log device string, which has the following syntax:
$<device_type>:<parameter_list>($<child_device1>[; $<child_device2>; ...])
For more information about constructing a device string, see Device string.

phDevice
[out] Pointer to a handle that represents the device tracing topology.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

WTTLog Functions (C), WTTLogCloseLogDevice


WTTLogDisableTraceLevels

Disables the specified set of device trace levels.

HRESULT WTTLogDisableTraceLevels(
   LPWSTR pwszTraceLevels,
   LONG   hDevice
);

Parameters

pwszTraceLevels
[in] String containing a list of trace levels to be disabled.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

WTTLog Functions (C), WTTLogEnableTraceLevels


WTTLogEnableTraceLevels

Enables the specified set of device trace levels.

HRESULT WTTLogEnableTraceLevels (
   LPWSTR pwszTraceLevels,
   LONG hDevice
);

Parameters

pwszTraceLevels
[in] String containing a list of trace levels to be enabled.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

WTTLog Functions (C), WTTLogDisableTraceLevels


WTTLogEndTest

Traces the end of a test case, clears current test case context, and sets it to the parent context.

HRESULT WTTLogEndTest (
   LONG hDevice,
   LPWSTR pwszTestName,
   DWORD dwResult,
   LPWSTR pwszRepro
);

Parameters

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

pwszTestName
[in] Name of the test case.

dwResult
[in] Test case result. This must be one of the following values:
  • WTT_TESTCASE_RESULT_PASS – This value does NOT guarantee that the logger will log the test case as passed. If traces are logged that indicate an error, a warning, or so forth, the logger will automatically override this value.
  • WTT_TESTCASE_RESULT_WARN – This value does NOT guarantee that the logger will log the test case as warned. If traces are logged that indicate an error or so forth, the logger will automatically override this value.
  • WTT_TESTCASE_RESULT_FAIL – This value does NOT guarantee that the logger will log the test case as failed. If traces are logged that indicate a bug or if no error trace is logged, the logger will automatically override this value.
  • WTT_TESTCASE_RESULT_BLOCKED – This value guarantees that the logger will log the test case as blocked.
  • WTT_TESTCASE_RESULT_SKIPPED – This value guarantees that the logger will log the test case as skipped.

pwszRepro
[in] Repro line number rerunning the test. If NULL, DTM Logger will try to get the command line for the current process.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

WTTLog Functions (C), WTTLogEndTestEx, WTTLogStartTest


WTTLogEndTestEx

Traces the end of a test case, and allows the user to specify a GUID-based test ID and a test hierarchy.

HRESULT WTTLogEndTestEx (
   LONG hDevice,
   DWORD dwResult,
   LPWSTR pwszTUID,
   LPWSTR pwszTestName,
   LPWSTR pwszParentTUID,
   LPWSTR pwszParentTestName
);

Parameters

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

dwResult
[in] Test case result. This must be one of the following values:
  • WTT_TESTCASE_RESULT_PASS – This value does NOT guarantee that the logger will log the test case as passed. If traces are logged that indicate an error, a warning, or so forth, the logger will automatically override this value.
  • WTT_TESTCASE_RESULT_WARN – This value does NOT guarantee that the logger will log the test case as warned. If traces are logged that indicate an error or so forth, the logger will automatically override this value.
  • WTT_TESTCASE_RESULT_FAIL – This value does NOT guarantee that the logger will log the test case as failed. If traces are logged that indicate a bug or if no error trace is logged, the logger will automatically override this value.
  • WTT_TESTCASE_RESULT_BLOCKED – This value guarantees that the logger will log the test case as blocked.
  • WTT_TESTCASE_RESULT_SKIPPED – This value guarantees that the logger will log the test case as skipped.

pwszTUID
[in] GUID (global universal identification) for the test case.

pwszTestName
[in] Name of the test case.

pwszParentTUID
[in] GUID for the parent test case.

pwszParentTestName
[in] Name of the parent test case.

Example

WTTLogStartTestEx (

hDevice,

L"b55de776-ea89-4dbe-9abd-df2041040cd7", // GUID of the test case

L"This is a sample test," // optional test case name,

WTTLOG_TESTCASE_TYPE_NOPARENT, // this is an independent test case

NULL, // GUID of the parent test case

NULL // optional name of the parent test case

);

WTTLogEndTestEx (

hDevice,

WTT_TESTCASE_RESULT_PASS, // test case result

L"b55de776-ea89-4dbe-9abd-df2041040cd7", // GUID of the test case

L"This is a sample test", // optional test case name,

NULL, // GUID of the parent test case

NULL // optional name of the parent test case

);

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

WTTLog Functions (C), WTTLogEndTest, WTTLogStartTestEx


WTTLogGetContext

Retrieves the current context of the logger object.

HRESULT WTTLogGetContext (
   LPWSTR  *ppwszContext,
   LPWSTR  *ppwszParentContext
 );

Parameters

ppwszContext
[in] Current context of the logger object.
ppwszParentContext
[in] Parent context of the logger object.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Header

Wttlogger.h

Library

WTTLog.dll

See Also

WTTLog Functions (C) WTTLogSetContext


WTTLogGetPFRollupStats

Retrieves the current pass-fail statistics.

HRESULT WTTLogGetPFRollupStats (
   PWTTLOGROLLUPINFO pWTTPFStats
);

Parameters

pWTTPFStats
[in] Pointer to a structure containing the statistics. The structure has the following definition:

typedef struct {

ULONG ulTotal; // Total number of test cases

ULONG ulPassed; // Number of test cases that passed

ULONG ulFailed; // Number of test cases that failed

ULONG ulBlocked; // Number of test cases that were blocked

ULONG ulWarned; // Number of warnings

ULONG ulSkipped; // Number of test cases that were skipped

} WTTLOGROLLUPINFO, * PWTTLOGROLLUPINFO;

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

Comments

To retrieve the current pass-fail statistics, you must create an empty structure as defined above and call WTTLogGetPFRollupStats, which passes DTM Logger a pointer the structure. DTM Logger will then populate the structure.

See Also

WTTLog Functions (C), WTTLogPFRollup


WTTLogInit

Initializes the DTM Logger DLL.

HRESULT WTTLogInit ();

Parameters

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

WTTLog Functions (C), WTTLogUninit


WTTLogPFRollup

Initializes the pass-fail statistics to the specified values.

HRESULT WTTLogPFRollup (
   LONG hDevice,
   ULONG ulPassed,
   ULONG ulWarned,
   ULONG ulFailed,
   ULONG ulBlocked,
   ULONG ulSkipped
);

Parameters

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

ulPassed
[in] Number of test cases that passed.

ulWarned
[in] Number of warnings.

ulFailed
[in] Number of tests cases that failed.

ulBlocked
[in] Number of test cases that were blocked.

ulSkipped
[in] Number of test cases that were skipped.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

WTTLog Functions (C), WTTLogGetPFRollupStats


WTTLogRemoveErrorFromErrorList

Deletes the specified error from a list of known errors.

HRESULT WTTLogRemoveErrorFromErrorList (
   DWORD dwErrorToRemove,
   DWORD dwErrorType,
   DWORD dwErrorList
);

Parameters

dwErrorToRemove
[in] Error code to remove.

dwErrorType
[in] Type of the error. This is one of the following values:
WTT_ERROR_TYPE_HRESULT
WTT_ERROR_TYPE_NTSTATUS
WTT_ERROR_TYPE_WIN32
WTT_ERROR_TYPE_BOOL

dwErrorList
[in] Error list to remove. This is one of the following values:
WTT_ERROR_LIST_EXPECTED
WTT_ERROR_LIST_BREAKON

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

WTTLog Functions (C), WTTLogAddErrorToErrorList, WTTLogClearErrorList, Error lists


WTTLogSetContext

Sets the current context of the logger object for all subsequent traces.

HRESULT WTTLogSetContext (
   LPWSTR  pwszCurrentCTX,
   LPWSTR  pwszParentCTX
 );

Parameters

pwszCurrentCTX
[in] Current context of the logger object.

pwszParentCTX
[in] Parent context of the logger object.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

WTTLog Functions (C) WTTLogGetContext


WTTLogStartTest

Traces the start of a test case.

HRESULT WTTLogStartTest (
   LONG hDevice,
   LPWSTR pwszTestName
);

Parameters

hDevice
[in] Name of the test case.

pwszTestName
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

WTTLog Functions (C), WTTLogEndTest, WTTLogStartTestEx


WTTLogStartTestEx

Traces the start of a test case and allows the user to specify a GUID-based test ID and a test hierarchy.

HRESULT WTTLogStartTestEx (
   LONG    hDevice,
   LPWSTR  pwszTUID,
   LPWSTR  pwszTestName,
   DWORD   dwTestType,
   LPWSTR  pwszParentTUID,
   LPWSTR  pwszParentTestName
);

Parameters

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

pwszTUID
[in] GUID (global universal identification) for the test case.

pwszTestName
[in] Name of the test case.

dwTestType
[in] Type of the test case. This is one of the following values:
WTTLOG_TESTCASE_TYPE_NOPARENT
WTTLOG_TESTCASE_TYPE_ISCHILD
WTTLOG_TESTCASE_TYPE_ISSIBLING
WTTLOG_TESTCASE_TYPE_SPECIFYPARENT

pwszParentTUID
[in] GUID for the parent test.

pwszParentTestName
[in] Name of the parent test.

Example

WTTLogStartTestEx (

hDevice,

L"b55de776-ea89-4dbe-9abd-df2041040cd7", // GUID of the test case

L"This is a sample test," // optional test case name,

WTTLOG_TESTCASE_TYPE_NOPARENT, // this is an independent test case

NULL, // GUID of the parent test case

NULL // optional name of the parent test case

);

WTTLogEndTestEx (

hDevice,

WTT_TESTCASE_RESULT_PASS, // test case result

L"b55de776-ea89-4dbe-9abd-df2041040cd7", // GUID of the test case

L"This is a sample test", // optional test case name,

NULL, // GUID of the parent test case

NULL // optional name of the parent test case

);

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

WTTLog Functions (C), WTTLogEndTestEx, WTTLogStartTest


WTTLogTrace

Logs a trace of the specified device at the given trace level.

HRESULT WTTLogTrace (
   LONG hDevice,
   DWORD dwTraceLvl,
   ...
);

Parameters

dwTraceLvl
[in] Trace level. This should be one of the following values:
  • WTT_LVL_MSG – Trace a user-define message. This is the most commonly used trace. If all traces within the context of a particular test case are messages, function entry, function exit, TCM information, or machine information, the test case will pass.
  • WTT_LVL_ERR – Trace an error. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_ASSERT – Trace an assertion. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_INVALID_PARAM – Trace an invalid parameter. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_BUG – Trace a known bug. This causes the logger (in the user mode) to log a test case as blocked, unless the user declares the test case as skipped.
  • WTT_LVL_BREAK – Trace a debug break. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_WARN – Trace a warning message. This causes the logger (in the user mode) to log the test case as warned, unless an error or bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_FUNCTION_ENTRY – Trace the function entry point. It has no effect on the test case result.
  • WTT_LVL_FUNCTION_EXIT – Trace the function exit point. It has no effect on the test case result.
  • WTT_LVL_START_TEST – Trace the start of a test case. This marks the beginning of a test case and sets a new context whose name is the current test case name. However, it is recommended that the user should call the StartTest method instead of using this level.
  • WTT_LVL_END_TEST – Trace the end of a test case. This marks the end of a test case and clears a new context whose name is the current test case name. It also updates the internal pass-fail counter according to the pass-fail mode and the previous traces. However, it is recommended that user should call the EndTest method instead of using this level.
  • WTT_LVL_TCMINFO – Sets the Tactics fields. It has no effect on the test case result.
  • WTT_LVL_MACHINEINFO – Sets machine-related test case fields for Tactics. It has no effect on the test case result
  • WTT_LVL_ROLLUP – Trace the test suite roll-up information. If the pass-fail mode is set to user, then the user plug-in must provide its own pass-fail count. Otherwise, DTM Logger will overwrite the counters provided by the user and use its internal counts. However, this does not cause the WTT execution agent (job agent) to perform a rollup operation.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

...
[in] Specifies one or more optional arguments that depends on the trace level specified in the dwTraceLvl parameter. For information about the arguments required for each trace level, see Trace Level.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

WTTLog Functions (C), WTTLogUserDefinedTraceEx, WTTLogTraceEx


WTTLogTraceEx

Logs a trace of the specified device at the given trace level using an XML-formatted data string.

HRESULT WTTLogTraceEx (
   DWORD dwLevel,
   DWORD dwPriority,
   LONG hDevice,
   LPWSTR pwszUserXML,
   ...
);

Parameters

dwLevel
[in] Trace level. This should be one of the following values:
  • WTT_LVL_MSG – Trace a user-define message. This is the most commonly used trace. If all traces within the context of a particular test case are messages, function entry, function exit, TCM information, or machine information, the test case will pass.
  • WTT_LVL_ERR – Trace an error. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_ASSERT – Trace an assertion. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_INVALID_PARAM – Trace an invalid parameter. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_BUG – Trace a known bug. This causes the logger (in the user mode) to log a test case as blocked, unless the user declares the test case as skipped.
  • WTT_LVL_BREAK – Trace a debug break. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_WARN – Trace a warning message. This causes the logger (in the user mode) to log the test case as warned, unless an error or bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_FUNCTION_ENTRY – Trace the function entry point. It has no effect on the test case result.
  • WTT_LVL_FUNCTION_EXIT – Trace the function exit point. It has no effect on the test case result.
  • WTT_LVL_START_TEST – Trace the start of a test case. This marks the beginning of a test case and sets a new context whose name is the current test case name. However, it is recommended that the user should call the StartTest method instead of using this level.
  • WTT_LVL_END_TEST – Trace the end of a test case. This marks the end of a test case and clears a new context whose name is the current test case name. It also updates the internal pass-fail counter according to the pass-fail mode and the previous traces. However, it is recommended that user should call the EndTest method instead of using this level.
  • WTT_LVL_TCMINFO – Sets the Tactics fields. It has no effect on the test case result.
  • WTT_LVL_MACHINEINFO – Sets machine-related test case fields for Tactics. It has no effect on the test case result
  • WTT_LVL_ROLLUP – Trace the test suite roll-up information. If the pass-fail mode is set to user, then the user plug-in must provide its own pass-fail count. Otherwise, DTM Logger will overwrite the counters provided by the user and use its internal counts. However, this does not cause the WTT execution agent (job agent) to perform a rollup operation.

dwPriority
[in] Priority of the trace. This should be one of the following values:
WTT_TRACE_PRIORITY_HIGH_CLASS
WTT_TRACE_PRIORITY_MEDIUM_CLASS
WTT_TRACE_PRIORITY_LOW_CLASS
WTT_TRACE_PRIORITY_RESERVED_CLASS
WTT_TRACE_PRIORITY_USER_CLASS

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

pwszUserXML
[in] XML-formatted string defined by the user.

...
[in] Specifies one or more optional arguments that depends on the trace level specified in the dwTraceLvl parameter. For information about the arguments required for each trace level, see Trace level.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

WTTLog Functions (C), WTTLogTrace


WTTLogTraceMachineInfo

Sets the specified computer as the trace machine.

HRESULT WTTLogTraceMachineInfo (
   LONG hDevice
);

Parameters

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1 | hDevice2

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Header

Wttlogger.h

Library

WTTLog.dll

See Also

WTTLog Functions (C) WTTLogTrace


WTTLogUninit

Removes the DTM Logger DLL from memory.

void WTTLogUninit ();

Parameters

Return Value

None

Headers

Wttlogger.h

Library

WTTLog.dll

Comments

If this function is not called, the results will not roll up into WTT Studio.

See Also

WTTLog Functions (C), WTTLogInit


WTTLogUserDefinedTrace

Logs trace data using a user-defined trace level and the specified priority.

HRESULT WTTLogUserDefinedTrace (
   LONG hDevice,
   LPCWSTR pwszUserLevel,
   DWORD dwBaseLevel,
   DWORD dwPriority
   ...
);

Parameters

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1 | hDevice2
pwszUserLevel
[in] User-defined trace level.
dwBaseLevel
[in] Base trace level. This should be one of the following values:
  • WTT_LVL_MSG – Trace a user-define message. This is the most commonly used trace. If all traces within the context of a particular test case are messages, function entry, function exit, TCM information, or machine information, the test case will pass.
  • WTT_LVL_ERR – Trace an error. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_ASSERT – Trace an assertion. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_INVALID_PARAM – Trace an invalid parameter. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_BUG – Trace a known bug. This causes the logger (in the userr mode) to log a test case as blocked, unless the user declares the test case as skipped.
  • WTT_LVL_BREAK – Trace a debug break. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_WARN – Trace a warning message. This causes the logger (in the user mode) to log the test case as warned, unless an error or bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_FUNCTION_ENTRY – Trace the function entry point. It has no effect on the test case result.
  • WTT_LVL_FUNCTION_EXIT – Trace the function exit point. It has no effect on the test case result.
  • WTT_LVL_START_TEST – Trace the start of a test case. This marks the beginning of a test case and sets a new context whose name is the current test case name. However, it is recommended that the user should call the WTTLogStartTest method instead of using this level.
  • WTT_LVL_END_TEST – Trace the end of a test case. This marks the end of a test case and clears a new context whose name is the current test case name. It also updates the internal pass-fail counter according to the pass-fail mode and the previous traces. However, it is recommended that user should call the WTTLogEndTest method instead of using this level.
  • WTT_LVL_TCMINFO – Sets the Tactics fields. It has no effect on the test case result.
  • WTT_LVL_MACHINEINFO – Sets machine-related test case fields for Tactics. It has no effect on the test case result
  • WTT_LVL_ROLLUP – Trace the test suite roll-up information. If the pass-fail mode is set to user, then the user plug-in must provide its own pass-fail count. Otherwise, WTT Logger will overwrite the counters provided by the user and use its internal counts. However, this does not cause the WTT execution agent (job agent) to perform a rollup operation.
dwPriority
[in] Priority of the trace. This should be one of the following values:
WTT_TRACE_PRIORITY_HIGH_CLASS
WTT_TRACE_PRIORITY_MEDIUM_CLASS
WTT_TRACE_PRIORITY_LOW_CLASS
WTT_TRACE_PRIORITY_RESERVED_CLASS
WTT_TRACE_PRIORITY_USER_CLASS
...

[in] Specifies one or more optional arguments that depends on the trace level specified in the dwUserLvl parameter. For information about the arguments required for each trace level, see Trace Level.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Remarks

User-defined trace levels must be enabled in order for them to be traced in the log. You enable custom trace levels on a device by using a device string, such as "$LogFile:EnableLvl=MyTrace".

Header

Wttlogger.h

Library

WTTLog.dll

See Also

WTTLog Functions (C) WTTLogUserDefinedTraceEx


WTTLogUserDefinedTraceEx

Logs trace data using a user-defined trace level and an XML-formatted data string.

HRESULT WTTLogUserDefinedTraceEx (
   LPCWSTR pcwszUserLevel,
   LONG hDevice,
   DWORD dwBaseLevel,
   DWORD dwPriority,
   LPWSTR pwszUserXML,
   ...
);

Parameters

pcwszUserLevel
[in] User-defined trace level.

hDevice
[in] Handle to the device tracing topology. You can combine multiple handles using the bitwise OR operator. Example: hDevice1, hDevice2

dwBaseLevel
[in] Base trace level. This should be one of the following values:
  • WTT_LVL_MSG – Trace a user-define message. This is the most commonly used trace. If all traces within the context of a particular test case are messages, function entry, function exit, TCM information, or machine information, the test case will pass.
  • WTT_LVL_ERR – Trace an error. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_ASSERT – Trace an assertion. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_INVALID_PARAM – Trace an invalid parameter. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_BUG – Trace a known bug. This causes the logger (in the user mode) to log a test case as blocked, unless the user declares the test case as skipped.
  • WTT_LVL_BREAK – Trace a debug break. This causes the logger (in the user mode) to fail a test case unless a bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_WARN – Trace a warning message. This causes the logger (in the user mode) to log the test case as warned, unless an error or bug trace is logged or the user declares the test case as skipped.
  • WTT_LVL_FUNCTION_ENTRY – Trace the function entry point. It has no effect on the test case result.
  • WTT_LVL_FUNCTION_EXIT – Trace the function exit point. It has no effect on the test case result.
  • WTT_LVL_START_TEST – Trace the start of a test case. This marks the beginning of a test case and sets a new context whose name is the current test case name. However, it is recommended that the user should call the WTTLogStartTest method instead of using this level.
  • WTT_LVL_END_TEST – Trace the end of a test case. This marks the end of a test case and clears a new context whose name is the current test case name. It also updates the internal pass-fail counter according to the pass-fail mode and the previous traces. However, it is recommended that user should call the WTTLogEndTest method instead of using this level.
  • WTT_LVL_TCMINFO – Sets the Tactics fields. It has no effect on the test case result.
  • WTT_LVL_MACHINEINFO – Sets machine-related test case fields for Tactics. It has no effect on the test case result
  • WTT_LVL_ROLLUP – Trace the test suite roll-up information. If the pass-fail mode is set to user, then the user plug-in must provide its own pass-fail count. Otherwise, DTM Logger will overwrite the counters provided by the user and use its internal counts. However, this does not cause the WTT execution agent (job agent) to perform a rollup operation.

dwPriority
[in] Priority of the trace. This should be one of the following values:
WTT_TRACE_PRIORITY_HIGH_CLASS
WTT_TRACE_PRIORITY_MEDIUM_CLASS
WTT_TRACE_PRIORITY_LOW_CLASS
WTT_TRACE_PRIORITY_RESERVED_CLASS
WTT_TRACE_PRIORITY_USER_CLASS

pwszUserXML
[in] XML-formatted string defined by the user.

...
[in] Specifies one or more optional arguments that depends on the trace level specified in the dwUserLvl parameter. For information about the arguments required for each trace level, see Trace Level.

Return Value

S_OK – operation was successful.

S_FALSE – operation was successful and the last device has been detached.

HRESULT – failure code. We recommend you use the FAILED macro to check HRESULT values.

Headers

Wttlogger.h

Library

WTTLog.dll

See Also

WTTLog Functions (C),


Using DTM from a Command Line

WttCmd is a command-line tool that performs DTM-related tasks. WttCmd enables users to perform actions equivalent to certain operations they can do from within the DTM Studio user interface. Generally, these operations are aimed at a single test that executes on a single client computer.

You can use WttCmd to:

  • Create Local Logical User (LLU) contexts for jobs to execute within

  • Create persistent custom dimensions under the Sysparse registry key

  • Get and set policies

  • Create temporary variables to assist with testing

  • Diagnose communication issues between a DTM client and its controller

  • Translate error and return codes into messages

  • Control auto-logon settings

  • Cancel a job

  • Reboot a client

  • Update task progress with comments

Note

The operations discussed in this appendix apply only to DTM clients because WttCmd is not installed on DTM controllers.

WttCmd is not intended for general purpose use.

WttCmd syntax

wttcmd.exe /parameter /parameter_argument
wttcmd.exe /parameter [/optional_argument]
wttcmd.exe [/optional_parameter] /?
wttcmd.exe [/optional_parameter] /help

To manipulate a LLU, use the following WttCmd parameters:

QueryLogicalUser

AddLogicalUser

DeleteLogicalUser

CleanLogicalUser

To manipulate Sysparse registry keys and values, use the following WttCmd parameters:

Note: The following parameters work only when run from a system context.

QuerySysparseReg

AddSysparseReg

DeleteSysparseReg

SignalGatherer

To manipulate policies, use the following WttCmd parameters:

GetPolicy

GetPolicies

SetPolicy

ResetPolicy

To manipulate variables and their values, use the following WttCmd parameters:

Note: The following parameters work only when run from a task within a DTM job.

SysInitKey

SysEvalKey

SysExpandStr

Additional WttCmd parameters:

Ping

HelpMsg

SetAutoLogon

Report

Note: The following parameters work only when run from a task within a DTM job.

CancelJob

EaReboot

TaskUpd

WttCmd supports additional parameters. If a parameter is not described in this documentation then DTM does not support it.

Code example to execute WttCmd

Several tasks can execute a WttCmd process from inside their executable code. For example, a task written in C/C++ to delete an LLU on the client computer might implement code similar to the following:

if( TRUE )
{
    exec( "WTTCmd.EXE /deletelogicaluser /localName:Local" );
}


DTM Policies

A DTM policy is a setting on the controller that controls the behavior and actions of DTM.

The following table lists predefined DTM policies and their default values. The default value of a policy is the value defined when the client was installed. Some policies require the client computer to be restarted to take effect.

Policy | Description | Default Value | Requires Restart
AutoUpdatePollInterval | Specifies the number of minutes that DTM should wait to poll for an update. | 720 minutes | Yes
ControlledStopTimeout | Specifies the number of minutes that DTM should wait to stop once it has determined that it needs to upgrade. | 720 minutes | Yes
MachineResetTimeout | Specifies the number of seconds that the Machine Reset handlers should wait to reset DTM. | 300 seconds | No
EaHBTimeoutInterval | Specifies the number of minutes that DTM should wait before sending peer computer heartbeats. | 30 minutes | Yes
EaHBTimeoutExpire | Specifies the number of minutes that DTM should wait for a heartbeat from a peer computer. If the time expires before receiving a heartbeat from a peer computer, the job is canceled. | 120 minutes | Yes
EaJobMemoryRestrictionPercentage | Specifies the percentage of virtual memory that can be combined and used by all of the tasks in the job. | 100 percent | No
EaRebootWaitTime | Specifies the number of seconds that DTM should wait for the client computer to restart after the restart task exits. | 1800 seconds | No
EaCopyInfraLogsOnPass | Specifies a Boolean flag to indicate whether DTM should copy the infra logs if job passed. The default value is FALSE, which will not copy the infra logs. Note that infra logs are always copied if the job fails. | FALSE | Yes
IgnoreUnexpectedReboots | Specifies a Boolean flag to indicate whether DTM should ignore unexpected restarts. The default value is FALSE to, which will ignore unexpected restarts. This policy should not be set to TRUE unless the test team has a custom method to detect unexpected restarts. | FALSE | No
AutologonWaitTime | Specifies the number of minutes that DTM should wait for Session 0 of Autologon. DTM will not wait if this policy is set to 0 seconds. | 300 minutes | No
PDSleepTime | Specifies the number of seconds the Push Daemon should wait for messages from the database. | 30 seconds | Yes
WTTMessageReceiveTimeout | Specifies the number of seconds to wait for incoming messages before rejecting the connections. | 300 seconds | Yes


QueryLogicalUser

The QueryLogicalUser parameter displays the Local Logical Users (LLU) that are configured on the client computer. An LLU local logical user (LLU) is a context that jobs can run under. An LLU removes the need to specify, and subsequently, transmit or log sensitive account information and passwords.

Syntax

wttcmd.exe /querylogicaluser

Examples

wttcmd.exe /querylogicaluser


AddLogicalUser

Use the AddLogicalUser parameter to add a Local Logical User (LLU) to the client computer. An LLU is a context that jobs can run under. It removes the need to specify, and subsequently, transmit or log sensitive account information and passwords.

Syntax

wttcmd.exe /addlogicaluser /localname:<localname> /user:<username> /domain:<domain> /password:<password>

Argument | Description
/LocalName:<LocalName> | A friendly name for the user to add.
/User:<UserName> | The user name.
/Domain:<Domain> | The domain that the user belongs to. This will be the name of the client computer if the user account exists on the computer itself.
/Password:<Password> | The password for the user.

Examples

wttcmd.exe /addlogicaluser /localname:StressTestUser /user:abc /domain:corporate /password:P@ssW0rd

Comments

The AddLogicalUser parameter does not add a user account to the computer. It only associates the provided account information with running jobs.

When used with the AddLogicalUser parameter, WttCmd does not verify that the specified account exists and has adequate access privileges.


DeleteLogicalUser

Use the DeleteLogicalUser parameter to delete a Local Logical User (LLU) from the client computer. An LLU is a context that jobs can run under. An LLU removes the need to specify, and subsequently, transmit or log sensitive account information and passwords.

Syntax

wttcmd.exe /deletelogicaluser /localname:<localname>

Argument | Description
/LocalName:<LocalName> | The name of the user to delete.

Examples

wttcmd.exe /deletelogicaluser /localname:StressTestUser

Comments

The DeleteLogicalUser parameter does not delete the user account that is associated with the LLU from the client computer. It only removes the mapping between the LLU and the user account.


CleanLogicalUser

Use the CleanLogicalUser parameter to delete all Local Logical Users (LLUs) from the client computer. An LLU is a context that jobs can run under. It removes the need to specify, and subsequently, transmit or log sensitive account information and passwords.

Syntax

wttcmd.exe /cleanlogicaluser

Examples

wttcmd.exe /cleanlogicaluser


QuerySysparseReg

Use the QuerySysparseReg parameter to check whether a value and/or its data exists in the Sysparse registry key. This parameter functions only when WttCmd executes from a system context.

Syntax

wttcmd.exe /querysysparsereg /v:<name> [/d:<data>]

Argument | Description
/v:<name> | The name of a value in the Sysparse registry key. This value can be either of type REG_SZ or of type REG_MULTI_SZ.
/d:<data> | The data present in the registry value.

Examples

wttcmd.exe /querysysparsereg /v:DimensionName /d:DimensionData

Comments

WttCmd returns 0 if <name> is present, and 1 if <name> is not present.

WttCmd returns 0 if <name> is specified and if <name> contains <data>.

WttCmd returns 1 if <name> is specified and if <name> does not contain <data>.


AddSysparseReg

Use the AddSysparseReg parameter to add a persistent custom dimension to the Sysparse registry key. This parameter functions only when WttCmd executes from a system context.

Syntax

wttcmd.exe /addsysparsereg /v:<name> [/d:<data>] [/t:<datatype>]

Argument | Description
/v:<name> | The name of a value in the Sysparse registry key. This value can be either of type REG_SZ or of type REG_MULTI_SZ depending on the data type specified in the /t argument.
/d:<data> | The data to add to the registry.
/t:<datatype> | The data type of the registry value. Supported data types are: REG_SZ (the default) REG_MULTI_SZ.

Examples

wttcmd.exe /addsysparsereg /v:DimensionName /d:DimensionData /t:reg_multi_sz

Comments

If <name> does not exist, the AddSysparseReg parameter adds a registry key called <name>, with a value of <data>.

If <name> exists, and its data type is REG_SZ, the AddSysparseReg parameter replaces the value stored in <name> with a new value of <data>.

If <name> exists, and its data type is REG_MULTI_SZ, the AddSysparseReg parameter appends the new value in <data> to the registry key specified in <data>.


DeleteSysparseReg

Use the DeleteSysparseReg parameter to delete a Sysparse registry key value. This parameter functions only when WttCmd executes from a system context.

Syntax

wttcmd.exe /deletesysparsereg /v:<name> [/d:<data>]

Argument | Description
/v:<name> | The name of a value in the Sysparse registry key. This value can be either of type REG_SZ or of type REG_MULTI_SZ.
/d:<value> | The data present in the registry value.

Examples

wttcmd.exe /deletesysparsereg /v:DimensionName /d:DimensionData


SignalGatherer

Use the SignalGatherer parameter to notify DTM to invoke the specified gatherer on the next update. Updates happen normally whenever a job finishes executing or when the client reboots. If the client reboots in the middle of the job, the update will be done only at the job completion. This parameter functions only when WttCmd executes from a system context.

Syntax

wttcmd.exe /signalgatherer /gatherer:<gatherername>

Argument | Description
/Gatherer:<GathererName> | The name of the gatherer to invoke during the next update.

Examples

wttcmd.exe /SignalGatherer /Gatherer:DTM_BLOCK


GetPolicy

Use the GetPolicy parameter to query a DTM policy on the client computer and return its value.

Syntax

wttcmd.exe /getpolicy /policy:<policyname>

Argument | Description
/Policy:<PolicyName> | The name of the policy to query.

Examples

wttcmd.exe /getpolicy /policy:EaHBTimeoutInterval


GetPolicies

Use the GetPolicies parameter to display all DTM policies configured on the client computer and return their default and current values.

Syntax

wttcmd.exe /getpolicies

Examples

wttcmd.exe /getpolicies


SetPolicy

Use the SetPolicy parameter to set a DTM policy to the specified value on the client computer.

Syntax

wttcmd.exe /setpolicy /policy:<policyname> /value:<value>

Argument | Description
/Policy:<PolicyName> | The name of the policy to set.
/Value:<value> | The value to set the policy to.

Examples

wttcmd.exe /setpolicy /policy:EaHBTimeoutInterval /value:500

Comments

When used with the SetPolicy parameter, WttCmd does not verify that the specified value matches the data type used with the policy (integer or string). Be sure to set it to the expected data type.


ResetPolicy

Use the ResetPolicy parameter to reset the specified DTM policy , or all DTM policies, on the client computer to their default values.

Syntax

wttcmd.exe /resetpolicy [/policy:<policyname>]

Argument | Description
/Policy:<PolicyName> | The name of the policy to reset.

Examples

wttcmd.exe /resetpolicy
wttcmd.exe /resetpolicy /policy:EaHBTimeoutInterval

Comments

The Policy argument is optional. If you do not specify a policy name, then ResetPolicy resets all policies on the client computer.


SysInitKey

Use the SysInitKey parameter to assign a value to a variable. Variables can be used in the task execution command-lines to be evaluated at run time. This parameter functions only when WttCmd executes from a task within a DTM job.

Syntax

wttcmd.exe /sysinitkey /key:<name> /value:<value>

Argument | Description
/Key:<name> | The name of the variable.
/Value:<value> | The value to assign to the variable.

Examples

wttcmd.exe /sysinitkey /key:Debugger /value:ntsd

Comments

Use the SysInitKey parameter to create an environment variable and assign a value to it.

The variable exists only during the lifetime of the job run.


SysEvalKey

Use the SysEvalKey parameter to evaluate the value of a variable. This parameter functions only when WttCmd executes from a task within a DTM job.

Syntax

wttcmd.exe /sysevalkey /key:<name> /default:<value>

Argument | Description
/Key:<name> | The variable to evaluate.
/Default:<value> | The default value to return if the variable is not defined.

Examples

wttcmd.exe /sysevalkey /key:Debugger /default:ntsd

Comments

To evaluate a variable, enclose it in square brackets.


SysExpandStr

Use the SysExpandStr parameter to evaluate the values of all variables in the specified string. This parameter functions only when WttCmd executes from a task within a DTM job.

Syntax

wttcmd.exe /sysexpandstr /string:”<string>” /default:<value>

Argument | Description
/String:”<string>” | The string to expand. The string can contain multiple variables to be evaluated. For example: "[Debugger] [Options] -test:netsniff"
/Default:<value> | The default value to return if any variable could not be evaluated.

Examples

wttcmd.exe /sysexpandstr /string:"[Debugger] [Options] -test:netsniff" /default:"ntsd -g -test:netsniff"

Comments

To evaluate a variable, enclose it in square brackets.


Ping

Use the Ping parameter to try to contact DTM on the specified computer. If the Ping parameter fails to contact DTM, no other DTM communications will succeed.

Syntax

wttcmd.exe /ping /target:<machinename>

Argument | Description
/Target:<MachineName> | The name of the computer to ping.

Examples

wttcmd.exe /ping /target:MyComputer
wttcmd.exe /ping /target:MyComputer.Domain.Com


HelpMsg

Use the HelpMsg parameter to display a text description for the specified Hresult error code. The Hresult error code must be supplied using hexadecimal notation. For example: 0x80040a02.

Syntax

wttcmd.exe /helpmsg /error:<hresult>

Argument | Description
/Error:<Hresult> | The hexadecimal Hresult code.

Examples

wttcmd.exe /helpmsg /error:0x80040a02


SetAutoLogon

Use the SetAutoLogon parameter to enable the auto-logon feature on the client computer.

Syntax

wttcmd.exe /setautologon [/lluname:<LLUName>][/user:<username> /domain:<domain> /password:<password>] /autologoncount:<value>

Argument | Description
/LLUName:<LLUName> | The name of the Local Logical User (LLU) to be used with auto-logon.
/User:<Username> | The user name.
/Domain:<Domain> | The domain that the user belongs to. This will be the name of the client computer if the user account exists on the computer itself.
/Password:<Password> | The password for the user.
/AutoLogonCount:<value> | The number of logoffs for which auto-logon is enabled.

Examples

wttcmd.exe /setautologon /lluname:LLU_LADU /autologoncount:1

Comments

The SetAutoLogon parameter requires either an LLU name or a user/domain/password triplet, but not both.


Report

Use the Report parameter to report an error against the task that is currently running, or if no task is currently running, the client computer. This parameter functions only when WttCmd executes from a task within a DTM job.

Syntax

wttcmd.exe /report /error:<string>

Argument | Description
/Error:<string> | The error message to log.

Examples

wttcmd.exe /report /error:"The task failed with error 1703."
wttcmd.exe /report /error:"The computer is held for someone to take a look."


CancelJob

Use the CancelJob parameter to cancel the current job. This parameter functions only when WttCmd executes from a task within a DTM job.

Syntax

wttcmd.exe /canceljob

Examples

wttcmd.exe /canceljob


EaReboot

Use the EaReboot parameter to notify DTM to restart the computer. This parameter functions only when WttCmd executes from a task within a DTM job.

Syntax

wttcmd.exe /eareboot [/restart] [/timeout:<value>] /taskwillreboot

Argument | Description
/Restart | Specifies to restart the same task after the computer restarts. Without this argument, the task will complete after restart and the next task or job will be started.
/Timeout:<value> | The number of seconds DTM should wait for the tasks currently executing to complete.
/TaskWillReboot | Specifies the task that initiated WttCmd will itself initiate the restart. The default behavior is for DTM to initiate the restart.

Examples

wttcmd.exe /eareboot /restart /timeout:10
wttcmd.exe /eareboot /restart /taskwillreboot /timeout:10

Comments

Microsoft recommends specifying a timeout value of at least 5 or more seconds to enable DTM some time to communicate information between the controller and client before the client reboots.


TaskUpd

Use the TaskUpd parameter to update a task’s "Percent Complete" with a comment. This parameter functions only when WttCmd executes from a task within a DTM job.

Syntax

wttcmd.exe /taskupd /progress:<value> /comment:”<string>”

Argument | Description
/Progress:<value> | The percentage of the task that is complete. This value should be a number from 0 to 100.
/Comment:”<string>” | A free-form comment of less than 2000 characters.

Examples

wttcmd.exe /taskupd /progress:50 /comment:"Round 1 of stress is complete."


Logo Tests: Device and Driver Technologies

This section contains descriptions of tests for each type of driver technology, and the procedures you must follow to prepare for testing.


Bus Controller Testing

This section describes how to test bus controllers in order to qualify them for the "Designed for Windows" logo. To complete logo testing, you must install and run the Device Test Manager and setup your testing environment. For information on installing and configuring the Device Test Manager, see Installing Driver Test Manager.

Bluetooth Controller Testing

CardBus-PCMCIA Controller Testing

Secure Digital Host Controller Testing


Bluetooth Controller Testing Overview

These procedures test your Bluetooth Controllers for proper functionality by using the Microsoft Windows Driver Kit (WDK) and the Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as required for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

The test procedures are divided into the following types of topics:

  • Overview: The overview topics describe the hardware, software, and tester knowledge requirements.
  • Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.
  • Running: The running topics describe how to run the tests for your device or system.

Bluetooth Controller Tests

The tests that you need to run depend on the capabilities of the device or system that is being tested. The following list contains all of the tests that you might need for your test device:

  • Bluetooth - point to point
  • Bluetooth - Scatternet
  • Bluetooth - SCO

Run time: approximately 1-2 hours

Note The test descriptions are included in a separate section.

Hardware Requirements

The following hardware is required for Bluetooth Controller testing. You might need additional hardware if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • Three test systems that are connected over TCP/IP.
  • Two Bluetooth control devices (such as those provided by Cambridge Silicon Radio and Silicon Wave) that have received "Designed for Windows" logos.

Software Requirements

The following software is required to run the Bluetooth Controller tests:

  • Microsoft Windows Vista
  • Microsoft Windows XP Professional with Service Pack 2 (SP2)
  • Microsoft Windows XP Professional x64 Edition
  • Any drivers that are not shipped with the operating system
  • The current release of the Microsoft Windows Driver Kit (WDK)

Tester Knowledge Requirements

To run the Bluetooth Controller tests, testers must know how to accomplish the following tasks:

  • Install the test Bluetooth controller, if the controller is not embedded on the motherboard.
  • Install the Bluetooth subordindate devices on the other test systems.
  • Install the operating system from the product CD.
  • Launch tests from the Device Console in DTM Studio.

After you have reviewed the necessary requirements, you can prepare to test your Bluetooth Controller device.

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Preparing for Bluetooth Controller Testing

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see the Bluetooth Controller Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, For more information about autologon, see [image] How to turn on automatic logon in Windows XP.

Test system configuration

To configure your test system for Bluetooth Controller testing, do the following:

  1. Install the appropriate Microsoft Windows operation system.
  2. Install the test device and any accessories. You should not need to install a driver for this device
  3. Install DTM Client.
  4. Configure the machine for testing in DTM Studio:
    • Add the machine to a machine pool.


Running the Bluetooth Controller Tests

To test Bluetooth Controllers, do the following:

  1. Open Device Console in DTM Studio.
  2. Create a new submission for “Bus Controllers and Ports > Bluetooth”.
    • Select "No Driver Files" if you are prompted, because the test device should not require a driver.
    • Make sure to select your test device under the Bluetooth node in the device list.
  3. Select the tests that you want to start, and then click Add Selected. The Job extension window (which is shown in the following figure) appears with the details of the test name, the selected computer, and other computers that are available to run the test.

    Job extension dialog box

  4. Select the appropriate computers, and click Save.
  5. Click Schedule Jobs to schedule a job.
  6. In the window that appears, select the appropriate computers where tests need to be run.
  7. Run the tests that are described in the following list.

Bluetooth - point to point

Note Ensure that the Bluetooth radio is installed during this test.

More Info:

Bluetooth - Scatternet

Note Ensure that the Bluetooth radio is installed during this test.

More Info:

Bluetooth - SCO

Note Ensure that the Bluetooth radio is installed during this test.

More Info:


Troubleshooting Bluetooth Controller Testing

Before you create a submission, make sure your client is in Ready Mode. If your client is not in Ready Mode, right-click the computer and click Change Status > Reset.


CardBus-PCMCIA Testing Overview

These procedures test your CardBus-PCMCIA Controller for proper functionality by using the Microsoft Windows Driver Kit (WDK) and the Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as required for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

The test procedures are divided into the following types of topics:

  • Overview: The overview topics describe the hardware, software, and tester knowledge requirements.
  • Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.
  • Running: The running topics describe how to run the tests for your device or system.

CardBus-PCMCIA Controller Tests

The tests that you need to run depend on the capabilities of the device or system that is being tested. The following list contains all of the tests that you might need for your test device:

  • CardBus Card Common Silicon Guidelines test
  • CardBus Bridge Power Management Register Test
  • CardBus Bridge Register Test
  • Device Path Exerciser
  • System - Sleep Stress with IO
  • Disable Enable with IO
  • Plug and Play Driver Test
  • Storage Device Stress test (SDStress)
  • Core Stress Test

If your device is connected through PCI, you will need:

  • For Windows Vista. PCI Compliance Test (LOGO)
  • For Windows XP and Windows Server 2003. PCI Compliance Test 2.1 (LOGO)

Run time: approximately 2 hours

Note The test descriptions are included in a separate section.

Hardware Requirements

The following hardware is required for CardBus-PCMCIA Controller testing. You might need additional hardware if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One test system with the following:
    • Minimum requirements that are published for the test operating system
    • CD-ROM drive
    • One monitor, one keyboard, and one mouse (or any pointing/drawing device)

      Note The preceding items are not required when the test system is a mobile system.

    Important The test system must be included in the Windows Catalog.

  • One CardBus/PCMCIA host controller (test device).
  • Any CardBus/PCMCIA card that complies with the requirements of the "Designed for Microsoft Windows" Logo Program for Hardware.

    Important Contact the CardBus card vendor if you are uncertain about ACPI compliance.

Software Requirements

The following software is required to run the CardBus-PCMCIA Controller tests:

  • One of the following operating systems:
      Microsoft Windows Vista

      Microsoft Windows XP Professional with Service Pack 2 (SP2)

      Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)

      Microsoft Windows Server 2003, Datacenter Edition, with SP1

      Microsoft Windows XP Professional x64 Edition

      Microsoft Windows Server 2003, Enterprise x64 Edition

      Microsoft Windows Server 2003, Datacenter x64 Edition

      Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems

      Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems

  • Any drivers that are not shipped with the operating system
  • The current release of Microsoft Windows Driver Kit (WDK)

Tester Knowledge Requirements

To run the CardBus-PCMCIA Controller tests, testers must know how to accomplish the following tasks:

  • Install the CardBus/PCMCIA test controller.
  • Install the operating system from the product CD.
  • Install the CardBus Card.
  • Install the manufacturer-supplied device driver for the CardBus card, if necessary.
  • Install DTM Client.
  • Start tests from DTM Studio’s Device Console (Submission mode).

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Preparing to Test CardBus-PCMCIA

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see CardBus-PCMCIA Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, For more information about autologon, see [image] How to turn on automatic logon in Windows XP.

Test system configuration

  1. Install the appropriate Microsoft Windows operating system.
  2. Install the test device and any accessories. You should not need to install a driver for this device.
  3. Install the CardBus device and any device driver that the manufacturer supplies.
  4. Install DTM Client.
  5. Configure the machine for testing in DTM Studio.
    1. Add the machine to a machine pool.
    2. Deploy the “WDK\ConfigureCardbusPCMCIAController” dimension.


Running the CardBus-PCMCIA Tests

To test CardBus-PCMCIA Controllers, do the following:

  1. Open Device Console in DTM Studio.
  2. Create a new submission for “Bus Controllers and Ports > CardBus-PCMCIA Controller”.
    • The test device should not require a driver. Please select “No Driver Files” when you are prompted.
    • Make sure to select your test device under the PCMCIA Adapters node in the device list.
  3. Select the tests that you want to start, choose Add Selected, and then click Schedule.

CardBus Card Common Silicon Guidelines

Note Ensure that the CardBus card is installed during this test.

More Info:

CardBus Bridge Power Management Register

Note Ensure that the CardBus card is installed during this test.

More Info:

CardBus Bridge Register

More Info:

DR - Device Path Exerciser

More Info:

DR - Sleep Stress with IO

More Info:

DR - Disable Enable with IO

More Info:

DR - Plug and Play Driver Test

More Info:

DR - Stress Test

More Info:

DR - Stress Test with low resource simulation

More Info:

DR - Sleep Stress Disable Enable with IO

More Info:

PCI Compliance Test

Note This test will appear only if your device is connected through PCI and the test system is running Windows Vista.

More Info:

PCI Compliance Test 2.1

Note This test will appear only if your device is connected through PCI and the test system is running Windows Server 2003 or Windows XP.

More Info:

PCI/PCI Express Compliance Test (PCITEST2_1)


Troubleshooting CardBus-PCMCIA Testing

For more information about troubleshooting CardBus-PCMCIA testing, see Troubleshooting Storage Tests.


Secure Digital Host Controller Testing Overview

These procedures test your Secure Digital Host Controller for proper functionality by using the Microsoft Windows Driver Kit (WDK) and the Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as required for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

The test procedures are divided into the following types of topics:

  • Overview: The overview topics describe the hardware, software, and tester knowledge requirements.
  • Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.
  • Running: The running topics describe how to run the tests for your device or system.

Secure Digital Host Controller Tests

The tests that you need to run depend on the capabilities of the device or system that is being tested. To see the complete list of tests that could be required for your device, see Secure Digital Host Controller Tests.

The following list contains the tests that you might need for your test device:

  • Secure Digital Test
  • Device Path Exerciser
  • System - Sleep Stress with IO
  • Disable Enable with IO
  • Plug and Play Driver Test
  • Storage Device Stress test (SDStress)
  • Core Stress Test

If your device is connected through Cardbus, you might need the following tests:

  • CardBus Card Configuration Space Register test
  • CardBus Card Common Silicon Guidelines test
  • CardBus Bridge Power Management Register Test

If your device is connected through PCI, you might need the following tests:

  • For Windows Vista. PCI Compliance Test (LOGO)
  • For Windows Server 2003 and Windows XP. PCI Compliance Test 2.1 (LOGO)

Run time: approximately 2 hours

Note The test descriptions are included in a separate section.

Hardware Requirements

The following hardware is required for Secure Digital Host Controller testing. You might need additional hardware if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One test system with the following:
    • Minimum requirements that are published for the test operating system
    • CD-ROM drive
    • One monitor, one keyboard, and one mouse (or any pointing/drawing device)

      Note The preceding items are not required when the test system is a mobile system.

    Important The test system must be included in the Windows Catalog.

  • One Secure Digital host controller (test device).
  • Any Secure Digital memory card that complies with the requirements of the "Designed for Microsoft Windows" Logo Program for Hardware.

Software Requirements

The following software is required to run the Secure Digital Host Controller tests:

  • One of the following operating systems:
      Microsoft Windows Vista

      Microsoft Windows XP Professional with Service Pack 2 (SP2)

      Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)

      Microsoft Windows Server 2003, Datacenter Edition, with SP1

      Microsoft Windows XP Professional x64 Edition

      Microsoft Windows Server 2003, Enterprise x64 Edition

      Microsoft Windows Server 2003, Datacenter x64 Edition

      Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems

      Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems

  • Any drivers that are not shipped with the operating system
  • The current release of Microsoft Windows Driver KiT (WDK)

Tester Knowledge Requirements

To run the Secure Digital Host Controller tests, testers must know how to accomplish the following tasks:

  • Install the Secure Digital test controller.
  • Install the operating system from the product CD.
  • Insert and remove the SD Memory card.
  • Install DTM Client.
  • Start tests from DTM Studio’s Device Console (Submission mode).

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Preparing to Test Secure Digital Host Controllers

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see Secure Digital Host Controller Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, For more information about autologon, see [image] How to turn on automatic logon in Windows XP.

Test system configuration

  1. Install the appropriate Microsoft Windows operating system.
  2. Install the test device and any accessories.
  3. Install DTM Client.
  4. Configure the machine for testing in DTM Studio.
    1. Add the machine to a machine pool.
    2. Deploy the “WDK\ConfigureSecureDigitalHostController” dimension.


Running the Secure Digital Host Controller Tests

To test Secure Digital Host Controllers, do the following:

  1. Open Device Console in DTM Studio.
  2. Create a new submission for “Bus Controllers and Ports > CardBus-PCMCIA Controller”.
    • The test device should not require a driver. Please select “No Driver Files” when you are prompted.
    • Make sure to select your test device under the SD Host node in the device list.
  3. Select the tests that you want to start, choose Add Selected, and then click Schedule.

    Important The Secure Digital Test requires manual user intervention. Please schedule this test alone and proceed to the test console after scheduling.

Secure Digital Test

Input: This test takes no command-line input.

Setup: This test requires no change to the standard setup. The test itself will change the device driver for the Secure Digital Host Controller.

Precaution: If the test should fail in such a way that DTM cannot run the test's clean-up tasks, you should manually reinstall the driver on the test device. Please see the test documentation for instructions.

More Info:

DR - Device Path Exerciser

More Info:

DR - Sleep Stress with IO

More Info:

DR - Disable Enable with IO

More Info:

DR - Plug and Play Driver Test

More Info:

DR - Stress Test

More Info:

DR - Stress Test with low resource simulation

More Info:

DR - Sleep Stress Disable Enable with IO

More Info:

CardBus Card Configuration Space Register

Note: This test will appear only if your device is connected through CardBus.

Precaution: Please remove all other CardBus cards before you run this test.

More Info:

CardBus Card Common Silicon Guidelines

Note: This test will appear only if your device is connected through CardBus.

Precaution: Please remove all other CardBus cards before you run this test.

More Info:

CardBus Bridge Power Management Register

Note: This test will appear only if your device is connected through CardBus.

Precaution: Please remove all other CardBus cards before you run this test.

More Info:

PCI Compliance Test

Note This test will appear only if your device is connected through PCI and the test system is running Windows Vista.

More Info:

PCI Compliance Test 2.1

Note This test will appear only if your device is connected through PCI and the test system is running Windows Server 2003 or Windows XP.

More Info:


Troubleshooting Secure Digital Host Controller Testing

  • Before you create a submission, make sure your client is in Ready Mode. If it is not, right-click the machine, click Change Status, and then click Reset.
  • If you plug in your device and it does not appear in DTM Studio, click the refresh button in Device Console before you create a submission. If the device still does not appear, restart the client machine.
  • If jobs are not getting your device's parameters, check the following:
    1. Right-click on the job in Job Monitor’s Job Execution Status pane.
    2. Click View Result Report.
    3. Check the Effective Parameters section at the bottom of the report.
    4. If the parameters are incorrect, you might have associated the wrong device with the submission, the device might be installed incorrectly, or the installed driver might be wrong.
    5. If the Effective Parameters section is empty, your submission might be invalid.
    6. Create a new submission and start the test again.
    7. If the parameters are still empty, your client installation may be corrupt.
    8. Delete the machine from the machine pool, uninstall the client, and then repeat steps 8 and 9 of Test System Configuration.
  • If jobs are appearing incorrectly, ensure that you have completed step 9 of Test System Configuration.

For more information about troubleshooting Secure Digital Host Controller testing, see Troubleshooting Storage Tests.


Bus Tests

Test name Target operating system Test description
Secure Digital Test Windows Vista
Windows XP
         This test is designed to test Secure Digital Host controllers. It loads a test driver sdhct.sys that allows it access the SD host controller hardware directly.
CardBus Bridge Register Test Windows Vista
Windows XP
The CardBus Bridge Register test determines whether the CardBus bridges support all of the registers that are specified in the PCI to PCMCIA CardBus Bridge Register Description standard (Yenta Specification).
Bluetooth - SCO Windows Vista
The "Bluetooth - SCO" tests Bluetooth's HCT for Bluetooth logo requirements.
It verifies that:
  • The system under test is using valid Bluetooth specifications
One can run the test manually using the command line options only after bthcsti (test driver) driver is installed and rebooted all machines. It requires 2 machines. One machine acts as Primary and other acts as Secondary machine.
Run command on primary machine : "mjolnir.exe -c SCO_HCT -l <logFileName>
Run command on secondary machine: "mjolnir.exe -m <PrimaryMachineName>
Debugging test failures requires complete log files. The test will generate a text log file as specified by user. Please include this file with any questions about failing results. A kernel debugger remote session might also need to be included.
Bluetooth - point to point Windows Vista
The "Bluetooth - point to point" tests Bluetooth's HCT for Bluetooth logo requirements.
It verifies that:
  • The system under test is using valid Bluetooth specifications
One can run the test manually using the command line options. It requires 2 machines. One machine acts as Primary and other acts as Secondary machine.
Run command on primary machine : "mjolnir.exe -c HCT -l <logFileName>
Run command on secondary machine: "mjolnir.exe -m <PrimaryMachineName>
Debugging test failures requires complete log files. The test will generate a text log file as specified by user. Please include this file with any questions about failing results. A kernel debugger remote session might also need to be included.
MCA Test Tool Windows Vista
The MCA Test tool determines whether an IA-64 class platform delivers appropriate information in error records for machine checks to the operating system. These error records are delivered from the System Abstraction Layer (SAL) and are reported by Microsoft Windows through the Windows Management Instrumentation (WMI) and ETW.
PCI/PCI Express Compliance Test (PCITEST2_1) Windows XP
         The PCI Compliance test (PCITest2.exe) determines whether or not a single PCI device or all relevant PCI devices in a system are compliant with industry standards for PCI devices as well as several specific Microsoft requirements for PCI devices that may exceed requirements in standard PCI related specifications.
Garttest Windows Vista
         This test covers compliance with AGP 1.0, AGP 2.0, and AGP 3.0 specifications
IrDA Transport Windows Vista
         IrDA Transport is a socket level test tool that is used to test the IrDA drivers. It tests the IrDA drivers by checking if other IrDA devices in range can be detected and data can be sent and received using the IrDA devices without any errors.
Graphics Bus Transfer Windows Vista
This test involves moving a known bit-pattern through AGP system memory into local video memory.
Bluetooth - Scatternet Windows Vista
The "Bluetooth - Scatternet" tests Bluetooth's scatternet requirements for Bluetooth logo requirements.
It verifies that:
  • The system under test is using valid Bluetooth specifications
One can run the test manually using the command line options. It requires 3 machines. One machine acts as Primary and other two act as Secondary machines.
Run command on primary machine : "mjolnir.exe -c Scatternet -S 2 -l <logFileName>
Run command on secondary machines: "mjolnir.exe -m <PrimaryMachineName>
Debugging test failures requires complete log files. The test will generate a text log file as specified by user. Please include this file with any questions about failing results. A kernel debugger remote session might also need to be included.


Secure Digital Test

Type: Automated Test

Overview

This test is designed to test Secure Digital Host controllers. It loads a test driver sdhct.sys that allows it access the SD host controller hardware directly.

Details

The SD Bus Host Controller HCT software allows operators to verify the correct operation of a Secure Digital controller on a Windows Logo’d platform. Correct operation includes exercising and verifying the following functionality:
  • Host Controller Configuration
  • Device Insertion/Removal
  • Wake on Device Insertion/Removal
  • SD Memory I/O
  • SD Performance
  • Host Controller Power Control
  • Error Handling

Run Time: 20
Log File: sdhctlog.xml
System Restart Required: Yes
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • SD Memory Card

Running Secure Digital Test

Launch the test from DTM. Allow the machine 5 minutes to load the test driver and reboot. Go to the test machine and follow the on-screen instructions to insert and remove the SD card.

Command Syntax

Command option | Description
sdhct.exe |

Code Tour

File Manifest

File | Location
sdhct.sys | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk\sdhct
sdhct.inf | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk\sdhct
sdhct.cat | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk\sdhct
sdhct.dll | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk\sdhct
sdhct.exe | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk\sdhct

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


CardBus Bridge Register Test

Type: Automated Test

Overview

The CardBus Bridge Register test determines whether the CardBus bridges support all of the registers that are specified in the PCI to PCMCIA CardBus Bridge Register Description standard (Yenta Specification).

Details

This test determines whether the CardBus bridges support all of the registers that are specified in the PCI to PCMCIA CardBus Bridge Register Description standard (Yenta Specification). The test also verifies that all reserved fields in the CardBus bridge configuration space register a return value of 0 when they are read. Write operations on reserved fields must have no effect.

Additionally, the test verifies that read-only bits and fields in the CardBus bridge registers are readable only.
The tests in the Windows Driver Kit (WDK) are used in several different test system configurations in each test category. Refer to the test procedure documentation for your specific test category for information about required system configurations and test procedures.
The test uses the Microsoft Windows PCI driver interface, which is loaded at runtime.

Run Time: 60 seconds
Log File: Cbbridge.wtl
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running CardBus Bridge Register Test

Command Syntax

Command option | Description
Cbbridge.exe |

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location
Cbbridge.exe | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk
pcidll.dll | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk
pcclib.dll | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk
pciwdm.sys | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk

Click to show or hide information. Test Assertions

Test Assertions

14.2.1 System supports industry-standard definition in PCI to PCPMCIA CardBus Bridge Register Description (Yenta Specification) for CardBus bridges.
Test Assertion GUID: b891202d-c33f-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.2.2 CardBus bridges must implement configuration header type 2.
Test Assertion GUID: b891202e-c33f-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.2.5 Device identification registers in the configuration space (such as Vendor ID, Device ID, Revision ID, and Class Code) must comply with the functionality defined in the PCI Local Bus Specification 2.1.
Test Assertion GUID: b891202f-c33f-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.2.6 CardBus bridge Subsystem ID and Subsystem Vendor ID registers (offsets 42h and 40h in the configuration space) comply with the PCI Local Bus Specification 2.1.
Test Assertion GUID: b8912030-c33f-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.2.7 CardBus bridge Subsystem ID and Subsystem Vendor ID registers must be populated with nonzero values.
Test Assertion GUID: b8912031-c33f-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.2.8 Bus number registers in the configuration space (such as Primary Bus Number, Secondary Bus Number and Subordinate Bus Number) must comply with the functionality defined in the PCI Local Bus Specification 2.1.
Test Assertion GUID: b8912032-c33f-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.2.9 CardBus bridges must implement command registers (such as Command and Bridge Control) and these registers must comply with the functionality defined in the PCI Local Bus Specification 2.1.
Test Assertion GUID: b8912033-c33f-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.2.10 CardBus bridges must implement status registers (such as Status and Secondary Status) and these registers must comply with the functionality defined in the PCI Local Bus Specification 2.1.
Test Assertion GUID: b8912034-c33f-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.2.11 CardBus bridges must implement memory filter registers (such as Memory Base Address and Memory Limit) and these registers must comply with the functionality defined in the PCI Local Bus Specification 2.1.
Test Assertion GUID: b8912035-c33f-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.2.12 CardBus bridges must implement I/O filter registers (such as I/O Base Address and I/O Limit), and these registers must comply with the functionality defined in the PCI Local Bus Specification 2.1.
Test Assertion GUID: b8912036-c33f-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.2.13 CardBus bridges must implement latency timer registers (such as Latency Timer and Secondary Latency Timer), and these registers must comply with the functionality defined in the PCI Local Bus Specification 2.1.
Test Assertion GUID: b8912037-c33f-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.2.14 CardBus bridges must implement interrupt-related registers (such as the Interrupt Pin and Interrupt Line), and these registers must comply with the functionality defined in the PCI Local Bus Specification 2.1.
Test Assertion GUID: b8912038-c33f-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.2.15 CardBus bridges must implement Cache Line Size register, and the register must comply with the functionality defined in the PCI Local Bus Specification 2.1.
Test Assertion GUID: b8912039-c33f-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.2.16 CardBus bridges must implement Cap_Ptr register (offset 14h).
Test Assertion GUID: b891203a-c33f-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.2.17 CardBus Bridge Cap_Ptr offset must be DWORD-aligned.
Test Assertion GUID: b891203b-c33f-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.2.18 CardBus bridge Cap_Ptr value must have a minimum value of 80h and a maximum value of F8h.
Test Assertion GUID: b891203c-c33f-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.2.19 CardBus bridges must implement PC Card Socket Status and Control Registers Base Address register.
Test Assertion GUID: b891203d-c33f-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.2.21 All reserved fields in the CardBus bridge configuration space must always return a value of 0 when they are read.
Test Assertion GUID: b891203e-c33f-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:


Bluetooth - SCO

Type: Automated Test

Overview

The "Bluetooth - SCO" tests Bluetooth's HCT for Bluetooth logo requirements.
It verifies that:
  • The system under test is using valid Bluetooth specifications
One can run the test manually using the command line options only after bthcsti (test driver) driver is installed and rebooted all machines. It requires 2 machines. One machine acts as Primary and other acts as Secondary machine.
Run command on primary machine : "mjolnir.exe -c SCO_HCT -l <logFileName>
Run command on secondary machine: "mjolnir.exe -m <PrimaryMachineName>
Debugging test failures requires complete log files. The test will generate a text log file as specified by user. Please include this file with any questions about failing results. A kernel debugger remote session might also need to be included.

Details

Success or Failure of the test is determined by the result of each test cases printed in log file at end of each test case. Each test case listed in the logfile must pass in order for the overall result to be "pass"
How to install bthcsti driver?
1) Copy bthcsti.inf, bthcsti.sys, bthcsti.cat, bthcstisetup.exe, devcon.exe in one directory and execute followin steps from that directory.
1) Run bthcstisetup.exe
2) Run command "devcon dp_add bthcsti.inf"
3) reboot machine
4) check in device manager that bthcsti driver is installed or not.

Run Time: 45 Mins
Log File:
System Restart Required: Yes
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running Bluetooth - SCO

Install test, start test, wait for the test to finish, examine generated log file for results.

Command Syntax

Command option | Description
mjolnir.exe -c SCO_HCT -l <logFileName> | run this command on Primary machine
mjolnir.exe -m <PrimaryMachineName> | run this command on Secondary machine

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Bluetooth - point to point

Type: Automated Test

Overview

The "Bluetooth - point to point" tests Bluetooth's HCT for Bluetooth logo requirements.
It verifies that:
  • The system under test is using valid Bluetooth specifications
One can run the test manually using the command line options. It requires 2 machines. One machine acts as Primary and other acts as Secondary machine.
Run command on primary machine : "mjolnir.exe -c HCT -l <logFileName>
Run command on secondary machine: "mjolnir.exe -m <PrimaryMachineName>
Debugging test failures requires complete log files. The test will generate a text log file as specified by user. Please include this file with any questions about failing results. A kernel debugger remote session might also need to be included.

Details

Success or Failure of the test is determined by the result of each test cases printed in log file at end of each test case. Each test case listed in the logfile must pass in order for the overall result to be "pass"
Run Time: 45 Mins
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running Bluetooth - point to point

Install test, start test, wait for the test to finish, examine generated log file for results.

Command Syntax

Command option | Description
mjolnir.exe -c HCT -l <logFileName> | run this command on Primary machine
mjolnir.exe -m <PrimaryMachineName> | run this command on Secondary machine

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


MCA Test Tool

Overview

The MCA Test tool determines whether an IA-64 class platform delivers appropriate information in error records for machine checks to the operating system. These error records are delivered from the System Abstraction Layer (SAL) and are reported by Microsoft Windows through the Windows Management Instrumentation (WMI) and ETW.

Details

The test tool checks the error records delivered to Windows to ensure their compliance with Intel SAL 3.0 Specification and all WHQL requirements, including System Design Guide. The test tool examines primarily the error records delivered according to these specifications. Both fatal error (Machine Check Abort) and corrected error (CMC) records are validated during the test.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • Itanium

Running MCA Test Tool

  • Run the tool as “mcahct /insert”, which will insert a fatal error.
  • Reboot the machine after the bugcheck.
  • Run the tool as “mcahct /validate”
Fatal Error Testing
  • Retrieve the fatal error record from WMI
  • Validate the fatal error record:
    1. Validate the section lengths of the error record. That is, check if any of the section lengths are zero. Also check if the actual length of the error record is the same as reported in the length field of the record header.
    2. Validate the record header revision field (should be equal to 0x0002).
    3. Validate the record header severity field (should be equal 0x0 or 0x1, which means a fatal error).
    4. Validate the error record valid bits (should be larger than one).
    5. Validate each section of the error record:
      1. Validate section header revision field (should be equal to 0x0002).
      2. Validate section header recovery info (should be equal to zero).
      3. Validate section GUID.
Corrected Error Testing (two times)
  • Insert corrected cache error
  • Wait for the error to be returned from WMI (if no timeout occurred)
  • Retrieve the error record from WMI
  • Validate the corrected error record:
    1. Validate the section lengths of the error record. That is, check if any of the section lengths are zero. Also check if the actual length of the error record is the same as reported in the length field of the record header.
    2. Validate the record header revision field (should be equal to 0x0002).
    3. Validate the record header severity field (should be equal to 0x2, which means a corrected error).
    4. Validate the error record valid bits (should be larger than one).
    5. Validate each section of the error record.

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


PCI/PCI Express Compliance Test (PCITEST2_1)

Overview

The PCI Compliance test (PCITest2.exe) determines whether or not a single PCI device or all relevant PCI devices in a system are compliant with industry standards for PCI devices as well as several specific Microsoft requirements for PCI devices that may exceed requirements in standard PCI related specifications.

Details

This test scans the system to find all currently installed and functional PCI devices. It then narrows the list of devices to test by automatically excluding devices with a base class that does not need testing (base classes 0h, Bh, Eh) or a base class/subclass combination that does not need testing (base class 5h with all subclasses except 1h, base class 6h with all subclasses except for 4h and 7h; and base class 8h with all subclasses except for 4h and 5h).
If the test is launched to verify the entire system, all remaining devices are tested. If single device testing is selected, the test prompts you with the list to choose from. You can alternately launch the test with the plug and play identifier (PNP ID) as an argument to target a single device automatically.
The test then verifies that the PCI Configuration space region of each device behaves as defined in the PCI specification.
For devices with a PCI-Express capability, the test also performs minimal driver related tests that check for changes in the values of particular registers in the configuration space when the driver is started, running and stopped.
For PCI-Express systems, the test also checks the ACPI table to perform a BIOS related test for memory configuration space access.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running PCI/PCI Express Compliance Test (PCITEST2_1)

For earlier versions of Windows, the PCI Hardware Compliance Test (PCITEST2_1) will be automatically selected in the DTM for a System Logo submission, or for Device Logo Submissions for which the selected device is a PCI, PCI-X or a PCI-Express device.
To view the PCITEST2_1 log after a test run:
  1. Launch the job monitor.
  2. Select the machine that ran the job.
  3. Select the job in the "Job Execution Status" pane
  4. In the Task Execution Status pane, right click "Run Test" task and select "View Task Log"
  5. Select the "ContextTree" view from the drop-down list on the top left of the window.
  6. The log file will be displayed in an organized fashion per PCI function, and further organized into test sections. Expand/collapse sections by clicking on the nodes.

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Garttest

Type: Automated Test

Overview

This test covers compliance with AGP 1.0, AGP 2.0, and AGP 3.0 specifications

Details

This test verifies that non-local video memory can be allocated and used directly for AGP operations. Support for a GART and write-combining (WC) memory (for processors that provide WC memory) is confirmed. Uncached memory mapping of the graphics aperture is verified for processors that do not support WC. Integrity of the GART allocation/alignment and allocation/free is confirmed.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running Garttest

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:

Windows Logo Program:

Additional Information:


IrDA Transport

Type: Automated Test

Overview

IrDA Transport is a socket level test tool that is used to test the IrDA drivers. It tests the IrDA drivers by checking if other IrDA devices in range can be detected and data can be sent and received using the IrDA devices without any errors.

Details

Below is a description of what each test does.
Random Sock Connect/Disconnect
A socket number is being randomly generated and a client connects to the server using this random socket. After the connection is established the socket is disconnected immediately. There’s no delay between the connect-disconnect states. A new socket has a new socket number. The test is repeated for the specified number of repetitions.
Single Sock Connect/Disconnect
A socket number is fixed, and a client connects to the server using this fixed number. After the connection is established the socket is disconnected immediately. There’s no delay between the connect-disconnect states. The test is repeated for the specified number of repetitions.
Multi Sock Full Connect/Disconnect
For the specified number of sockets, each socket is connected to the server. After all sockets are connected, they all get disconnected in the same sequence (the first connected socket disconnects first). There is no delay between connect-disconnect procedures.
Discovery
A socket is created accept out the IRLMP_ENUMDEVICES socket option. A return value of the number of IR devices in range is compared to zero, and if the number of devices greater than zero (there are devices in range), test continues normally. The test case is repeated for the number of iterations.
Stop/Start IrDA Protocol
IRDA protocol is stopped, a machine waits for 0.5 seconds and the service is started again. A new delay of 0.5 seconds is held before continuing. The test repeats for the specified number of iterations.
Stop/Start IrMON
IRMON service is stopped, a machine waits for 0.5 seconds and the service is started again. A new delay of 0.5 seconds is held before continuing. The test repeats for the specified number of iterations.
Single Socket Data Loop - Verified
For the specified number of sockets, test program opens connections to a server computer, and sends the data '01010101b'. The sockets are used one at a to send and receive the data. The buffer length is selected by the user and value for the sent buffer size is ranging from 0 to 2k. The data received by the client is verified for integrity with the original buffer that was sent out.
Single Socket Data Loop - Verified (Random Data)
For the specified number of sockets, test program opens connections to a server computer, and sends random data. The sockets are used one at a to send and receive the data. The buffer length is selected by the user and value for the sent buffer size is ranging from 0 to 2k. The data received by the client is verified for integrity with the original buffer that was sent out.
Single Socket Data Loop - Verified (Random Data Length)
For the specified number of sockets, test program opens connections to a server computer, and sends the data '01010101b'. The sockets are used one at a to send and receive the data. The buffer length is selected randomly and value for the sent buffer size is ranging from 0 to 2k. The data received by the client is verified for integrity with the original buffer that was sent out.
Single Socket Data Loop - Verified (Random Data & Random Data Length)
For the specified number of sockets, test program opens connections to a server computer, and sends random data. The sockets are used one at a to send and receive the data. The buffer length is selected randomly and value for the sent buffer size is ranging from 0 to 2k. The data received by the client is verified for integrity with the original buffer that was sent out.
Multi Socket Data Loop - Verified
For the specified number of sockets, test program opens connections to a server computer, and sends the data '01010101b'. The buffer length is selected by the user and value for the sent buffer size is ranging from 0 to 2k. The data received by the client is verified for integrity with the original buffer that was sent out.
Multi Socket Data Loop - Verified (Random Data)
For the specified number of sockets, test program opens connections to a server computer, and sends random data. The buffer length is selected by the user and value for the sent buffer size is ranging from 0 to 2k. The data received by the client is verified for integrity with the original buffer that was sent out.
Multi Socket Data Loop - Verified (Random Data Length)
For the specified number of sockets, test program opens connections to a server computer, and sends the data '01010101b'. The buffer length is selected randomly and value for the sent buffer size is ranging from 0 to 2k. The data received by the client is verified for integrity with the original buffer that was sent out.
Multi Socket Data Loop - Verified (Random Data & Random Data Length)
For the specified number of sockets, test program opens connections to a server computer, and sends random data. The buffer length is selected randomly and value for the sent buffer size is ranging from 0 to 2k. The data received by the client is verified for integrity with the original buffer that was sent out.
Multi-thread Socket Data Loop - Verified
For the specified number of sockets, a thread is created that transfers data from the client to the server and back. Buffer size is four kilobytes. Integrity of transferred data is verified. Once all threads are terminated, the test exits.

Run Time:
Log File: irwhql.wtl
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running IrDA Transport

Command Syntax

Command option | Description
/s | Start IrWHQL server
/c | Start IrWHQL client running default tests
/logo | Start logo testing
/d | Enable detailed logging

Cautions

There should not be any other IrDA devices in range except the ones that are part of the test.

Troubleshooting

This test runs only if each IrDA device finds exactly one IrDA device in range. If the test does not start then either there is no device in range or there is more than one device in range. This information can be found out from the log file that gets generated.

Code Tour

File Manifest

File | Location
* | [WTT\TestBinRoot]\nttest\nettest\irda\TransportTest

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Graphics Bus Transfer

Type: Automated Test

Overview

This test involves moving a known bit-pattern through AGP system memory into local video memory.

Details

This test verifies that AGP devices can reliably transfer data when configured to run at the required transfer mode. A known bit pattern is transferred between AGP system memory and local video memory (video memory residing on the graphics adapter). The bit pattern is then compared to the result of the transfer (as it resides in local video memory) and any differences in the bit pattern indicate data corruption.

Run Time: 15 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running Graphics Bus Transfer

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:

Windows Logo Program:

Additional Information:


Bluetooth - Scatternet

Type: Automated Test

Overview

The "Bluetooth - Scatternet" tests Bluetooth's scatternet requirements for Bluetooth logo requirements.
It verifies that:
  • The system under test is using valid Bluetooth specifications
One can run the test manually using the command line options. It requires 3 machines. One machine acts as Primary and other two act as Secondary machines.
Run command on primary machine : "mjolnir.exe -c Scatternet -S 2 -l <logFileName>
Run command on secondary machines: "mjolnir.exe -m <PrimaryMachineName>
Debugging test failures requires complete log files. The test will generate a text log file as specified by user. Please include this file with any questions about failing results. A kernel debugger remote session might also need to be included.

Details

Success or Failure of the test is determined by the result of each test cases printed in log file at end of each test case. Each test case listed in the logfile must pass in order for the overall result to be "pass"
Run Time: 45 Mins
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running Bluetooth - Scatternet

Install test, start test, wait for the test to finish, examine generated log file for results.

Command Syntax

Command option | Description
mjolnir.exe -c Scatternet -S 2 -l <logFileName> | run this command on Primary machine
mjolnir.exe -m <PrimaryMachineName> | run this command on two Secondary machines

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Serial Port Tests

Test name | Target operating system | Test description
CardBus Bridge Power Management Register Test | Windows Vista Windows XP | The CardBus Bridge Power Management Register test searches the CardBus Bridge/Card configuration space for each of the CardBus device functions and verifies that the power management registers are correctly implemented.
CardBus Card Configuration Space Register test | Windows Vista Windows XP | This test determines the correct implementation of the CardBus card’s configuration space support registers.
CardBus Card Common Silicon Guidelines test | Windows Vista Windows XP | This test determines whether the CardBus card’s configuration space supports the Common Silicon Guidelines as described in PC Card Standard Guidelines, Volume 10.


CardBus Bridge Power Management Register Test

Type: Automated Test

Overview

The CardBus Bridge Power Management Register test searches the CardBus Bridge/Card configuration space for each of the CardBus device functions and verifies that the power management registers are correctly implemented.

Details

The CardBus Bridge Power Management Register test accesses the CardBus Bridge PCI configuration space through the Microsoft Windows PCI driver interface, which is loaded at runtime.
Run Time: 60 seconds
Log File: Cbpmreg.log and Cbpmreg.log.trace
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • If testing a CardBus bridge/controller, One CardBus card that complies with the requirements of the "Designed for Microsoft Windows" Logo Program for Hardware.

Running CardBus Bridge Power Management Register Test

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location
Cbpmreg.exe | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk
pcidll.dll | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk
pcclib.dll | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk
pciwdm.sys | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk

Click to show or hide information. Test Assertions

Test Assertions

14.9.1 CardBus controllers and cards implement PCI power management specification.
Test Assertion GUID: c53a1591-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.9.2 The Capabilities bit (bit 4) in the PCI Status register determines whether or not the function implements new capabilities.
Test Assertion GUID: c53a1592-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information: When this bit is set to a value other than 0b, it indicates that the function implements capabilities. If the value is set at 0b, the function does not implement new capabilities.

14.9.3 The Capabilities bit is read-only and its reset value is 1b.
Test Assertion GUID: c53a1593-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.9.4 The Cap_Ptr register is located in PCI configuration space at offset 34h for header-type-zero devices.
Test Assertion GUID: c53a1594-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.9.5 The Cap_Ptr register is located in PCI configuration space at offset 14h for header-type-2 devices (PCI-to-CardBus bridges).
Test Assertion GUID: c53a1595-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.9.6 The values of 00h-3Fh are not valid for the Cap_Ptr register for CardBus cards For PCI-to-CardBus bridges, the values of 00h-7Fh are not valid for the Cap_Ptr register.
Test Assertion GUID: c53a1596-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.9.7 The Cap_Ptr register offset is double word aligned so that the two least-significant bits are always assigned zero values.
Test Assertion GUID: c53a1597-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.9.8 The Power Management registers can be accessed as bytes, 16-bit words, or 32-bit double words.
Test Assertion GUID: c53a1598-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.9.9 The Capability ID register is read-only.
Test Assertion GUID: c53a1599-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.9.10 The NextItemPtr field (bits 8 through 15) must point to the next item in the capabilities list.
Test Assertion GUID: c53a15a0-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information: This address must be double-word-aligned. If this capability entry is the last, it must have a value of 00h.

14.9.11 The NextItemPtr field (bits 8 through 15) is read-only.
Test Assertion GUID: c53a15a1-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.9.12 Each function of a PCI device has only one item in its capability list with Cap_ID register value set to 01b.
Test Assertion GUID: c53a15a2-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.9.13 The PMC register is a 16-bit, read-only register.
Test Assertion GUID: c53a15a3-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.9.14 For CardBus cards, the Version field (bits 0 through 2) must have a value of 010b to indicate that this function complies with Revision 1.1 of the PCI Power Management Interface Specification for CardBus cards.
Test Assertion GUID: c53a15a4-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information: For PCI-to-CardBus bridges, the Version field (bits 0 through 2) can have a value of 001b as specified in Revision 1.0 of the PCI Power Management Interface Specification or 010b to indicate that the function complies with Revision 1.1 of the PCI PM Interface Specification.

14.9.15 The PME_Clock (bit 3) must have a value of 0b for functions that do not support PME# generation in any state.
Test Assertion GUID: c53a15a5-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.9.18 The DSI bit (bit 5) indicates whether special initialization of this function is required.
Test Assertion GUID: c53a15a8-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.9.19 The D1_Support bit (bit 9) must be set to a value of 1b for any function that supports the D1 power management state.
Test Assertion GUID: c53a15a9-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information: If the function does not support D1, it must always return a value of 0b for this bit.

14.9.20 The D1_Support bit is read-only.
Test Assertion GUID: c53a15b0-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.9.21 The D2_Support bit (bit 10) must be set to a value of 1b for any function that supports the D2 power management state.
Test Assertion GUID: c53a15b1-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information: If the function does not support D2, it must always return a value of 0b for this bit.

14.9.22 The D2_Support bit is read-only.
Test Assertion GUID: c53a15b2-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.9.23 The PME_Support bit 15 indicates the power states in which the function may assert the PME# signal.
Test Assertion GUID: c53a15b3-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.9.24 The PME_Support bits 11 through 14 are read-only.
Test Assertion GUID: c53a15b4-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.9.25 All reserved bits in the PMC Register (bit 6 through 8) must always return a value of 0b when they are read.
Test Assertion GUID: c53a15b5-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information: Write operations on these bits have no effect. This assertion applies only for CardBus bridges that comply with PCI PM spec Revision 1.0.

14.9.26 For CardBus bridges, auxiliary power source (bit 4) must have a value of 1b to indicate that support for PME# in D3COLD requires auxiliary power that the system supplies by a proprietary delivery vehicle.
Test Assertion GUID: c53a15b6-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information: If the function supplies its own auxiliary power, this bit must have a value of 0b. This bit is read-only. This assertion is applicable for CardBus bridges that comply with version 1.0 of the PCI power management specification. For CardBus cards that comply with PCI PM Spec Rev 1.1, the bit 4 is reserved and should read 0. This bit is read-only.

14.9.27 The PowerState field (bits 0 through 1) in the PMCSR 4egister is used to determine the current power state of a PCI function and to set the function into a new power state.
Test Assertion GUID: c53a15b7-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.9.28 The PowerState field is read/write.
Test Assertion GUID: c53a15b8-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.9.30 If system software attempts to write an unsupported optional state to the PowerState field, the write operation must finish normally on the bus.
Test Assertion GUID: c53a15c0-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information: he data is then discarded and the state doesn’t change.

14.9.31 The PME_En bit (bit 8) is read/write.
Test Assertion GUID: c53a15c1-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.9.33 The PCI functions that do not support PME# generation from any Dx state might treat the PME_En bit as read-only.
Test Assertion GUID: c53a15c3-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information: When system software reads the bit, the bit must always return a value of 0b.

14.9.37 Writing a value of 0b to the PME_Status bit has no effect.
Test Assertion GUID: c53a15c7-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.9.38 If the PCI function does not support PME# generation from the D3 Cold state, the PME_Status bit defaults to a value of 0b.
Test Assertion GUID: c53a15c8-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.9.40 The Data_Select field is read/write.
Test Assertion GUID: c53a15d0-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.9.41 The reset value of the Data_Select field is 0000b.
Test Assertion GUID: c53a15d1-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.9.42 The Data_Scale field (bits 13 through 14) is required for any function that implements the Data register.
Test Assertion GUID: c53a15d2-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.9.43 The Data_Scale field is read-only.
Test Assertion GUID: c53a15d3-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.9.44 All reserved fields in the PMCSR register (bits 2 through 7) must always return a value of 0 when they are read.
Test Assertion GUID: c53a15d4-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information: Write operations on these fields have no effect.

14.9.45 The Data register is an optional, 8-bit read-only register.
Test Assertion GUID: c53a15d5-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information:

14.9.46 If the Data register is implemented, the Data_Select and Data_Scale fields must also be implemented.
Test Assertion GUID: c53a15d6-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information: If the Data Register is not implemented, it must always return a value of0b. The Data_Select and Data_Scale fields must also return a value of 0b.

14.9.49 Values from 0 through 8 are the only valid values for the Data_Select field.
Test Assertion GUID: c53a15d9-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information: Values from 9 through 15 are reserved.

14.9.52 The B2_B3# bit (bit 6) determines the action that results from programming the function to the D3 Hot state.
Test Assertion GUID: c53a15e2-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information: A value of 1b indicates that when the bridge function is programmed to this state, its secondary bus PCI clock is stopped (B2). A value of 0b indicates that its secondary bus has its power removed (B3). Note: This assertion does not apply for CardBus cards.

14.9.53 The B2_B3# bit is read-only.
Test Assertion GUID: c53a15e3-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information: Note: This assertion does not apply for CardBus cards.

14.9.54 If the BPCC_En bit (bit 7) is set to a value of 1b, only the B2_B3# bit is significant.
Test Assertion GUID: c53a15e4-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information: Note: This assertion does not apply for CardBus cards.

14.9.55 The BPCC_En bit (bit 7) indicates whether the bus power and clock control mechanism is enabled.
Test Assertion GUID: c53a15e5-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information: A value of 1b indicates that the bus power/clock control mechanism is enabled. A value of 0b indicates that the bus power and clock control policies have been disabled. Note: This assertion does not apply for CardBus cards.

14.9.57 All reserved fields in the PMCSR_BSE Register (bits 0 through 5) must always return a value of 0b when they are read.
Test Assertion GUID: c53a15e7-c34c-11da-94f3-00123f3a6b60

Windows Logo Program: BUSPORT-0006 CardBus controller complies with industry standards and Windows-compatible configuration

Additional Information: Write operations on these fields have no effect. Note: This assertion does not apply for CardBus cards.


CardBus Card Configuration Space Register test

Type: Automated Test

Overview

This test determines the correct implementation of the CardBus card’s configuration space support registers.

Details

This test determines the correct implementation of the CardBus card’s configuration space support registers. Specifically, this test program validates the CardBus CIS Pointer register. CardBus cards must include a separate CIS for each function within the card. Each CIS provides a method for function-specific software, such as the client drivers, to determine the type of function and the configuration options for a given function.
The CardBus Card Configuration Space Register test verifies the CardBus card’s CIS Pointer register field functionality. In addition, the program verifies that all unimplemented registers in CardBus card configuration space returns all zeros when read.
After the system restarts and loads the Microsoft Windows operating system, the test gains access to the CardBus card configuration space to verify the support for the CIS register fields. The test gets access to the CardBus card’s configuration space through the PCI driver interface.
The tests in the Windows Driver Kit (WDK) are used in several different test system configurations in each test category. Refer to the test procedure documentation for your specific test category for information about required system configurations and test procedures.
The test uses the Microsoft Windows PCI driver interface, which is loaded at runtime.

Run Time: 60 seconds
Log File: cbcreg.wtl
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running CardBus Card Configuration Space Register test

Command Syntax

Command option | Description
cbcreg.exe |

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location
cbcreg.exe | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk
pcidll.dll | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk
pcclib.dll | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk
pciwdm.sys | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk

Click to show or hide information. Test Assertions

Test Assertions

14.6.1 All devices comply with the PC Card Standards.
Test Assertion GUID: 959be3e9-c341-11da-94f3-00123f3a6b60

Windows Logo Program: CONNECT-0012 CardBus card is configured correctly

Additional Information:

14.6.2 CardBus cards must hace a seperate configuration space for each implemented function.
Test Assertion GUID: 959be3ea-c341-11da-94f3-00123f3a6b60

Windows Logo Program: CONNECT-0012 CardBus card is configured correctly

Additional Information:

14.6.3 All registers in CardBus card configuration space that are not implemented must return all zeros when read.
Test Assertion GUID: 959be3eb-c341-11da-94f3-00123f3a6b60

Windows Logo Program: CONNECT-0012 CardBus card is configured correctly

Additional Information:

14.6.4 CIS register in CardBus card configuration space is a read-only register.
Test Assertion GUID: 959be3ec-c341-11da-94f3-00123f3a6b60

Windows Logo Program: CONNECT-0012 CardBus card is configured correctly

Additional Information:

14.6.5 Each configuration space of a multiple-function CardBus card must have its own CIS that the CIS pointer in the configuration space points to.
Test Assertion GUID: 959be3ed-c341-11da-94f3-00123f3a6b60

Windows Logo Program: CONNECT-0012 CardBus card is configured correctly

Additional Information:

14.6.6 If a CardBus card's CIS begins in device-dependent configuration space, the Address Space Offset field value in the CIS register must be in the range 40h to F8h, both inclusive.
Test Assertion GUID: 959be3ee-c341-11da-94f3-00123f3a6b60

Windows Logo Program: CONNECT-0012 CardBus card is configured correctly

Additional Information:

14.6.7 If a CardBus card's CIS begins in the memory address space governed by one of the six Base Address registers, the Address Space Offset field value in the CIS register plus the base address value in the Base Address register must be in the range 0 to FFFFFFF8h, both inclusive.
Test Assertion GUID: 959be3ef-c341-11da-94f3-00123f3a6b60

Windows Logo Program: CONNECT-0012 CardBus card is configured correctly

Additional Information:

14.6.8 If a CardBus card's CIS begins in the expansion ROM space governed by the Expansion ROM Base register, the Address Space Offset field (bits 3-23) value in the CIS register must be in the range 0 to 0FFFFFF8h, both inclusive.
Test Assertion GUID: 959be3f0-c341-11da-94f3-00123f3a6b60

Windows Logo Program: CONNECT-0012 CardBus card is configured correctly

Additional Information:

14.6.9 If a CardBus card's CIS begins in the expansion ROM space governed by the Expansion ROM Base Register, the Address Space Offset field (bits 24-27) value in the CIS register must be in the range of 0 to Fh, inclusive.
Test Assertion GUID: 959be3f1-c341-11da-94f3-00123f3a6b60

Windows Logo Program: CONNECT-0012 CardBus card is configured correctly

Additional Information:


CardBus Card Common Silicon Guidelines test

Type: Automated Test

Overview

This test determines whether the CardBus card’s configuration space supports the Common Silicon Guidelines as described in PC Card Standard Guidelines, Volume 10.

Details

This test determines whether the CardBus card’s configuration space supports the Common Silicon Guidelines as described in PC Card Standard Guidelines, Volume 10.
This test verifies that the CardBus card implements the following allocated fields in the configuration space:
  • PCI SIG-assigned vendor ID (Vendor ID)
  • Vendor-assigned device ID (Device ID)
  • Vendor-assigned revision ID (Revision ID)
  • CardBus card device class (Class Code)
  • Latency timer setting (Max_Lat)
  • Time-slice request setting (Min_Gnt)
  • Current IRQ routing for the CardBus card device (Interrupt Line)
The tests in the Windows Driver Kit (WDK) are used in several different test system configurations in each test category. Refer to the test procedure documentation for your specific test category for information about required system configurations and test procedures.
The test uses the Microsoft Windows PCI driver interface, which is loaded at runtime.

Run Time: 60s
Log File: cbcomsig.wtl
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • If testing a CardBus bridge/controller, One CardBus card that complies with the requirements of the "Designed for Microsoft Windows" Logo Program for Hardware.

Running CardBus Card Common Silicon Guidelines test

Command Syntax

Command option | Description
cbcomsig.exe |

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location
cbcomsig.exe | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk
pcidll.dll | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk
pcclib.dll | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk
pciwdm.sys | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk

Click to show or hide information. Test Assertions

Test Assertions

14.7.1 CardBus card configuration space meets Common Silicon Guidelines.
Test Assertion GUID: fecf2769-c340-11da-94f3-00123f3a6b60

Windows Logo Program: CONNECT-0012 CardBus card is configured correctly

Additional Information:

14.7.2 CardBus card common silicon must implement read-only Vendor ID field in the 16-double word PCI-like configuration header space.
Test Assertion GUID: fecf276a-c340-11da-94f3-00123f3a6b60

Windows Logo Program: CONNECT-0012 CardBus card is configured correctly

Additional Information:

14.7.3 CardBus card common silicon must implement read-only Device ID field in the 16-double word PCI-like configuration header space.
Test Assertion GUID: fecf276b-c340-11da-94f3-00123f3a6b60

Windows Logo Program: CONNECT-0012 CardBus card is configured correctly

Additional Information:

14.7.4 CardBus card common silicon must implement read-only Revision ID field in the 16-double word PCI-like configuration header space.
Test Assertion GUID: fecf276c-c340-11da-94f3-00123f3a6b60

Windows Logo Program: CONNECT-0012 CardBus card is configured correctly

Additional Information:

14.7.5 CardBus card common silicon must implement read-only Class CodeID field in the 16-double word PCI-like configuration header space.
Test Assertion GUID: fecf276d-c340-11da-94f3-00123f3a6b60

Windows Logo Program: CONNECT-0012 CardBus card is configured correctly

Additional Information:

14.7.6 CardBus card common silicon must implement PCI's read-only Max_Lat field in the 16-double word PCI-like configuration header space.
Test Assertion GUID: fecf276e-c340-11da-94f3-00123f3a6b60

Windows Logo Program: CONNECT-0012 CardBus card is configured correctly

Additional Information:

14.7.7 CardBus card common silicon must implement PCI's read-only Min_Gnt field in the 16-double word PCI-like configuration header space.
Test Assertion GUID: fecf276f-c340-11da-94f3-00123f3a6b60

Windows Logo Program: CONNECT-0012 CardBus card is configured correctly

Additional Information:

14.7.8 CardBus card common silicon must implement PCI's read-write Interrupt Line register in the 16-double word PCI-like configuration header space.
Test Assertion GUID: fecf2770-c340-11da-94f3-00123f3a6b60

Windows Logo Program: CONNECT-0012 CardBus card is configured correctly

Additional Information:


Display Testing

This section describes how to test display devices in order to qualify them for the "Designed for Windows" logo.

Display > Adapters

Display > Monitors


Display Adapter Testing Overview

The procedures presented in this section outline the process for testing your Display Adapter and Chipset device for proper functionality with the Microsoft Windows operating system. These procedures test your product for proper functionality by using the Microsoft Windows Driver Kit (WDK) and the Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as requried for the device.

If the device that is being tested is multifunctional, you must complete the test procedures for each functionally independent, logical device. For example, a display adapter that contains video input capability must complete the display tests and the video capture tests.

The test procedures are divided into the following types of topics:

  • Overview: The overview topics describe the hardware, software, and tester knowledge requirements.
  • Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.
  • Running: The running topics describe how to run the tests for your device or system.

Display Adapter Tests

The tests that you need to run depend on the capabilities of the device or system that is being tested. To see the complete list of tests that could be required for your device, see Display Adapter Tests.

Hardware Requirements

The following hardware is required to be present in the machine pool for Display Adapter and Chipset Testing to fullfill the diversity requirements that demonstrate the stability of display drivers and chipsets:

  • You must have at least 2 comptuers:
    • At least one AMD microprocessor system
    • At least one Intel system with a dual microprocessor (such as the Intel Hyper-Threading microprocessor)

    Note Mobile display adapters and chipsets do not have to follow this requirement.

  • You must use the following power management states:
    • S1
    • S3
    • S4
  • At least two adapters for each Display asic family that are supported in the INF file that is obtaining the logo. One of the adapters must support dualview.
  • A multi-sync display data channel standard, level 2B (DDC2B)-capable monitor with EDID 1.3 support on the test systems.

Software Requirements

The following software is required to run Display Adapter and Chipset Testing:

  • All display adapters and chipsets must be running the same driver version.
  • An ageed upon Display/Chipset asic grouping breakout, DisplayGroups.xml, on the DTM controller and DTM clients.
  • To run the Fast User Switching (FUS) tests, ensure that the test system is not part of a domain. To verify this situation, right-click My Computer, and click Properties. Click the Computer Name tab, and see if the computer is a part of a domain. If the computer is part of a domain, click Change, and then add the computer to a Workgroup.
  • Disable power management on the test systems before you run tests from the DTM.
  • Ensure that all password protection is disabled before you run power management tests; otherwise, you might be asked for a password when your system resumes, interrupting automated testing.

Tester Knowledge Requirements

To run Display Adapter and Chipset Testing, testers must know how to accomplish the following tasks:

  • Install the operating system from the product CD.
  • Extend the desktop to a secondary display.

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Preparing for Display Adapter Testing

Before running the display tests on a test system or systems, you must install and configure the system hardware, choose the target Windows operating system and install and configure the Device Test Manager (DTM). This section summarizes the display adapter and chipset–related requirements and procedures. For information about installing and configuring the DTM, see Driver Test Manager Introduction.

Note To obtain more accurate test results, run the display tests on two differently configured systems.

Test System Configuration

Use the following procedure to prepare the test systems for testing display adapters for your target operating system.

To configure test systems for display adapter testing
  1. Install the test devices on two (or more) differently configured test systems.
  2. Install the multi-sync display data channel standard, level 2B (DDC2B)-capable monitor with EDID 1.3 support on the test systems.

    Note The secondary head of a multiheaded display adapter or chipset must be connected to a monitor and enabled before tesing starts. Not all devices that support multiple heads must be enabled but at lease one for each asic family that is listed in the INF file.

  3. On each test system, install the target Microsoft Windows operating system.
  4. Install the test device driver on each system.
  5. If you have not done so already, install the the DTM controller and the DTM Studio.
  6. On each test system, install the DTM client. For more information, see Driver Test Manager Introduction.
  7. On the controller, update Displaygroups.xml with the agreed upon asic family breakout (in <InstallDrive>\Program Files\Microsoft Driver Test Manager\Tests\x86fre\nttest\MultimediaTest\Video\)
  8. After the DTM client software is installed, copy the updated Displaygroups.xml to the client system (in <InstallDrive>\Program Files\Microsoft Driver Test Manager\client) and restart the system.

Before you start a display test run, close any active application (including Windows Explorer and Microsoft Internet Explorer) on the test system.


Running the Display Adapter Tests

After you have installed the test devices and drivers in the test clients and have set up the DTM controller, studio, and clients, you can begin running the logo tests.

To run the display adapter and chipset logo tests
  1. Start DTM Studio.
  2. Open Job monitor.
  3. Create a machine pool to be used for the submission.
  4. Right-click the machine pool, and click Properties.
  5. Click the MCU Policy tab, under Available Dimensions click WDK\ConfigureDisplayAdapter, click Add, and then click OK.
  6. Move all test systems in to the newly created machine pool and ensure the machine status is set to reset.
  7. Make sure DisplayGroup.xml is updated with the proper ASIC grouping. You can find this file on the controller under \\<controllername>\tests\x86fre\nttest\Multimediatests\video.
  8. Copy DisplayGroup.xml from the controller to %RootDrive%\Program Files\Microsoft Driver Test Manager\client on the client computer, and restart the client.
  9. Switch to the Device Selection window, or open a new Device Selection window by clicking Explorers and then clicking Device Selection.
  10. In the View By field, select the submission button.
  11. In the submission menu, click New submission.
  12. Follow the steps in the Submission Wizard. After you complete the wizard, you will have a set of jobs.
  13. Select the main job tree to run all of the jobs that are listed or choose the jobs individually and then click Add selected.
    At this time, jobs are presented in the bottom pane. This list of job is based on the following:
    • The information you entered in the Submission Wizard.
    • Display devices that are listed in the INF file.
    • Devices in the machine pool.
    • DisplayGroups.xml.
    • Attributes of the jobs.
  14. When you are ready to run the jobs, click the Schedule button.
  15. Use the Job Monitor to track the progress of jobs as they are executed.
  16. When the testing is complete, click the Status button in Device Console, review the information that is provided, and correct any issues that DTM identified.
  17. After you verify the status information, select and right-click the Summary icon in the Available Devices pane of Device Console and click Create submission package.

Use the Job Monitor to track the progress of jobs as they are executed.

Use the Result Explorer to examine the results of jobs that have completed.

Driver Reliability Signature Program

If you are submitting a driver with your device submission, you must also run the Driver Reliability (DRS) tests and tools. For more information, see Driver Reliability Tools and Tests.


Troubleshooting Display Adapter Testing


Display Monitor Testing Overview

The procedures presented in this section outline the process for testing your Monitor device for proper functionality with the Microsoft Windows operating system. These procedures test your product for proper functionality by using the Microsoft Windows Driver Kit (WDK) and the Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as requried for the device.

If the test device is multifunctional, you must complete the test procedures for each functionally independent, logical device. For example, a display monitor that also provides external USB ports must complete the USB tests.

The test procedures are divided into the following types of topics:

  • Overview: The overview topics describe the hardware, software, and tester knowledge requirements.
  • Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.
  • Running: The running topics describe how to run the tests for your device or system.

Display Adapter Tests

The tests that you need to run depend on the capabilities of the device or system that is being tested. To see the complete list of tests that might be required for your device, see Display Monitor.

Hardware Requirements

The following hardware is required to run the Monitor tests:

  • Two different display data channel standard, level 2B (DDC2B) display adapters that support all resolutions, color depths, and refresh rates that the test monitor supports.
  • All unique display connection types must be tested. For example, if the monitor supported DVI and Dsub connection, both connection must be tested.

Note Display adapters must use manufacturer-supplied drivers that support the operating system that the display monitor is being certified for, and the manufacture-supplied drivers must be from different manufactures.

Software Requirements

The following software is required to run the display monitor testing:

  • Any drivers that are not shipped with the operating system.
  • The setup information file (INF) for the device under test.
  • The Image Color Management (ICM) file, if applicable.

Tester Knowledge Requirements

To run the Monitor tests, testers must know how to accomplish the following tasks:

  • Connect the test monitors to both test systems.
  • Install the display adapters.
  • Install the INF files, if necessary.
  • Install the ICM file, if necessary.

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Preparing for Display Monitor Testing

Before running the display tests on a test system or systems, you must install and configure the system hardware, choose the target Windows operating system and install and configure the Device Test Manager (DTM). This section summarizes the display monitor–related requirements and procedures. For information about installing and configuring the DTM, see the DTM help.

Test System Configuration

You must complete the following procedure to prepare the test system for monitor testing:

To configure the test systems for monitor testing
  1. Install the appropriate operating system on both test systems.
  2. Connect identical test monitors on both test systems.
  3. Install different display data channel standard, level 2B (DDC2B) display adapters on both test systems.
  4. Install the manufacturer-supplied INF file for the display adapter, if necessary, on both test systems.
  5. If appropriate, enable the autologon functionality.
  6. Install the DTM client on both test systems.


Running the Display Monitor Tests

After you have installed the test devices and drivers in the test clients and have set up the DTM controller, studio, and clients, you can begin running the logo tests.

To run the display monitor logo tests
  1. Start DTM Studio.
  2. Open Job monitor.
  3. Create a machine pool for the client systems to go.
  4. Right-click the machine pool, and click Properties.
  5. Click the MCU Policy tab, under Available Dimensions click WDK\ConfigureMonitor, click Add, and then click OK.
  6. Move the client systems to the newly created machine pool.
  7. Switch to the Device Selection window, or open a new Device Selection window by clicking Explorers and then clicking Device Selection.
  8. In the View By field, select the submission button.
  9. In the submission menu, click New submission.
  10. Follow the steps in the Submission Wizard. After you complete the wizard, you will have a set of jobs.
  11. In the Avaliable devices pane, select one of the devices
  12. In the Available jobs pane, click the main job tree to run all of the jobs that are listed, or choose the jobs individually and then click Add selected.
  13. When you are ready to run the jobs, click the Schedule button.
  14. Repeat step 11 – 13 for the other devices in the Avaliable devices pane.
  15. When the testing is complete, click the Status button in Device Console, review the information that is provided, and correct any issues that DTM identified.
  16. After you verify the status information, select and right-click the Summary icon in the Available Devices pane of Device Console and click Create submission package.

Use the Job Monitor to track the progress of jobs as they are executed.

Use the Result Explorer to examine the results of jobs that have completed.

Driver Reliability Signature Program

If you are submitting a driver with your device submission, you must also run the Driver Reliability (DRS) tests and tools. For more information, see Driver Reliability Tools and Tests.


Troubleshooting Display Monitor Testing


Display Tests

Test name Target operating system Test description
Present Validation 2 - Vista Windows Vista
         The test verifies the new flag D3DPRESENT_DONOTFLIP. The driver should skip the present if this flag is set.
WDDM PnPStopVGA Test Windows Vista
         WDDM PnPStopVGA Test - This test generates a PnPStop by disabling the device and checks if the system is in VGA mode.
Blt - Stretch & Color Key - Video Memory to Primary Memory Windows Vista
Windows XP
Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.
GL Coverage Tests Windows Vista
Windows 2000
The GL Coverage test ensures that OpenGL implementation covers all the GL APIs.
WDDM FlipQueue Windows Vista
         The WDDM FlipQueue test verifies that kernel-mode display drivers correctly implement hardware or software flip queuing.
DDRAW Cubic Windows Vista
Windows XP
Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.
Blt - Color Key - Video Memory to Primary Memory Windows Vista
Windows XP
Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.
GL Primitive Tests Windows Vista
Windows 2000
Test analyzes pixel-by-pixel verification, drawing primitively in various rendering modes.
WDDM Eviction Windows Vista
         Eviction - This tests if eviction has been done correctly by the video memory manager.
WDDM System Check Windows Vista
         Test verifies that system supports appropriate display driver model
Present Validation Windows Vista
         Test ensures that the graphics adapter is able to perform Idirect3Ddevice8::Present() calls correctly in all situations, including stretching, shrinking, and destination window overrides.
Memory Leak Verifier Windows Vista
         This test creates and releases numerous resources and checks for memory leaks greater than 1Mb
TVWLPTest : ehome - standard display tests Windows Vista
This discusses ehome - standard display tests. These tests are all enacted by a program called TVWLPTest and up to four DShow filters it invokes.
These job verifies that system is capable of supporting premium Media Center TV playback functionality. Tests portions of GRAPHICS-0001 devoted to content protection, GRAPHICS-0043, and GRAPHICS-0055
Present Validation 2 Windows Vista
The Present Validation test attempts to validate the Preset() method. The main aspects of this test are:
  • To shrink or stretch in height.
  • To shrink or stretch in width.
  • To clip to the source area.
  • To clip to the destination area.
  • To override the destination window.
These aspects of Present are performed individually and in combination, and the resulting output is verified for correctness.
D3D Invalid Parameters - Bad Pointers Windows Vista
         The D3D Invalid Parameters - Bad Pointers test verifies that the system is stable and secure when invalid parameters are passed to the D3D APIs.
CopyRects Functionality (32-bit) Windows Vista
Windows 2000
The test automatically verifies the functionality provided by the IDirect3DDevice8::CopyRects method by comparing surfaces generated by tested operations with reference surfaces generated by the test itself.
Morph - Invalid Params Windows Vista
         The Morph - Invalid Params test verifies system stability when invalid parameters are passed to legacy Direct3D APIs.
Fast User Switching - D3DTest Windows Vista
         Tests video drivers when D3D components are used, on one or more users, and fast-user-switching occurs.
H.264 Display Test Windows Vista
         H.264 Display tests test the DirectX VA 2.0 H.264/AVC specification
Windows SideShow Device Class Test Windows Vista
         This test verifies that a device uses the Windows SideShow class correctly. If a device is created for Windows SideShow, it must use the appropriate class and class driver.
MovieMaker GPU Pipeline WHQL test Windows Vista
         This tool tests if new Microsoft Windows Vista video drivers work correctly with MovieMaker's new Direct3D GPU pipeline rendering engine. The major interest is the support of pixel shader 2.0 and vertex shader 2.0 features that MovieMaker's new effects and transitions rely on.
WDDM Blt Windows Vista
         WDDM Blt is a stability test for the user-mode Blt DDI.
WDDM PresentHistory Windows Vista
         The WDDM PresentHistory test verifies that drivers correctly support redirected presentation operation (which is required for windowed-mode DirectX applications to work when the Desktop Window Manager is enabled).
WDDM Fuzzer - Invalid Param Windows Vista
         The WDDM Fuzzer test verifies that kernel-mode drivers are stable when asked to process command buffers that contain invalid data.
Conformance ECP [2] Windows Vista
Windows 2000
Test analyzes pixel-by-pixel verification. The concept of an equivalent computational path, ECP, is introduced to test the same functionalities.
Update Surface (32-bit) Windows Vista
Windows 2000
The test automatically verifies correct implementation of the driver functionality that underlies the IDirect3DDevice9::UpdateSurface method.
DDraw Blt - Basic - AGP to Primary Windows Vista
Windows XP
Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.
Dynamic Resources Windows Vista
         This test concentrates on creating dynamic resources (vertex buffers, index buffers, and textures) and using them with various lock flags. The test renders an image and compares pixels in the source image to an image created by the Microsoft® Direct3D® reference (software rasterizer). The test uses the comparison to verify that none of the buffers were dropped while locked.
Palette Tests Windows Vista
Windows XP
Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.
WDDM PresentStats - Present Statistics Test Windows Vista
         The WDDM PresentStats - Present Statistics Test verifies that drivers work correctly with the operating system to provide reliable presentation statistics to applications.
Blt - Color Key - System Memory to Primary Memory Windows Vista
Windows XP
Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.
You do not need fnswtt.dll to run the test. It's only used for WTT logging.
WDDM TDR Verify Test Windows Vista
         WDDM TDR Verify Test - The test is a user mode test which simulates a TDR and verifies that d3d applications can render after a TDR.
WDDM Blt - Depth Windows Vista
         WDDM Blt - Depth verifies that drivers are stable when asked to perform blts to and from system memory surfaces with depth/stencil formats.
WDDM Toaster - Invalid Param Windows Vista
         The WDDM Toaster - Invalid Param test verifies that the OS is stable and secure in the face of invalid parameters passed to a user-mode display driver.
Fast User Switching - DdrawTest Windows Vista
         Tests video drivers when DDraw components are used, on one or more users, and fast-user-switching occurs.
WGF Draw Windows Vista
         Verifies graphics drivers/hardware D3D Draw behavior meets Microsoft D3D specifications
DXGI Occlusion Windows Vista
         Verifies support for DXGI's occlusion detection.
WGF Vertex Shader Windows Vista
         Verifies graphics drivers/hardware D3D stream out behavior meets Microsoft D3D specifications
DXGI - Presentation testing (32-bit) Windows Vista
         This is an automated test that verifies correct implementation of the IDXGISwapChain::Present method.
WDDM Scheduler Stress (Force Split Points) Windows Vista
         The WDDM Scheduler Stress (Force Split Points) test verifies system stability while running many GPU-bound memory intensive applications when all DMA buffers are split as much as possible.
Automatic Stereo Windows Vista
Windows XP
Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.
WDDM Process Callout Windows Vista
         The WDDM Process Callout test is a stress test that verifies system stability during process destruction.
D3D Invalid Parameters Windows Vista
         The D3D Invalid Parameters test verifies that the system is stable and secure when invalid parameters are passed to the D3D APIs.
Blt - Raster Ops - Vid Mem Windows Vista
Windows XP
Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.
RateTest Windows Vista
The test switches to all enumerated GDI display modes, all available low-resolution GDI low-resolution modes (< 640x480 pixels), and enumerated DirectDraw full-screen modes. The test then intersects these two sets of modes, and validates that the set of DirectX enumerated modes exist in the set of GDI enumerated modes. The test switches to these modes, and validates that the refresh rate actually produced by the card matches the refresh rate that the driver says is being output. Refresh rate is validated using IDirectDraw::GetVerticalBlankStatus. After each mode is set, the test puts up a DOS box, to ensure that virtualization of VGA hardware works correctly for each mode.
Fast User Switching - DVDTest Windows Vista
         Tests video drivers when software DVD playback is running, on one or more users, and fast-user-switching occurs.
WDDM PnPStop Test Windows Vista
         WDDM PnPStop Test - The test disables and enables the display adapter.
WDDM Overlay Windows Vista
         The WDDM Overlay test is a basic test of overlay functionality.
WDDM BVT2 Windows Vista
         This test validates the user-mode display drivers implement basic functionality required by the user-mode DDI.
WDDM Primary Surface Windows Vista
         The WDDM Primary Surface test verifies that drivers correctly implement presentation operations.
WDDM Coherency Windows Vista
         The WDDM Coherency test validates that GPU and CPU accesses to aperture segments are flushed correctly to ensure coherency of the data accesses between both processors.
DXGI - GetAdapterIdentifier and Output Enumeration (32-bit) Windows Vista
         The test verifies correct implementation of IDXGIAdapter::GetAdapterIdentifier and IDXGIAdapter::EnumOutputs.
Missing Resource Stability Windows Vista

Thegraphic driver must ensure that all render targets, textures, and vertex buffers are flushed, and are also handled properly before they are released by the system.
WDDM Sync Windows Vista
         The WDDM Sync test verifies that user-mode drivers properly synchronize the CPU and GPU when resources are used by the CPU and GPU.
Surface Flipping Tests Windows Vista
Windows XP
Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.
DDraw Blt - ColorFill - Video Memory Windows Vista
Windows XP
Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.
DXGI - Frame Statistics Windows Vista
         Verifies support for DXGI's Frame Statistics
Visual GPU Windows Vista
         Visual GPU is a visualization tool. Visual GPU allows its users to visualize the internal workings of the Microsoft Windows Vista graphics kernel and LDDM display drivers. This tool is useful in understanding and debugging performance problems related to LDDM display drivers.
WDDM LockSmith Windows Vista
         The WDDM LockSmith test is a basic test of user-mode display driver locking functionality.
DDraw Blt - ColorFill - AGP Windows Vista
Windows XP
Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.
Update Texture (32-bit) Windows Vista
Windows 2000
Test verifies device capacities to load textures (mipmap, cubemap) from system memory to video memory using UpdateTexture function. The test includes the following scenarios: (1) Load the entire texture. (2) Load a portion of the texture. (3) source and destination texture are square or non square. (4) Source and destination texture have different levels.
Present Validation 2 (FullScreen) Windows Vista
This test verifies that all modes reported by the EnumAdapterModes method for the device are available to applications. The following parameters are considered: the back buffer format, screen resolution, present intervals, swap effects, and multisample types.
The DoNotWait test calls the swap chain's Present method in a loop, passes the D3DPRESENT_DONOTWAIT flag, in full-screen mode, and uses the D3DPRESENT_INTERVAL_ONE value. As a result, the driver’s queue of frames will exceed 3 (maximum allowed). The DoNotWait test expects the driver to return control to the application using the D3DERR_WASSTILLDRAWING error code. If the error code is not returned, the test fails.
The LockDoNotWait test is similar to the DoNotWait test, but this test is performed on a surface (the back buffer). The same behavior is expected of the driver. If the error code is not returned, the test fails.
Conformance ECP [1] Windows Vista
Windows 2000
Test analyzes pixel-by-pixel verification. The concept of an equivalent computational path, ECP, is introduced to test the same functionalities.
Vista Fonts Windows Vista
The test verifies the functionality of the ComposeRects API. The drivers should set the D3DPTFILTERCAPS_CONVOLUTIONMONO if they support this feature.
WDDM Max Contexts Windows Vista
         The WDDM Max Contexts test verifies that drivers do not have any hardware limits on the number of rendering contexts can that exist at any given time.
BLT Unused Pixel Bits Windows Vista
Windows XP
Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.
WDDM Blt - Stretch Windows Vista
         The WDDM Blt - Stretch test verifies that user-mode display drivers correctly implement stretching blt operations.
WGF Input Assembler Windows Vista
         Verifies graphics drivers/hardware D3D input assembler behavior meets Microsoft D3D specifications.
Windows SideShow Enhanced Device Test Windows Vista
         This test verifies that a device uses the inbox Windows SideShow diver. This is for Windows SideShow devices that use a USB connection and run the TinyCLR.
CreateSurface Windows Vista
Windows XP
Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.
Alpha Blended Cursor (Manual) Windows Vista
Windows XP
Windows 2000
         The test tool displays an icon on the window and allows the tester to decide if the icon has been drawn correctly or not
WDDM Scheduler Stress (Always Repatch) Windows Vista
         The WDDM Scheduler Stress (Always Repatch) test verifies system stability while running many GPU-bound memory intensive applications when all patch locations are always repatched via the Patch DDI.
WGF Stream Out Windows Vista
         Verifies graphics drivers/hardware D3D stream out behavior meets Microsoft D3D specifications.
WDDM Bit Flip - Invalid Param Windows Vista
         Bit Flip - Invalid Param is an invalid parameter stability test that verifies that kernel-mode display drivers correctly validate command buffers and private driver data passed from user-mode.
Display Power Test (32-bit) Windows Vista
Display Power Test verifies that display device still maintain refresh rate at all supported low-power states.
WDDM Four Character Code Surface Stability Test Windows Vista
         The Four Character Code Surface Stability Test verifies that the system is stable when IHV-specific 4CC surfaces are created and used.
WDDM Blt - DepthFill Windows Vista
         WDDM Blt - DepthFill validates that drivers correctly implement the DepthFill DDI.
PC99 #12 downloadable RAMDAC Windows Vista
Windows XP
Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.
WDDM Handles - Invalid Param Windows Vista
         The WDDM Handles - Invalid Param test verifies that kernel-mode drivers are stable when asked to process invalid handles.
WDDM Deadlock Windows Vista
         The WDDM deadlock test verifies that user-mode and kernel-mode drivers correctly synchronize calls from multiple processes and threads.
GL Utilities Coverage Tests Windows Vista
Windows 2000
The GL Utilities Coverage test ensures that OpenGL implementation covers all the GL Utility APIs.
TVOut Test Windows Vista
TVOut Test is a quality assurance application for display card secondary output ports (generically referred to as TV Output ports).
WDDM PnPStop Device Test Windows Vista
         WDDM PnPStop Device Test - This test disables the display adapter.
WDDM Passthrough Windows Vista
         The WDDM Passthrough test verifies that user-mode display drivers correctly handle failures originating from runtime callbacks.
TVWLPTest : ehome - premium display tests Windows Vista
This discusses ehome - premium display tests. These tests are all enacted by a program called TVWLPTest and up to four DShow filters it invokes.
These job verifies that system is capable of supporting premium Media Center TV playback functionality. Tests portions of GRAPHICS-0001 devoted to content protection, GRAPHICS-0043, and GRAPHICS-0055
WDDM Sch_Stress Windows Vista
         The WDDM Sch_Stress test verifies system stability while running many GPU-bound memory intensive applications.
Video Memory Management Tests Windows Vista
Windows XP
Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.
You do not need fnswtt.dll unless you want WTT logging.
Read Scan Line Windows Vista
Windows XP
Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.
Blt Basic - System Memory to Primary Memory Windows Vista
Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.
Blt - Stretch - Video Memory to Primary Memory Windows Vista
Windows XP
Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.
WDDM ManagedPrimary Windows Vista
         The WDDM ManagedPrimary test verifies that display drivers correctly implement managed primary functionality.
DDraw AGP Memory Tests Windows Vista
Windows XP
Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.
DXGI - Mode Enumeration (32-bit) Windows Vista
         The test verifies correct implementation of IDXGIOutput::FindClosestMatchingMode.
Fast User Switching - VideoTest Windows Vista
         Tests video drivers when an MPEG video is being played, on one or more users, and fast-user-switching occurs.
PC99 #3 system uses WC Windows Vista
Windows XP
Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.
Blt - Exotic Windows Vista
Windows XP
Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.
WDDM Passthrough - QueryResidency Windows Vista
         The WDDM Passthrough - QueryResidency test ensures that drivers correctly implement the QueryResourceResidency DDI.
DDraw Blt - Stretch - AGP to Primary Windows Vista
Windows XP
Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.
Blt - Stretch & Color Key - System Memory to Primary Memory Windows Vista
Windows XP
Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.
WDDM PnPStart Device Test Windows Vista
         PnPStart Device Test - The tests enables the display adapter.
Color Fill (64-bit) Windows Vista
Windows 2000
This test verifies proper implementation of the driver functionality that supports the Direct3D9 method IDirect3DDevice9::ColorFill.
DDraw Blt - Stretch & Color Key - AGP to Primary Windows Vista
Windows XP
Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.
Wait For VBlank (32-bit) Windows Vista
         The test verifies proper driver implementation of the vertical blank synchronization functionality that underlies the implementation of IDirect3DDevice9Ex::WaitForVBlank.
Registry Validation Windows Vista
Windows 2000
         This test verifies that display drivers create the correct registry entries.
Conformance ECP [-] Windows Vista
Windows 2000
Test analyzes pixel-by-pixel verification. The concept of an equivalent computational path, ECP, is introduced to test the same functionalities.
Update Surface (64-bit) Windows Vista
Windows 2000
The test automatically verifies correct implementation of the driver functionality that underlies the IDirect3DDevice9::UpdateSurface method.
Stretch Rect (64-bit) Windows Vista
Windows 2000
         The test automatically verifies correct implementation of the driver functionality that underlies the IDirect3DDevice9::StretchRect method.
COPPTest Windows Vista
         These tests execute COPP commands to test display drivers for COPP compatibility.
OPMTest Windows Vista
         These tests execute OPM commands to test display drivers for OPM compatibility.
WDDM SetDXMode Windows Vista
         The WDDM SetDXMode test verifies that display drivers can successful set all display modes that they enumerate.
DDraw Blt - Color Key - AGP to Primary Windows Vista
Windows XP
Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.
WDDM ModeChange Windows Vista
         The WDDM ModeChange test verifies system stability during display mode changes.
Blt - Textures Windows Vista
Windows XP
Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.
Stretch Rect (32-bit) Windows Vista
Windows 2000
The test automatically verifies correct implementation of the driver functionality that underlies the IDirect3DDevice9::StretchRect method.
Color Fill (32-bit) Windows Vista
Windows 2000
This test verifies proper implementation of the driver functionality that supports the Direct3D9 method IDirect3DDevice9::ColorFill.
WDDM Sync - VolBlt Windows Vista
         The WDDM Sync VolBlt test verifies that user-mode drivers properly synchronize the CPU and GPU when resources are used by the CPU and GPU.
WDDM Passthrough - Lock Windows Vista
         The WDDM Passthrough test verifies that user-mode display drivers correctly handle failures originating from runtime callbacks.
Blt Basic - Video Memory to Primary Memory Windows Vista
Windows XP
Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.
WDDM Scheduler Stress (No PrePatching) Windows Vista
         The WDDM Scheduler Stress (No PrePatching) test verifies system stability while running many GPU-bound, memory intensive applications when pre-patching of DMA buffers is disabled.
CopyRects Functionality (64-bit) Windows Vista
Windows 2000
The test automatically verifies the functionality provided by the IDirect3DDevice8::CopyRects method by comparing surfaces generated by tested operations with reference surfaces generated by the test itself.
WDDM GammaRamp Windows Vista
         The WDDM GammaRamp test verifies that kernel-mode display drivers succeed attempts to set gamma ramps.
WDDM ModifyVAD Windows Vista
         The WDDM ModifyVAD test verifies that drivers correctly protect accesses to user-mode virtual addresses.
D3D Cross Process Sharing Windows Vista
Verify support for D3D9L Cross process resource sharing.
VPE and Kernel Tests Windows Vista
Windows XP
Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.
Conformance ECP [3] Windows Vista
Windows 2000
Test analyzes pixel-by-pixel verification. The concept of an equivalent computational path, ECP, is introduced to test the same functionalities.
WDDM HPD Notification Test Windows Vista
         WDDM HPD Notification Test -Test for HPD removal and arrival notification event.


Present Validation 2 - Vista

Type: Automated Test

Overview

The test verifies the new flag D3DPRESENT_DONOTFLIP. The driver should skip the present if this flag is set.

Details

The test verifies that no presentation happens when D3DPRESENT_DONOTFLIP is specified. The test first renders with regular Present and then verifies the front buffer is not modified when the flag is used.
Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running Present Validation 2 - Vista

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WDDM PnPStopVGA Test

Type: Automated Test

Overview

WDDM PnPStopVGA Test - This test generates a PnPStop by disabling the device and checks if the system is in VGA mode.

Details

WDDM PnPStopVGA Test - In the new windows driver model for Longhorn, when the display device is disables, the system should be in VGA mode. This is done by checking the registry entry for value of
InstalledDisplayDrivers for the specified device key to be "vga". The test also checks for
the card to support 10x7 for 32bpp and 24bpp.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM PnPStopVGA Test

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification

Additional Information:


Blt - Stretch & Color Key - Video Memory to Primary Memory

Type: Automated Test

Overview

Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.

Details

Test ensures that the DirectDraw graphics adapter is able to process combinations of stretched (and shrunk) blts as well as SOURCE and DESTINATION color key blts from video memory to the primary surface.
The follow Fnddraw cases make up this test
BLT,Stretch(width only), SRCKEY, VMem to pri
BLT,Stretch, SRCKEY, VMem to primary
Test Executable: Fnddraw.exe

Run Time: 00:12:30
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Display adapater with DDraw capabilities

Running Blt - Stretch & Color Key - Video Memory to Primary Memory

No specific steps to follow for this test

Command Syntax

Command option | Description
fnddraw.exe dd_sckvv.pro -r -c -p"m%MONITOR%" | The %monitor% parameter needs to be replaced with a 1 based index that corresponds to the display under test.

Cautions

The screen saver should be turned off and the power management should be disabled before running this test. Mode changes, full screen apps can cause failures and should be avoided.

Reference Documentation

DirectX SDK (Version 7.0 or Later)

Code Tour

File Manifest

File | Location
fnddraw.exe | multimediatest\video\ddraw
fnswtt.dll | multimediatest\video\ddraw
dd_sckvv.pro | multimediatest\video\ddraw\pro

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


GL Coverage Tests

Overview

The GL Coverage test ensures that OpenGL implementation covers all the GL APIs.

Details

The GL Coverage tests are designed to test all API functions within the OpenGL 1.1 library. Specified valid and invalid parameters are passed to these functions to ensure they are handled properly.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Windows 2000
  • Windows 9x
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running GL Coverage Tests

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WDDM FlipQueue

Type: Automated Test

Overview

The WDDM FlipQueue test verifies that kernel-mode display drivers correctly implement hardware or software flip queuing.

Details

The WDDM FlipQueue test uses the GPU to render on many GPU device contexts simultaneously. One of the context does flipping operations. If the driver correctly implements hardware or software flip queuing, then the flipping operations submitted by one context will not cause the GPU to stall and starve the other contexts. Drivers pass this test if the non-flipping contexts are not starved.
Run Time: 5 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM FlipQueue

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-69 Display adapter or chipset complies with the DirectX DDK specification
Test Assertion GUID: 7af8c5fb-d668-426c-a663-5c27038e8a01

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification

Additional Information:


DDRAW Cubic

Type: Automated Test

Overview

Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.

Details

This creates attempts to create a variety of valid and invalid cubic maps, and verifies the driver handles it properly. This test only runs if the driver supports cubic environment maps for 3D.
Test Executable: Fnddraw.exe

Run Time: 00:00:05
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Display adapater with DDraw capabilities

Running DDRAW Cubic

No specific steps to follow for this test

Command Syntax

Command option | Description
fnddraw.exe dd_cube.pro -r -c -p"m%MONITOR%" | The %monitor% parameter needs to be replaced with a 1 based index that corresponds to the display under test.

Cautions

The screen saver should be turned off and the power management should be disabled before running this test. Mode changes, full screen apps can cause failures and should be avoided.

Reference Documentation

DirectX SDK (Version 7.0 or Later)

Code Tour

File Manifest

File | Location
fnddraw.exe | multimediatest\video\ddraw
fnswtt.dll | multimediatest\video\ddraw
dd_cube.pro | multimediatest\video\ddraw\pro

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Blt - Color Key - Video Memory to Primary Memory

Type: Automated Test

Overview

Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.

Details

This series of tests performs color keyed blts from offscreen video memory to the primary. Blt results are compared against a simulation using either GDI operations or the test’s internal software blitter. Images are expected to match exactly.
Drivers are required to support source color key Blts between video memory surfaces. Destination color key blts and “space” blts are optional.
The follow Fnddraw cases make up this test
BLT, DESTKEY Space, VMem to Primary
BLT, single DESTKEY, VMem to Primary
BLT, SRCKEY Space, VMem to Primary
BLT, single SRCKEY, VMem to Primary
Test Executable: Fnddraw.exe

Run Time: 00:10:10
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Display adapater with DDraw capabilities

Running Blt - Color Key - Video Memory to Primary Memory

No specific steps to follow for this test

Command Syntax

Command option | Description
fnddraw_dct.exe ..\pro\dd_ckvv.pro -r -c -p"m%MONITOR%" | The %monitor% parameter needs to be replaced with a 1 based index that corresponds to the display under test.

Cautions

The screen saver should be turned off and the power management should be disabled before running this test. Mode changes, full screen apps can cause failures and should be avoided.

Reference Documentation

DirectX SDK (Version 7.0 or Later)

Code Tour

File Manifest

File | Location
fnddraw.exe | multimediatest\video\ddraw
fnswtt.dll | multimediatest\video\ddraw
dd_ckvv.pro | multimediatest\video\ddraw\pro

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


GL Primitive Tests

Overview

Test analyzes pixel-by-pixel verification, drawing primitively in various rendering modes.

Details

The GL Primitive Tests check the functionality of various OpenGL operations, drawing primitively in various rendering modes, to ensure the driver's implementation is valid. A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Any detected failure generates additional information that clearly identifies the non-compliant issue. Each test allows up to 10 failures before a fail is considered.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Windows 2000
  • Windows 9x
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running GL Primitive Tests

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WDDM Eviction

Type: Automated Test

Overview

Eviction - This tests if eviction has been done correctly by the video memory manager.

Details

Eviction - There might not be enough free video memory available to bring all the resources required by a DMA buffer in, in which case some resources currently in memory needs to be evicted. The test creates a reference image without eviction taking place. It then creates multiple images with large resources which ensures that eviction will take place. Each of these images is compared with the reference image. If eviction has been carried out correctly the two images should be identical.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM Eviction

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification

Additional Information:


WDDM System Check

Type: Automated Test

Overview

Test verifies that system supports appropriate display driver model

Details

Test checks for following:
  1. If system includes multiheaded solutions, multiple adapter solutions, or a combination of these, it must use the same graphics vendor and type when using Windows WDDM.
  2. If system is a standalone server, graphics driver is expected to be built off the XDDM if 3D acceleration is not supported, or off the WDDM otherwise.

Run Time: 1 minute
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM System Check

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:

Windows Logo Program:

Additional Information:


Present Validation

Type: Automated Test

Overview

Test ensures that the graphics adapter is able to perform Idirect3Ddevice8::Present() calls correctly in all situations, including stretching, shrinking, and destination window overrides.

Details

Test ensures that the graphics adapter is able to perform Idirect3Ddevice8::Present() calls correctly in all situations, including stretching, shrinking, and destination window overrides. A reference image used by d3dx will be used for comparison.
Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running Present Validation

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

5.43.1 Present Validation test.
Test Assertion GUID:


Memory Leak Verifier

Type: Automated Test

Overview

This test creates and releases numerous resources and checks for memory leaks greater than 1Mb

Details

This test creates and releases numerous resources and checks for memory leaks greater than 64 KB. The test also checks for memory leaks when rendering from buffers and when resetting the device.
Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running Memory Leak Verifier

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

5.309.1 Drivers must not leak memory between calls to create the resource and calls to release the resource.
Test Assertion GUID:

5.309.2 Drivers must not leak memory when drawing from buffers.
Test Assertion GUID:


TVWLPTest : ehome - standard display tests

Type: Automated Test

Overview

This discusses ehome - standard display tests. These tests are all enacted by a program called TVWLPTest and up to four DShow filters it invokes.
These job verifies that system is capable of supporting premium Media Center TV playback functionality. Tests portions of GRAPHICS-0001 devoted to content protection, GRAPHICS-0043, and GRAPHICS-0055

Details

TvWLPTest is a command line program invoked by the DTM that verifies most of the Media Center requirement. Any failures on any requirment will cause the whole job to fail.

GRAPHICS-0001

This tests the content protection portion of this requirement. Other parts of this requirement are tested in the <> test?
Title: Test Display Adaptor Supports and Exposes Video Output Connector
Success:
This test will succeed if the display adapter supports APS or Macrovision copy protection. It will succeed if display adapter expose required timings. It will succeed if test able to switch TV-out to TV playback mode while TV-out connected to TV Display device and while in this mode display adapter disables flicker filter and overscan compensation. Also it should be in proper TV standard that is NTSC, PAL or SECAM. Then test will switch it to Win Graphics mode while TV-out connected to VGA Display device and if it will switch successfully test will succeed. Also, display adapter must have TV standard set to WIN VGA in order to pass the test.
Failure:
This test will fail if the user aborts the test. If display adapter does not supports APS or Macrovision copy protection. If it does not expose required timings. It also will fail if test will not be able to switch TV-out to TV playback mode while TV-out connected to TV Display device. If display adapter does not disable flicker filter and overscan compensation while in TV playback mode and does not report proper TV standard such as NTSC, PAL, SECAM. It will also fail if driver fails to report required values that used to determine if it in proper mode and have disabled flicker filter and overscan compensation. It will fail in test enable to switch it to Win Graphics mode while TV-out connected to VGA Display adapter and if it does not have WIN VGA TV standards on TV-out while in this mode. Also, it will fail if test fails to set TV Standards and playback modes or driver fails to report required values.

GRAPHICS-0043

Title: Test Display Driver Supports Minimum Display Timing and Modes
Success:
This test will succeed if the display device supports required timings and modes.
Failure:
This test will fail if one or more of the required timings or modes are not supported by the display adapter.

GRAPHICS-0055

Title: Test Display Sub-System Supports Digital TV Resolution and Timing
Success:
This test will succeed if the display device has a digital interfaces and support required digital timings and modes. It will also succeed if the display adapted does not have a digital interface, because this test does not required timings and modes to be checked for display adapters that do not have a digital interface.
Failure:
This test will fail if a display adaptor with a digital interface does not support one or more of the required digital timings or modes.

Run Time: 1 min
Log File: TVWLPTest.xml
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running TVWLPTest : ehome - standard display tests

) Run this job
- this will iterate and test each of the requirements listed above
2) Handle prompts as they occur.

Command Syntax

Command option | Description
tvwlptest <test case ID> “<Device ID of device you want to test>” |

Troubleshooting
An analog TV monitor of the correct broadcast format. If the card supports digital TV output, a digital TV to connect to. For portable devices, a external computer monitor is also required.

Code Tour

File Manifest

File | Location
TVWLPTest.exe |
TVWLPAudioMonitor.ax |
TVWLPSourceFilter.ax |
TVWLPMPeg2Monitor.ax |
TVWLPVBIMonitor.ax |

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Present Validation 2

Type: Automated Test

Overview

The Present Validation test attempts to validate the Preset() method. The main aspects of this test are:
  • To shrink or stretch in height.
  • To shrink or stretch in width.
  • To clip to the source area.
  • To clip to the destination area.
  • To override the destination window.
These aspects of Present are performed individually and in combination, and the resulting output is verified for correctness.

Details

ColorConverting:
This test is similar the standard Present Validation test, except this test resets the device into a state where the back buffer and the front buffer have different formats (only if the call to the CheckDeviceFormatConversion method was successful). The test performs a comparison with a reference image generated by the Microsoft® Direct3D® (D3D) application programming interface. The driver is required to perform the color conversion between those two formats (no software emulation is performed by D3D).
GammaPresent:
This test uses the IDirect3DSwapChain9::Present method with the D3DPRESENT_LINEAR_CONTENT flag.
If the driver supports gamma presentation (the driver exposes the D3DCAPS3 capabilities flag D3DCAPS3_LINEAR_TO_SRGB_PRESENTATION) a gamma corrected presentation is expected. This test verifies the correct output by post processing the reference image using gamma 2.2 correction. If the driver claims that gamma presentation is not supported, the test verifies that no gamma correction is performed.
The test performs the following operations:
  • Scales the color channels to [0..1).
  • Calculates Channel = pow( Channel, 1 / Gamma ).
  • Scales the result back to int [0..256).
Gamma presentation is only supported on a 32-bit color depth desktop.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running Present Validation 2

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

5.306.1 If supported, the driver correctly performs color conversion between the back buffer and the front buffer (if their formats are different).
Test Assertion GUID:

5.307.1 Gamma presentation is only supported on a 32-bit color depth desktop.
Test Assertion GUID:

5.307.2 The driver must perform gamma correction if the D3DCAPS3_LINEAR_TO_SRGB_PRESENTATION flag is set and if the D3DPRESENT_LINEAR_CONTENT flag is requested by the application in the call to Present.
Test Assertion GUID:

5.307.3 The driver must not perform gamma correction if the D3DCAPS3_LINEAR_TO_SRGB_PRESENTATION flag is not set, regardless of the flag the application requested in the call to Present.
Test Assertion GUID:

5.43.1 Present Validation 2 test
Test Assertion GUID:


D3D Invalid Parameters - Bad Pointers

Type: Automated Test

Overview

The D3D Invalid Parameters - Bad Pointers test verifies that the system is stable and secure when invalid parameters are passed to the D3D APIs.

Details

The D3D Invalid Parameters - Bad Pointers test calls the Direct3D APIs with invalid memory pointers. Some of these invalid pointers are passed on to the display driver. Display drivers must do parameter validation on data generated by user-mode clients to ensure that the system does not crash or hang.
Run Time: 45 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running D3D Invalid Parameters - Bad Pointers

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-70 Display driver functions properly, and does not generate hangs or faults, under prolonged stress
Test Assertion GUID: 85ad15b6-d938-43d0-9142-094375997519

Windows Logo Program: GRAPHICS-0038 Display driver functions properly and does not generate hangs or faults under prolonged stress

Additional Information:


CopyRects Functionality (32-bit)

Type: Automated Test

Overview

The test automatically verifies the functionality provided by the IDirect3DDevice8::CopyRects method by comparing surfaces generated by tested operations with reference surfaces generated by the test itself.

Details

For each D3D8 format, the test uses IDirect3D8::CheckDeviceFormat to determine the surface types, if any, supported by the driver. The test then generates representative surfaces for each combination of format and surface type and performs a set of CopyRects operations for each pair of source and destination surfaces that share the same format. These operations include full-surface copies, subrect copies with and without translation, and copies of multiple overlapping rectangles. In each case, the result of the operation is evaluated automatically by comparing the content of the destination surface with that of a reference surface generated by the test.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Windows 2000
  • Windows 9x
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86

Running CopyRects Functionality (32-bit)

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Automatic Verification of IDirect3DDevice8::CopyRects.
Test Assertion GUID: 5.13.1


Morph - Invalid Params

Type: Automated Test

Overview

The Morph - Invalid Params test verifies system stability when invalid parameters are passed to legacy Direct3D APIs.

Details

The Morph - Invalid Params test passes invalid parameters to legacy (DirectX 6 and below) Direct3D APIs. The Direct3D APIs pass many of these invalid parameters to the user-mode display driver. The display driver must validate enough parameters to ensure that the system does not crash or hang while running this test.
Run Time: 1 hours
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running Morph - Invalid Params

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-70 Display driver functions properly, and does not generate hangs or faults, under prolonged stress
Test Assertion GUID: 85ad15b6-d938-43d0-9142-094375997519

Windows Logo Program: GRAPHICS-0038 Display driver functions properly and does not generate hangs or faults under prolonged stress

Additional Information:


Fast User Switching - D3DTest

Overview

Tests video drivers when D3D components are used, on one or more users, and fast-user-switching occurs.

Details

This test will create users on a system and start a D3D application on one of the users. Without logging the user out, it will switch to another user via Fast User Switching and start D3D application on that user as well. In a process of the test user switching will happen multiple times. Test failures indicate problems such as failure to switch the user or failure to launch a D3D application on a user. The purpose of the test is to make sure that video drivers do not bugcheck while user switching occurs.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running Fast User Switching - D3DTest

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


H.264 Display Test

Type: Automated Test

Overview

H.264 Display tests test the DirectX VA 2.0 H.264/AVC specification

Details

N/A
Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running H.264 Display Test

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

H.264 Display Test Automated
Test Assertion GUID: 83110BFD-73E6-40f9-9B41-4858F4F3E1CC


Windows SideShow Device Class Test

Type: Automated Test

Overview

This test verifies that a device uses the Windows SideShow class correctly. If a device is created for Windows SideShow, it must use the appropriate class and class driver.

Details

This test verifies that a device uses the Windows SideShow class correctly. Any Windows SideShow device must belong to the Windows SideShow class of devices so that a use can enable and disable gadgets on these devices from the Windows SideShow control panel. If a device is created for Windows SideShow, it must use the appropriate class driver.
To run the Windows SideShow basic device logo test:
1. Start DTM studio.

2. Click the Explorers then click Device Console. (see attached sideshow.jpg)

3. From the Machine Pool list, select the machine pool that contains the computer on which you want to run test.

4. In the View by option box, select Device.

5. In the Available devices pane, expand SideShow, then select the specific device to run the test. The name of the computer is show after the device name.
6. In the Available Jobs pane, select “WDKLogoTestEnhancedInf” test jobs

7. Click Add Selected.

8. From the added jobs, use mouse right button to click “WDKLogoTestEnhancedInf” to bring up a pop menu and select “Edit Parameters…” menu item.

9. Update the schedule value of “InfFieName” to point to the test device inf file name with full path. (see attached InfFileName.jpg)

10. When you are ready to run the jobs, select “Load”

11. Use the Job Monitor to track the progress of jobs as they are executed

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running Windows SideShow Device Class Test

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


MovieMaker GPU Pipeline WHQL test

Overview

This tool tests if new Microsoft Windows Vista video drivers work correctly with MovieMaker's new Direct3D GPU pipeline rendering engine. The major interest is the support of pixel shader 2.0 and vertex shader 2.0 features that MovieMaker's new effects and transitions rely on.

Details

This tool compares bitmaps generated from new video card with reference bitmaps generated by "known good" card and driver. It contains flowing tests:
  • Content Types: which will verify major media file types (avi, mpeg, and so on)
  • Effect
  • Titles
  • Credits
  • Geometry transitions
During the test, pipelinetest.exe will be launched, which will go through all tests listed above, do the bitmap comparison, and display pass/fail information onto the console screen, as well as write WTT logs. It will tolerate some pixel difference.
During each test, pipelinetest.exe will seek through five timeline points, generate a bitmap from video card buffer for each seek point, and do a pixel-wise comparison with the reference bitmap.
Test executable:
cppunittest.exe, pipelinewhqltests.dll, pipelinetest.exe
Other files listed in install steps are also needed. Among them pipeline.dll - the core pipeline engine.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running MovieMaker GPU Pipeline WHQL test

No specific steps to follow for this test

Command Syntax

Command option | Description
cppunittests.exe /module:pipelinewhqltests.dll /NoBreak |

Code Tour

File Manifest

File | Location
all contents from multimediatestdata\REDIST\vmg\Pipeline | multimediatest\vmg\content\pipeline
All other files listed above | multimediatest\vmg\pipelinewhql

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WDDM Blt

Type: Automated Test

Overview

WDDM Blt is a stability test for the user-mode Blt DDI.

Details

WDDM Blt verifies system stability when performing valid video and system memory surface blt operations. This test performs surface blts between a variety of surface types and memory pools. LDDM drivers must not crash in user or kernel mode when running this test.
Run Time: 20 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM Blt

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-69 Display adapter or chipset complies with the DirectX DDK specification
Test Assertion GUID: 7af8c5fb-d668-426c-a663-5c27038e8a01

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification

Additional Information:


WDDM PresentHistory

Type: Automated Test

Overview

The WDDM PresentHistory test verifies that drivers correctly support redirected presentation operation (which is required for windowed-mode DirectX applications to work when the Desktop Window Manager is enabled).

Details

The WDDM PresentHistory test simulates redirected presentation operations by calling the user-mode Blt DDI. It then verifies that the user-mode driver responded to the Blt DDI by calling RenderCB exactly once. Drivers must behave this way to correctly support redirected presentation operations.
Run Time: 2 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM PresentHistory

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-69 Display adapter or chipset complies with the DirectX DDK specification
Test Assertion GUID: 7af8c5fb-d668-426c-a663-5c27038e8a01

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification

Additional Information:


WDDM Fuzzer - Invalid Param

Type: Automated Test

Overview

The WDDM Fuzzer test verifies that kernel-mode drivers are stable when asked to process command buffers that contain invalid data.

Details

The WDDM fuzzer test intercepts command buffers and other private driver data sent from the user-mode driver to the kernel-mode driver. The test randomly modifies the contents of the buffers and private driver data before the data is sent to the kernel. Drivers must not cause the system to crash or hang while running this test.
Run Time: 30 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM Fuzzer - Invalid Param

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-70 Display driver functions properly, and does not generate hangs or faults, under prolonged stress
Test Assertion GUID: 85ad15b6-d938-43d0-9142-094375997519

Windows Logo Program: GRAPHICS-0038 Display driver functions properly and does not generate hangs or faults under prolonged stress

Additional Information:


Conformance ECP [2]

Overview

Test analyzes pixel-by-pixel verification. The concept of an equivalent computational path, ECP, is introduced to test the same functionalities.

Details

The Conformance ECP [x] tests check the functionality of various OpenGL operations to ensure the driver's implementation is valid. This includes viewport clamping and transformations, matrix stacks, vertex orders, transforms, buffer operations, color ramping, masking, selection, feedback, clipping, alpha and stencil planes, dithering, logical operations, pixel operations, rasterizations, polygon operations, lighting, fog, texture mapping, mipmapping, display lists, and evaluator vertex testing.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Windows 2000
  • Windows 9x
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running Conformance ECP [2]

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Update Surface (32-bit)

Type: Automated Test

Overview

The test automatically verifies correct implementation of the driver functionality that underlies the IDirect3DDevice9::UpdateSurface method.

Details

The test uses IDirect3D9::CheckDeviceFormat to determine the combinations of formats and surface types supported by the driver.
For all valid surface type combinations, the test performs a comprehensive set of UpdateSurface operations including full surface and subrect copies, with and without translation.
Automatic verification is accomplished by rendering both the destination surface and a reference surface and comparing the rendered images. The test uses D3DX9's LoadSurfaceFromSurface function to prepare reference images.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Windows 2000
  • Windows 9x
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86

Running Update Surface (32-bit)

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


DDraw Blt - Basic - AGP to Primary

Type: Automated Test

Overview

Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.

Details

Test ensures that the DirectDraw graphics adapter FNDDRAW blt function is capable of handling several conversion blts from various memory surfaces.
Test Executable: Fnddraw.exe

Run Time: 00:05:05
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Display adapater with DDraw capabilities

Running DDraw Blt - Basic - AGP to Primary

No specific steps to follow for this test

Command Syntax

Command option | Description
fnddraw.exe dd_avb.pro -r -c -p"m%MONITOR%" | The %monitor% parameter needs to be replaced with a 1 based index that corresponds to the display under test.

Cautions

The screen saver should be turned off and the power management should be disabled before running this test. Mode changes, full screen apps can cause failures and should be avoided.

Reference Documentation

DirectX SDK (Version 7.0 or Later)

Code Tour

File Manifest

File | Location
fnddraw.exe | multimediatest\video\ddraw
fnswtt.dll | multimediatest\video\ddraw
dd_avb.pro | multimediatest\video\ddraw\pro

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Dynamic Resources

Type: Automated Test

Overview

This test concentrates on creating dynamic resources (vertex buffers, index buffers, and textures) and using them with various lock flags. The test renders an image and compares pixels in the source image to an image created by the Microsoft® Direct3D® reference (software rasterizer). The test uses the comparison to verify that none of the buffers were dropped while locked.

Details

This test concentrates on creating dynamic resources (vertex buffers, index buffers, and textures) and using them with various lock flags. The test renders an image and compares pixels in the source image to an image created by the Microsoft® Direct3D® reference (software rasterizer). The test uses the comparison to verify that none of the buffers were dropped while locked.
Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running Dynamic Resources

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

5.85.1 The driver must successfully handle the CreateVertexBuffer method when dynamic usage (D3DUSAGE_DYNAMIC) is specified.
Test Assertion GUID:

5.85.2 The driver must successfully handle all locks on the dynamic vertex buffer, when the locks are set using various combinations of flags and offsets
Test Assertion GUID:

5.85.3 The drivers must correctly render dynamic vertex buffers, even when they are locked multiple times per frame.
Test Assertion GUID:

5.85.4 If a driver supports multiple streams, the driver must be able to correctly render from one static buffer and from one dynamic buffer that is locked multiple times per frame.
Test Assertion GUID:


Palette Tests

Type: Automated Test

Overview

Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.

Details

The Palette test ensures that the DirectDraw graphics adapter verifies palette manipulation.
This test is only partially automated and requires some manual verification.
PAL_GetEntries/SetEntries (8-Bit)(TC 4.5.7, 4.7.7)
PAL_CreatePalette - ALLOW256 Test(TC 2.6.12)
PAL_CreatePalette - Init 256 clrs(TC 2.6.9)
Test Executable: Fnddraw.exe

Run Time: 00:06:00
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Display adapater with DDraw capabilities

Running Palette Tests

No specific steps to follow for this test

Command Syntax

Command option | Description
fnddraw.exe dd_pal.pro -r -c -p"m%MONITOR%" | The %monitor% parameter needs to be replaced with a 1 based index that corresponds to the display under test.

Cautions

The screen saver should be turned off and the power management should be disabled before running this test. Mode changes, full screen apps can cause failures and should be avoided.

Reference Documentation

DirectX SDK (Version 7.0 or Later)

Code Tour

File Manifest

File | Location
fnddraw.exe | multimediatest\video\ddraw
fnswtt.dll | multimediatest\video\ddraw
dd_pal.pro | multimediatest\video\ddraw\pro

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WDDM PresentStats - Present Statistics Test

Type: Automated Test

Overview

The WDDM PresentStats - Present Statistics Test verifies that drivers work correctly with the operating system to provide reliable presentation statistics to applications.

Details

The WDDM PresentStats - Present Statistics Test verifies the following scenarios work:
  • For multi-head devices, presentations on 1 swap chain do not affect the present IDs for other swap chains
  • The QPC times reported for v-blanks increase at a rate approximately equal to the refresh rate of the monitor connected to the corresponding output head
  • GPU-bound applications that spin calling the present API (for flipping) should never miss a frame
  • The latency reported by the presentation statistics increase linearly with the maximum number of queued presents (for GPU-bound applications)
  • v-blank IDs reported through the present statistics API agree with the WaitForVerticalBlank API
  • Present statistics work for immediate flips and flips occur during a vertical blank
Drivers must reliably report vertical-blank interrupts and correctly support flipping to pass this test.

Run Time: 20 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM PresentStats - Present Statistics Test

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-69 Display adapter or chipset complies with the DirectX DDK specification
Test Assertion GUID: 7af8c5fb-d668-426c-a663-5c27038e8a01

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification

Additional Information:


Blt - Color Key - System Memory to Primary Memory

Type: Automated Test

Overview

Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.
You do not need fnswtt.dll to run the test. It's only used for WTT logging.

Details

These tests ensure that display drivers which claim to support system to video color key blts, perform them correctly. The tests perform simple source and destination color key blts from system memory to the primary surface. Blt results are compared against a simulation using either GDI operations or the test’s internal software blitter. Images are expected to match exactly.
The follow Fnddraw cases make up this test
BLT, single DESTKEY, System to Primary
BLT, single SRCKEY, System to Primary
Test Executable: Fnddraw.exe

Run Time: 00:20:40
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Display adapater with DDraw capabilities

Running Blt - Color Key - System Memory to Primary Memory

No specific steps to follow for this test

Command Syntax

Command option | Description
fnddraw.exe dd_vvb.pro -r -c -p"m%MONITOR%" | The %monitor% parameter needs to be replaced with a 1 based index that corresponds to the display under test.

Cautions

The screen saver should be turned off and the power management should be disabled before running this test. Mode changes, full screen apps can cause failures and should be avoided.

Reference Documentation

DirectX SDK (Version 7.0 or Later)

Code Tour

File Manifest

File | Location
fnddraw.exe | multimediatest\video\ddraw
fnswtt.dll | multimediatest\video\ddraw
dd_cksv.pro | multimediatest\video\ddraw\pro

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WDDM TDR Verify Test

Type: Automated Test

Overview

WDDM TDR Verify Test - The test is a user mode test which simulates a TDR and verifies that d3d applications can render after a TDR.

Details

WDDM TDR Verify Test - The test simulates a TDR, and verifies a TDR actually occured. It then executes d3d7,d3d8 and d3d9 applications.
Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM TDR Verify Test

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification

Additional Information:


WDDM Blt - Depth

Type: Automated Test

Overview

WDDM Blt - Depth verifies that drivers are stable when asked to perform blts to and from system memory surfaces with depth/stencil formats.

Details

WDDM Blt - Depth verifies that display drivers correctly handle depth blts. In particular this test creates a video memory depth buffer of a supported format, and then creates a system memory lockable depth buffer and asks the driver to blt between them. Drivers must not crash or hang during this test.
Run Time: 10 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM Blt - Depth

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-69 Display adapter or chipset complies with the DirectX DDK specification
Test Assertion GUID: 7af8c5fb-d668-426c-a663-5c27038e8a01

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification

Additional Information:


WDDM Toaster - Invalid Param

Type: Automated Test

Overview

The WDDM Toaster - Invalid Param test verifies that the OS is stable and secure in the face of invalid parameters passed to a user-mode display driver.

Details

The WDDM Toaster - Invalid Param test verifies system stability when invalid parameters are passed to the user-mode driver. Kernel mode drivers must be robust enough to not cause the system to crash or hang when a user-mode driver is given invalid parameters.
Run Time: 2 hours
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM Toaster - Invalid Param

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-70 Display driver functions properly, and does not generate hangs or faults, under prolonged stress
Test Assertion GUID: 85ad15b6-d938-43d0-9142-094375997519

Windows Logo Program: GRAPHICS-0038 Display driver functions properly and does not generate hangs or faults under prolonged stress

Additional Information:


Fast User Switching - DdrawTest

Overview

Tests video drivers when DDraw components are used, on one or more users, and fast-user-switching occurs.

Details

This test will create users on a system and start a DDraw application on one of the users. Without logging the user out, it will switch to another user via Fast User Switching and start DDraw application on that user as well. In a process of the test user switching will happen multiple times. Test failures indicate problems such as failure to switch the user or failure to launch a DDraw application on a user. The purpose of the test is to make sure that video drivers do not bugcheck while user switching occurs.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running Fast User Switching - DdrawTest

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WGF Draw

Type: Automated Test

Overview

Verifies graphics drivers/hardware D3D Draw behavior meets Microsoft D3D specifications

Details

Draw

This is not complete, haven’t thought much about it, just adding cases when they come.
  • Test overflow
  • Incomplete primitives
  • All topologies
    • Cut value needs to be respected
    • Cut complete and imcomplete primitives
  • Draw*Indexed without IndexBuffer
  • Draw*Instanced without Instance data

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WGF Draw

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


DXGI Occlusion

Overview

Verifies support for DXGI's occlusion detection.

Details

DXGIOcclusion cycles through various scenarios pertaining to window state and occlusion, such as a windowed D3D device behind a full-screen D3D device, windowed devices behind other windows, minimization, and so forth.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running DXGI Occlusion

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WGF Vertex Shader

Type: Automated Test

Overview

Verifies graphics drivers/hardware D3D stream out behavior meets Microsoft D3D specifications

Details

Basic cases with buffers

This is to validate simple cases that should work
  • Make sure that indices are respected for IB
  • Make sure that buffer bound as a view works
  • Make sure that VB works
  • Make sure that Constant Buffers works
  • Cycle through all valid buffer usages and some sizes
  • Try huge buffers
  • Bind max number of buffers, with each buffer of a different usage/pool/cpuaccess
  • Overflow
    • Indices > number of vertices
    • 2 vb: one too small, only small should overflow

Read From Unbound Buffer Slot

  • Read from a buffer when not set (VB, IB, Views, Constant) should return default value

Generated Values

  • Generated values should reset for each draw
  • Make sure that all VS Generated values are generated correctly
    • No buffer bound, id’s should be generated correctly
    • When only IB is used, VertexID should be the IB Values
    • Also try IB smaller than number of vertices to draw

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WGF Vertex Shader

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


DXGI - Presentation testing (32-bit)

Type: Automated Test

Overview

This is an automated test that verifies correct implementation of the IDXGISwapChain::Present method.

Details

This test automatically verifies several aspects of the implementation of IDXGISwapChain::Present.
The test creates both windowed and full screen swap chains. It creates back buffers in all supported back buffer formats, using dimensions that either match or differ from those of the output window. In this manner, it comprehensively tests stretching and color-converting Present operations. Full screen test cases are designed to ensure that both flip-based and copy-based Present operations are exercised.
The test also verifies correct implementation of the different DXGI swap effects and uses timing-based test cases to verify correct implementation of presentation intervals.
Automatic verification of presented images is accomplished by using IDXGIOutput::GetDisplaySurfaceData to retrieve the images and comparing these images with the surfaces that were used to initialize the back buffers.

Run Time: 3 hours
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running DXGI - Presentation testing (32-bit)

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WDDM Scheduler Stress (Force Split Points)

Type: Automated Test

Overview

The WDDM Scheduler Stress (Force Split Points) test verifies system stability while running many GPU-bound memory intensive applications when all DMA buffers are split as much as possible.

Details

The WDDM Scheduler Stress (Force Split Points) test creates many processes that do D3D9 rendering with a large video memory working set. This causes preemption and paging to occur on the GPU. The test puts the operating system into a mode that causes it to always use all split points specified by the driver. Display drivers must not cause the system to crash or hang while running this test.
Run Time: 30 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM Scheduler Stress (Force Split Points)

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-70 Display driver functions properly, and does not generate hangs or faults, under prolonged stress
Test Assertion GUID: 85ad15b6-d938-43d0-9142-094375997519

Windows Logo Program: GRAPHICS-0038 Display driver functions properly and does not generate hangs or faults under prolonged stress

Additional Information:


Automatic Stereo

Type: Automated Test

Overview

Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.

Details

Test ensures that the DirectDraw graphics adapter reports stereo caps consistent, and that stereo flipping can be enabled and disabled.
Test Executable: Fnddraw.exe
DirectDraw's Stereo Vision feature was originally designed to take advantage of LCD flicker glasses on supported video cards. To this date, the feature has not been widely adopted by HW or applications, and is not supported by D3D8 or D3D9.

Run Time: 00:00:10
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Display adapater with DDraw capabilities

Running Automatic Stereo

No specific steps to follow for this test

Command Syntax

Command option | Description
fnddraw.exe dd_ster.pro -l"fnswtt.dll" -r -c -p"m%MONITOR%" | The %monitor% parameter needs to be replaced with a 1 based index that corresponds to the display under test.

Cautions

The screen saver should be turned off and the power management should be disabled before running this test. Mode changes, full screen apps can cause failures and should be avoided.

Reference Documentation

DirectX SDK (Version 7.0 or Later)

Code Tour

File Manifest

File | Location
fnddraw.exe | multimediatest\video\ddraw
fnswtt.dll | multimediatest\video\ddraw
dd_ster.pro | multimediatest\video\ddraw\pro

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WDDM Process Callout

Type: Automated Test

Overview

The WDDM Process Callout test is a stress test that verifies system stability during process destruction.

Details

The WDDM Process Callout test creates many processes that do windowed and full-screen d3d9 rendering. The test then asynchronously terminates these processes. Drivers must not cause the system to hang or crash while running this test.
Run Time: 20 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM Process Callout

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-70 Display driver functions properly, and does not generate hangs or faults, under prolonged stress
Test Assertion GUID: 85ad15b6-d938-43d0-9142-094375997519

Windows Logo Program: GRAPHICS-0038 Display driver functions properly and does not generate hangs or faults under prolonged stress

Additional Information:


D3D Invalid Parameters

Type: Automated Test

Overview

The D3D Invalid Parameters test verifies that the system is stable and secure when invalid parameters are passed to the D3D APIs.

Details

The D3D Invalid Parameters test calls the Direct3D APIs with invalid parameters. Most of these invalid parameters are passed on to the display driver. Display drivers must do parameter validation on data generated by user-mode clients to ensure that the system does not crash or hang.
Run Time: 45 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running D3D Invalid Parameters

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-70 Display driver functions properly, and does not generate hangs or faults, under prolonged stress
Test Assertion GUID: 85ad15b6-d938-43d0-9142-094375997519

Windows Logo Program: GRAPHICS-0038 Display driver functions properly and does not generate hangs or faults under prolonged stress

Additional Information:


Blt - Raster Ops - Vid Mem

Type: Automated Test

Overview

Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.

Details

Test ensures that the DisplayDriver correctly performs all reported DirectDraw Blt Raster Operations. Only SRCCOPY is required.
Test Executable: Fnddraw.exe

Run Time: 00:00:25
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Display adapater with DDraw capabilities

Running Blt - Raster Ops - Vid Mem

No specific steps to follow for this test

Command Syntax

Command option | Description
fnddraw.exe dd_rop.pro -r -c -p"m%MONITOR%" | The %monitor% parameter needs to be replaced with a 1 based index that corresponds to the display under test.

Cautions

The screen saver should be turned off and the power management should be disabled before running this test. Mode changes, full screen apps can cause failures and should be avoided.

Reference Documentation

DirectX SDK (Version 7.0 or Later)

Code Tour

File Manifest

File | Location
fnddraw.exe | multimediatest\video\ddraw
fnswtt.dll | multimediatest\video\ddraw
dd_rop.pro | multimediatest\video\ddraw\pro

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


RateTest

Type: Automated Test

Overview

The test switches to all enumerated GDI display modes, all available low-resolution GDI low-resolution modes (< 640x480 pixels), and enumerated DirectDraw full-screen modes. The test then intersects these two sets of modes, and validates that the set of DirectX enumerated modes exist in the set of GDI enumerated modes. The test switches to these modes, and validates that the refresh rate actually produced by the card matches the refresh rate that the driver says is being output. Refresh rate is validated using IDirectDraw::GetVerticalBlankStatus. After each mode is set, the test puts up a DOS box, to ensure that virtualization of VGA hardware works correctly for each mode.

Details

Display Resolution, Color Depth, and Refresh Rate Test
This test verifies that the graphics adapter hardware supports 800 x 600 pixel resolution, 16 bits per pixel (bpp) color depth, 16-bit Z buffer, double frame buffering, and 75 Hz refresh rate in full-screen 3D graphics mode. Mobile computers are only required to support 640 x 480 pixel resolution.
The test first verifies these requirements in software by querying the DirectDraw capabilities, and then in hardware by selecting the specified settings and displaying a predefined scene as shown in the following steps:
  1. A DirectDraw object is created with the DirectDrawCreate function using the DDCREATE_HARDWAREONLY flag. This action forces a HAL device to be used, instead of a HEL device.
  2. Using the DirectDraw IDirectDraw4: EnumDisplayModes function, the following values in the DDSURFACEDESC2 structure are verified as valid choices:
dwWidth = 800 (dwWidth = 640 for mobile systems)

dwHeight = 600 (dwHeight = 480 for mobile systems)

dwRefreshRate = 75 (or 0 for drivers that do not report this value)
  3. The DDPIXELFORMAT structure verifies that the following are valid choices:
dwRGBBitCount = 16

dwZBufferBitDepth = 16
  4. The SetCooperativeLevel function selects the DDSCL_EXCLUSIVE and DDSCL_FULLSCREEN flags.
  5. SetDisplayMode is called to set the display to 800 x 600 x 16 and 75 Hz refresh rate. If the 75 Hz value fails, a refresh rate value of 0 (default) is used.
  6. CreateSurface is called for the primary surface, the back buffer, and the Z buffer.
  7. The Direct3D CreateDevice function is called using class identifier IID_IDirect3DHALDevice to allow access to the 3D graphics hardware device.
  8. All other 3D graphics tests specified in this chapter employ a double-buffered surface to verify compliance with the double frame buffering requirement.
A pass/fail indication of compliance with this requirement is displayed and logged by the test program. Failures may be generated by any of the device setup steps described in the overview section of this test. Any detected failure generates additional information that clearly identifies the non-compliant issue.

Run Time:
Log File: RateTest.wtl
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running RateTest

The SVGA-compatible display monitor attached to the system being tested must support the minimum display resolution and refresh rate specified above. Microsoft Windows 98 or Windows 2000 operating system or later must be installed, as well as DirectX version 6 or later.

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:

Windows Logo Program:

Additional Information:


Fast User Switching - DVDTest

Overview

Tests video drivers when software DVD playback is running, on one or more users, and fast-user-switching occurs.

Details

This test will create users on a system and start a DVD playback on one of the users. Without logging the user out, it will switch to another user via Fast User Switching and start DVD playback on that user as well. In a process of the test user switching will happen multiple times. Test failures indicate problems such as failure to switch the user or failure to start a DVD playback on a user. The purpose of the test is to make sure that video drivers do not bugcheck while user switching occurs.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running Fast User Switching - DVDTest

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WDDM PnPStop Test

Type: Automated Test

Overview

WDDM PnPStop Test - The test disables and enables the display adapter.

Details

WDDM PnPStop Test - The test disables the display adapter and then enables it. Setupapi is used for disabling/enabling the display device.
Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM PnPStop Test

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification

Additional Information:


WDDM Overlay

Type: Automated Test

Overview

The WDDM Overlay test is a basic test of overlay functionality.

Details

The WDDM Overlay test verifies that user-mode and kernel-mode display drivers correctly handle overlays. The test creates overlays (if supported) and performs rendering operations on surfaces display via overlays. Neither the user-mode nor kernel-mode driver may crash or hang during this test.
Run Time: 10 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM Overlay

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-69 Display adapter or chipset complies with the DirectX DDK specification
Test Assertion GUID: 7af8c5fb-d668-426c-a663-5c27038e8a01

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification

Additional Information:


WDDM BVT2

Type: Automated Test

Overview

This test validates the user-mode display drivers implement basic functionality required by the user-mode DDI.

Details

The WDDM BVT2 test is a minimal test application designed to verify basic functionality of a Vista Driver Model video driver. The primary goals of this test are to ensure system stability under the Longhorn driver model and to verify the functionality of Vista display drivers. The test is composed of a set of test groups. Each test group exercises one subset of the Vista user mode DDI. The WDDM BVT test does not use the Direct3D runtime. Instead, it calls directly into the user mode driver and the kernel mode thunks in the operating system. Drivers must not crash or leak memory while running this test.
Run Time: 30 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM BVT2

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-69 Display adapter or chipset complies with the DirectX DDK specification
Test Assertion GUID: 7af8c5fb-d668-426c-a663-5c27038e8a01

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification

Additional Information:


WDDM Primary Surface

Type: Automated Test

Overview

The WDDM Primary Surface test verifies that drivers correctly implement presentation operations.

Details

The WDDM Primary Surface test exercises the kernel-mode presentation DDI in a variety of ways. Drivers must succeed present calls and not crash or hang during this test. The following scenarios are executed:
  1. Present-blts to 8bpp, 16bpp, and 32bpp surfaces
  2. Color-fill presents to 8bpp, 16bpp, and 32bpp surfaces
  3. Presents to staging buffers
  4. Primary to primary present-blts
5. Present blts with large rectangle counts

Run Time: 60 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM Primary Surface

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-69 Display adapter or chipset complies with the DirectX DDK specification
Test Assertion GUID: 7af8c5fb-d668-426c-a663-5c27038e8a01

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification

Additional Information:


WDDM Coherency

Type: Automated Test

Overview

The WDDM Coherency test validates that GPU and CPU accesses to aperture segments are flushed correctly to ensure coherency of the data accesses between both processors.

Details

The WDDM coherency test invokes a test embedded in the Vista kernel. The test validates that accesses to aperture segments (AGP and PCI-express) are coherent, and correctly cause cache flushes. To pass this test, AGP chipset drivers and display drivers must correctly flush caches when instructed to by the operating system.
Run Time: 1 minute
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM Coherency

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-69 Display adapter or chipset complies with the DirectX DDK specification
Test Assertion GUID: 7af8c5fb-d668-426c-a663-5c27038e8a01

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification

Additional Information:


DXGI - GetAdapterIdentifier and Output Enumeration (32-bit)

Type: Automated Test

Overview

The test verifies correct implementation of IDXGIAdapter::GetAdapterIdentifier and IDXGIAdapter::EnumOutputs.

Details

The test simply compares the results generated by DXGI with those generated by corresponding D3D9 methods.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running DXGI - GetAdapterIdentifier and Output Enumeration (32-bit)

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Missing Resource Stability

Type: Automated Test

Overview

The graphic driver must ensure that all render targets, textures, and vertex buffers are flushed, and are also handled properly before they are released by the system.

Details

This test verifies that a driver can process resource handles correctly. In the test, the DrawPrimitive functions are called along with calls to manage resources (render targets, textures, vertex buffers). If the driver incorrectly processes the resource handles, the attempts to render the target result in missing or inappropriate resource pointers.

The test calls DrawPrimitive, releases the resource, (it is expected that the drivers flush the resource properly), and calls IDirect3DDevice9::Present. If the resource has been flushed properly, the primitives are present.

Run Time:
Log File: Missing.xml
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running Missing Resource Stability

Command Syntax

Command option | Description
-multisample | ‑multisampleThe test clears the multisample render target, and then creates, and releases the texture immediately (without loading the image).
-texture | ‑textureIDirect3DDevice9::Present method is called when the texture resource has been released.
-buffer | ‑bufferIDirect3DDevice9::Present method is called when the vertex buffer has been released.

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WDDM Sync

Type: Automated Test

Overview

The WDDM Sync test verifies that user-mode drivers properly synchronize the CPU and GPU when resources are used by the CPU and GPU.

Details

The WDDM Sync test verifies that user-mode display drivers expose correct locking semantics. In particular, there are 2 situations in which user mode drivers must flush command buffers to kernel mode before returning from a Lock() call.
1. When a resource is locked that is the target of a pending GPU write operations
2. When a resource is locked that is the source of a pending GPU read operations
The test creates video memory resources and instructions the user-mode driver to program the GPU to read from or write to these resources. The test then locks the resources and reads their contents with the CPU. The test verifies that the data read by the CPU indicates that the Lock DDI blocked until the GPU finished processing all commands that reference the resources.

Run Time: 20 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM Sync

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-69 Display adapter or chipset complies with the DirectX DDK specification
Test Assertion GUID: 7af8c5fb-d668-426c-a663-5c27038e8a01

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification

Additional Information:


Surface Flipping Tests

Type: Automated Test

Overview

Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.

Details

Test ensures that the DirectDraw graphics adapter supports surface flipping, flip status reporting, and vertical blank querying.
The follow Fnddraw cases make up this test
SURF_GetFlipStatus
API_GetVerticalBlankStatus
PC98_22 (PC97 20) Perform Double Buffer Swaps with no tearing
Test Executable: Fnddraw.exe

Run Time: 00:07:55
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Display adapater with DDraw capabilities

Running Surface Flipping Tests

No specific steps to follow for this test

Command Syntax

Command option | Description
fnddraw.exe dd_flip.pro -r -c -p"m%MONITOR%" | The %monitor% parameter needs to be replaced with a 1 based index that corresponds to the display under test.

Cautions

The screen saver should be turned off and the power management should be disabled before running this test. Mode changes, full screen apps can cause failures and should be avoided.

Reference Documentation

DirectX SDK (Version 7.0 or Later)

Code Tour

File Manifest

File | Location
fnddraw.exe | multimediatest\video\ddraw
fnswtt.dll | multimediatest\video\ddraw
dd_flip.pro | multimediatest\video\ddraw\pro

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


DDraw Blt - ColorFill - Video Memory

Type: Automated Test

Overview

Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.

Details

The purpose of these tests is to verify that color fill blt operations can be successfully performed on video memory surfaces.
The test performs a series of color fill directly onto the primary surface. Fill regions (RECTs) are chosen such that a variety of sizes and memory alignments are tested. The results of the color fills are compared against a reference image generated using GDI.
Display Drivers are required to support hardware accelerated color fills. Support is indicated by setting the DDCAPS_BLTCOLORFILL flag.
Test Executable: Fnddraw.exe
Fnddraw Test Case: BLT Color Fill Primary

Run Time: 00:02:50
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Display adapater with DDraw capabilities

Running DDraw Blt - ColorFill - Video Memory

No specific steps to follow for this test

Command Syntax

Command option | Description
fnddraw.exe dd_vcf.pro -r -c -p"m%MONITOR%" | The %monitor% parameter needs to be replaced with a 1 based index that corresponds to the display under test.

Cautions

The screen saver should be turned off and the power management should be disabled before running this test. Mode changes, full screen apps can cause failures and should be avoided.

Reference Documentation

DirectX SDK (Version 7.0 or Later)

Code Tour

File Manifest

File | Location
fnddraw.exe | multimediatest\video\ddraw
fnswtt.dll | multimediatest\video\ddraw
dd_vcf.pro | multimediatest\video\ddraw\pro

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


DXGI - Frame Statistics

Overview

Verifies support for DXGI's Frame Statistics

Details

Verifies the DXGI_FRAME_STATISTICS buffer for calls to DXGISwapChain::GetFrameStatistics and DXGIOutput::GetframeStatistics. PresentCounts should be updated per DXGISwapChain::Present.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running DXGI - Frame Statistics

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Visual GPU

Overview

Visual GPU is a visualization tool. Visual GPU allows its users to visualize the internal workings of the Microsoft Windows Vista graphics kernel and LDDM display drivers. This tool is useful in understanding and debugging performance problems related to LDDM display drivers.

Details

There are two steps involved in using Visual GPU. They are:
  1. Recording a scenario
  2. Visualizing that scenario
Recording
In the first step, Visual GPU records a sequence of events that occur during the scenario that the user is interested in. To instruct Visual GPU to record a scenario, the user should enter the following command in a command prompt:
VisualGPU.exe record <log file name> <seconds to record>
where <log file name> is the name of the log file that will be created and <seconds to record> is the number of seconds that events will be recorded for. For example: to save 10 seconds worth of data to logfile.log, enter this command:
VisualGPU.exe record logfile.log 10
Visual GPU will overwrite previously existing log files with duplicate file names, it will not append events into existing log files.
Be careful not to set the record time to a high value. Each second of recording generates about 1MB of data in the log file.
After starting Visual GPU in record mode, the user should run the graphics scenario they are interested in. This usually means running a Direct3D application.
Visual GPU can be run in record mode only on a system with an LDDM display driver.
Visualization
In the second step, Visual GPU displays the contents of a log file onto the screen as an animation. To instruct Visual GPU to playback the contents of a log file, enter the following command in a command prompt:
VisualGPU.exe play <log file name>
where <log file name> is the name of the log file that was previously recorded.
This will cause Visual GPU to display a window with an animation representing the contents of the log file.
Visual GPU can be run in playback mode on Windows XP and later versions of the operating system. An LDDM display driver is not required to run Visual GPU in playback mode.
Controls
In playback mode, the user can control the animation speed and the location in time that is being displayed through the window labeled "VCR". This window has five controls.
  • Slider
  • Up button
  • Down button
  • Play button
  • Pause button
The Slider controls the location in time that is currently being displayed. The leftmost position represents the beginning of the animation. The rightmost position represents the end of the animation. Dragging the slider with the mouse will cause the animation to fast-forward or rewind accordingly. Additionally, the user can click the slider and then use the right and left arrow keys on the keyboard for fine-grained control of the animation time.
The Up and Down buttons control the rate at which the animation is displayed. Clicking the Up button causes the animation to be displayed faster. Clicking the Down button causes the animation to be displayed slower.
The Play button causes the animation to proceed forward in time. The Pause button causes the animation to stop advancing and continuously display the same location in time.
Animation Elements
The playback window displays an animation representing a sequence of events contained in a log file. To properly understand these elements, the user must understand the Windows Vista Display Driver Model. Please review the Windows Vista Display Driver Model documentation for an overview of the model. The elements of the animation are:
  • GPU statistics (in the upper-left)
  • Per-device queues (to the right of the GPU statistics)
  • Hardware Queue (beneath the GPU statistics)
  • Memory segments (to the right of the per-device queues)
  • Monitors (The rightmost elements on the screen)
The GPU statistics element contains the following data that is periodically updated:
  • GPU busy %: The percentage of the time that the hardware queue is not empty. 100% means the hardware queue is never empty.
  • Frames per second: The number of present commands completed by the GPU per second.
  • DMA buffers per second: The number of DMA buffers completed by the GPU per second.
  • Context switches per second: The number of times the GPU scheduler decides to switch device contexts per second.
  • Average quantum used: The average number of milliseconds that a device context operates on the GPU before a context switch occurs.
  • Sys->Vid mem per second: The number of kilobytes of data transferred from system memory to local video memory per second.
  • Vid->Sys mem per second: The number of kilobytes of data transferred from local video memory to system memory per second.
  • AGP->Vid mem per second: The number of kilobytes of data transferred from non-local video memory to local video memory per second.
  • Vid->AGP mem per second: The number of kilobytes of data transferred from local video memory to non-local video memory per second.
  • Vid mem filled per second: The number of kilobytes of local video memory that the GPU is asked to zero-fill per second.
The per-device queues element contains a number of device queues. Each device queue has a set of statistics and a queue of DMA buffers. DMA buffers are represented by rectangles. White rectangles represent normal DMA buffers. Yellow rectangles represent DMA buffers that contain present operations. Green rectangles represent paging buffers. Typically, each Direct3D application contains one per-device queue. The statistics displayed about each queue are:
  • Application name: The name of the application that owns the per-device queue.
  • FPS: The number of present operations that are completed by the device context per second.
  • Frame time (msec): The average number of milliseconds in-between the time that the GPU completes two present operations.
  • Frame time std dev: The standard deviation of the time in-between present operations (measured in milliseconds). Lower values indicate smoother animations.
  • GPU Time %: The percentage of time that the GPU spends processing commands from the device queue.
  • Locks/Frame: The number of times per frame that the application locks an allocation.
DMA buffers in the device queue are ordered from bottom to top. When an application submits a DMA buffer into the queue, the buffer appears in the top of the queue. When a DMA buffer is moved to the hardware queue, it is taken from the bottom of the device queue. Applications with many DMA buffers in their per-device queue are typically GPU-bound. While applications that usually have empty per-device queues are typically CPU-bound.
The hardware queue element contains a single queue of DMA buffers that is ordered from left to right. The leftmost element is the DMA buffer that was most recently submitted to the hardware queue. The rightmost element is the DMA buffer that the GPU is currently processing. To the left of the hardware queue is a text field that says either "Preempting: true" or "Preempting: false." "Preempting: true" is displayed when the display driver is told to preempt all commands in the hardware queue. This will cause some of the commands in the hardware queue to be moved back to the bottom of their respective per-device queues. "Preempting: false" is displayed when the display driver is not being asked to preempt any outstanding DMA buffers.
Each memory segment enumerated by the display driver is represented by a hollow red rectangle. The rectangle represents all of the memory contained in that segment. Byte 0 is at the top left of the segment, while the last byte is at the bottom right of the segment. A segment contains zero or more allocations. An allocation is represented by a blue region with a green border. The location of the allocation within the segment corresponds to the physical address of the segment. This means that allocations with a higher physical address will appear lower in the segment. Allocations that are currently "paged out" (not resident in local or non-local video memory) are not displayed.
On the rightmost edge of the screen, there is one solid white box for each monitor connected to the display adapter. Each monitor contains the following information:
  • Target ID: The VidPn target ID. This number represents the output head on the display adapter that the monitor is connected to. See the Windows Vista Display Driver Model documentation for more information on VidPn targets.
  • Frame Number: A number that is incremented each time a v-sync occurs on the monitor.
  • Primary Surface Segment: The segment ID of the primary surface that is currently being displayed on the monitor.
  • Primary Surface Address: The physical address of the primary surface that is currently being displayed on the monitor.
More detailed information can be obtained about some elements by left clicking them with the mouse. See the Windows Vista Display Driver Model documentation for a description of the displayed information. The detailed information that can be obtained is:
DMA Buffers - Left clicking a DMA buffer displays:
  • The name of the process that created the DMA buffer
  • The amount of time that the GPU spent processing the DMA Buffer
  • The amount of time that the DMA buffer spent in a per-device queue
  • The amount of time that the DMA buffer spent in the entire system (per-device queue + hardware queue)
  • The amount of time that the system spent preparing the DMA buffer (paging in all required allocations)
  • The number of preparation passes that are required to prepare the DMA buffer
Segments - Left clicking on a memory segment displays:
  • The size of the segment (in bytes)
  • The number of banks in the segment
  • Segment flags (zero or more of: Aperture, AGP, CPU Visible, Banking, and Cache Coherent)
Allocations - Left clicking on an allocation displays:
  • The name of the processes that have opened views of the allocation
  • Whether or not the allocation is pinned
  • The size of the allocation (in bytes)
  • The offset (address) of the allocation within the segment (in bytes)
  • Allocation flags (zero ore more of: CPU Visible, Permanent system memory, Cached, Protected, Existing system memory, Existing kernel memory, Allocated from end of segment, Swizzled, Overlay, Shareable, Primary, Managed Primary)
  • Alignment (in bytes)
  • The IDs of the segments that the allocation can be read from
  • The IDs of the segments that the allocation can be written to
  • The ID of the preferred segment for the allocation
  • The ID of the preferred bank for the allocation

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running Visual GPU

Command Syntax

Command option | Description
VisualGPU.exe record <log file name> <seconds to record> |
VisualGPU.exe play <log file name> |

Code Tour

File Manifest

File | Location
VisualGPU.exe |

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WDDM LockSmith

Type: Automated Test

Overview

The WDDM LockSmith test is a basic test of user-mode display driver locking functionality.

Details

The WDDM LockSmith test verifies that user-mode display drivers correctly implement the Lock DDI. In particular, this test locks multiple surfaces with a resource simultaneously and locks surfaces with discard semantics. Display drivers must not crash, hang, or fail calls to the Lock DDI during this test.
Run Time: 5 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM LockSmith

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-69 Display adapter or chipset complies with the DirectX DDK specification
Test Assertion GUID: 7af8c5fb-d668-426c-a663-5c27038e8a01

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification

Additional Information:


DDraw Blt - ColorFill - AGP

Type: Automated Test

Overview

Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.

Details

The purpose of these tests is to verify that color fill blt operations can be successfully performed on AGP (non-local video) memory surfaces.
The test performs a series of color fill operations on an AGP surface whose pixel format matches the current display mode. Fill regions (RECTs) are chosen such that a variety of sizes and memory alignments are tested. The results of the color fills are compared against a reference image generated using GDI.
Drivers are not required to support color fill operations on AGP surfaces. DirectDraw is capable of performing these operations in it’s emulation layer. Flags passed to DirectDraw indicate whether or not a display driver supports color fill operations on AGP surfaces. If the driver sets flags indicating support, it must match the reference image exactly.
The DirectX8 Driver Development Kit (DDK) documents which flags a driver sets to indicate support for AGP color fills.
Test Executable: Fnddraw.exe
Fnddraw Test Case: BLT Color Fill AGP Mem

Run Time: 00:01:50
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Display adapater with DDraw capabilities

Running DDraw Blt - ColorFill - AGP

No specific steps to follow for this test

Command Syntax

Command option | Description
fnddraw.exe dd_acf.pro -r -c -p"m%MONITOR%" | The %monitor% parameter needs to be replaced with a 1 based index that corresponds to the display under test.

Cautions

The screen saver should be turned off and the power management should be disabled before running this test. Mode changes, full screen apps can cause failures and should be avoided.

Reference Documentation

DirectX SDK (Version 7.0 or Later)

Code Tour

File Manifest

File | Location
fnddraw.exe | multimediatest\video\ddraw
fnswtt.dll | multimediatest\video\ddraw
dd_acf.pro | multimediatest\video\ddraw\pro

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Update Texture (32-bit)

Type: Automated Test

Overview

Test verifies device capacities to load textures (mipmap, cubemap) from system memory to video memory using UpdateTexture function. The test includes the following scenarios: (1) Load the entire texture. (2) Load a portion of the texture. (3) source and destination texture are square or non square. (4) Source and destination texture have different levels.

Details

This test verifies device capacities to load textures (mipmap, cubemap) using UpdateTexture function. It first creates a source texture in the system memory and destination texture in the video memory (source and destination texture could be square or non-square, could have different levels) and populate them with data. Second, it does some preparation on the source texture: it makes the entire texture dirty, and it makes a portion of the texture dirty. Finally it calls UpdateTexture to load the texture and checks the destination texture to make sure it is loaded correctly.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Windows 2000
  • Windows 9x
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running Update Texture (32-bit)

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Texture Update test.
Test Assertion GUID: 5.65.1


Present Validation 2 (FullScreen)

Type: Automated Test

Overview

This test verifies that all modes reported by the EnumAdapterModes method for the device are available to applications. The following parameters are considered: the back buffer format, screen resolution, present intervals, swap effects, and multisample types.
The DoNotWait test calls the swap chain's Present method in a loop, passes the D3DPRESENT_DONOTWAIT flag, in full-screen mode, and uses the D3DPRESENT_INTERVAL_ONE value. As a result, the driver’s queue of frames will exceed 3 (maximum allowed). The DoNotWait test expects the driver to return control to the application using the D3DERR_WASSTILLDRAWING error code. If the error code is not returned, the test fails.
The LockDoNotWait test is similar to the DoNotWait test, but this test is performed on a surface (the back buffer). The same behavior is expected of the driver. If the error code is not returned, the test fails.

Details

FullScreenPresent:
The test displays on-screen pass or fail compliance and writes the results to a log file called Present2.xml. Present2.xml is written to the %windir%\dxlogs directory.
If the call to the Reset method fails, you can check the values the test used for the back buffer format / size in the log file. If the image comparison fails, the test prints the image comparison statistics, similar to the other Present Validation tests in the group.
The image surfaces used in the test are listed in the following table. If you specify the -Save command option, the test saves these files.
Surface | Description
texture.dds | Texture used to fill the quad used in present operations.
SourceSurface.bmp | Source surface in the back buffer. For full-screen present operations, this is the whole buffer.
DestSurface.bmp | Destination surface in the front buffer. For full-screen present operations, this is the whole buffer.
refSurface.bmp | The reference surface, as computed by the Microsoft® Direct3D® application programming interface.
DiffSurface.bmp | The difference between the front buffer and the reference image.
frontBuffer.bmp | The contents of the front buffer.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running Present Validation 2 (FullScreen)

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

5.305.1 Drivers must succeed Reset for all the modes reported through EnumAdapterModes.
Test Assertion GUID:

5.305.2 Drivers should succeed the Present calls for all the modes reported through EnumAdapterModes.
Test Assertion GUID:

5.306.2 The driver is not allowed to queue more than 3 frames, and it should return control to the application if the D3DPRESENT_DONOTWAIT flag is specified.
Test Assertion GUID:

5.306.3 The driver should return control to the application if the D3DLOCK_DONOTWAIT flag is specified and the operation cannot be performed immediately.
Test Assertion GUID:


Conformance ECP [1]

Overview

Test analyzes pixel-by-pixel verification. The concept of an equivalent computational path, ECP, is introduced to test the same functionalities.

Details

The GL Coverage and Utilities Coverage tests are designed to test all API functions within the OpenGL 1.1 library. Specified valid and invalid parameters are passed to these functions to ensure they are handled properly.
The Conformance ECP [x] tests check the functionality of various OpenGL operations to ensure the driver's implementation is valid. This includes viewport clamping and transformations, matrix stacks, vertex orders, transforms, buffer operations, color ramping, masking, selection, feedback, clipping, alpha and stencil planes, dithering, logical operations, pixel operations, rasterizations, polygon operations, lighting, fog, texture mapping, mipmapping, display lists, and evaluator vertex testing.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Windows 2000
  • Windows 9x
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running Conformance ECP [1]

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Vista Fonts

Type: Automated Test

Overview

The test verifies the functionality of the ComposeRects API. The drivers should set the D3DPTFILTERCAPS_CONVOLUTIONMONO if they support this feature.

Details

The test verifies the functionality of the ComposeRects API.
2 VB created with the D3DUSAGE_TEXTAPI flag store D3DCOMPOSERECTDESC & D3DCOMPOSERECTDESTINATION arrays.
Font textures are created with D3DFMT_A1 format.
The font texture is alpha blended on top of an existing background.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running Vista Fonts

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WDDM Max Contexts

Type: Automated Test

Overview

The WDDM Max Contexts test verifies that drivers do not have any hardware limits on the number of rendering contexts can that exist at any given time.

Details

The WDDM Max Contexts test creates 100 user-mode device contexts at the same time. Drivers fail the test if they fail any of the device creation attempts. The number of outstanding device contexts that exist must be limited by available system memory only.
Run Time: 2 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM Max Contexts

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-69 Display adapter or chipset complies with the DirectX DDK specification
Test Assertion GUID: 7af8c5fb-d668-426c-a663-5c27038e8a01

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification

Additional Information:


BLT Unused Pixel Bits

Type: Automated Test

Overview

Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.

Details

This test verifies that the display driver ignores unused portions of a pixel when performing a color key blt operation. Unused portions of a pixel (such as the high byte in 32bpp modes) should not be included in the color key comparison.
Test Executable: Fnddraw.exe
Fnddraw Test Case: BLT, SRCKEY (from VMem) with unused pixel bits set

Run Time: 00:03:15
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Display adapater with DDraw capabilities

Running BLT Unused Pixel Bits

No specific steps to follow for this test

Command Syntax

Command option | Description
fnddraw.exe dd_bupbs.pro -r -c -p"m%MONITOR%" | The %monitor% parameter needs to be replaced with a 1 based index that corresponds to the display under test.

Cautions

The screen saver should be turned off and the power management should be disabled before running this test. Mode changes, full screen apps can cause failures and should be avoided.

Reference Documentation

DirectX SDK (Version 7.0 or Later)

Code Tour

File Manifest

File | Location
fnddraw.exe | multimediatest\video\ddraw
fnswtt.dll | multimediatest\video\ddraw
dd_bupbs.pro | multimediatest\video\ddraw\pro

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WDDM Blt - Stretch

Type: Automated Test

Overview

The WDDM Blt - Stretch test verifies that user-mode display drivers correctly implement stretching blt operations.

Details

The WDDM Blt - Stretch test creates 2 surfaces and uses the user-mode blt DDI to transfer data between them. The test asks drivers to do stretching blts between the two surfaces. The source surface make exist in system memory while the destination exists in video memory. User-mode drivers must not crash or fail the blt DDI call during this test.
Run Time: 10 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM Blt - Stretch

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-69 Display adapter or chipset complies with the DirectX DDK specification
Test Assertion GUID: 7af8c5fb-d668-426c-a663-5c27038e8a01

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification

Additional Information:


WGF Input Assembler

Type: Automated Test

Overview

Verifies graphics drivers/hardware D3D input assembler behavior meets Microsoft D3D specifications.

Details

Input Assembler Conformance Test

Basic cases with buffers

This is to validate simple cases that should work
  • Make sure that indices are respected for IB
  • Make sure that buffer bound as a view works
  • Make sure that VB works
  • Make sure that Constant Buffers works
  • Cycle through all valid buffer usages and some sizes
  • Try huge buffers
  • Bind max number of buffers, with each buffer of a different usage/pool/cpuaccess
  • Overflow
    • Indices > number of vertices
    • 2 vb: one too small, only small should overflow

Read From Unbound Buffer Slot

  • Read from a buffer when not set (VB, IB, Views, Constant) should return default value

Input Layouts

    • InputSlotClass
      • Layouts with varying slot class (they should also cycle offsets and inputSlot), like
      • vertex, instance, vertex, vertex
      • instance, vertex, vertex, instance
      • max number of elements varying
      • etc.
    • InputSlot
      • Layouts with :
      • Out of order slots
      • Skipped slots
      • Not using slot 0
    • InstanceDataStepRate
      • Make sure they are respected
    • Alignments
      • Make sure they are respected
    • Number of elements in input layout :
      • smaller than number of elements in shader
        • HW needs to set default value
      • bigger than number of elements in shader
        • expect same behavior as equal numbers
      • Maximum number of elements
    • No Input Layouts (only Generated IDs)
    • Same Offset with different format stride

Generated Values

  • Generated values should reset for each draw
  • Make sure that all VS Generated values are generated correctly
    • No buffer bound, id’s should be generated correctly
    • When only IB is used, VertexID should be the IB Values
    • Also try IB smaller than number of vertices to draw

Buffers bound to many inputs

  • VB - Same buffer bound in different slots
  • Buffer bound as VB and IB and View to a VS
    • with and without same offsets, stride, etc.

Undefined Behaviors

These are lower priorities, I add them whenever I think of a case and should be tested just to make sure the driver doesn’t crash.
  • Invalid format for IB
  • InstanceDataStepRate should be ignored for vertex data
  • Use InputSlot > maxInputSlot
  • Unaligned data (AlignedByteOffset) with format size
  • bind buffers without correct usage and Draw (for example ConstantBuffer bound as IB)
  • vertex and instance data in same stream
  • typeless formats in input layout

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WGF Input Assembler

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Windows SideShow Enhanced Device Test

Type: Automated Test

Overview

This test verifies that a device uses the inbox Windows SideShow diver. This is for Windows SideShow devices that use a USB connection and run the TinyCLR.

Details

This test ensures that a Windows SideShow device that uses USB and the TinyCLR firmware uses the appropriate driver. This allows the user to receive a rich experience on the device and in the Windows SideShow control panel.
To run the Windows SideShow enhanced device logo test:
1. Start DTM studio.

2. Click the Explorers then click Device Console. (see attached sideshow.jpg)

3. From the Machine Pool list, select the machine pool that contains the computer on which you want to run test.

4. In the View by option box, select Device.

5. In the Available devices pane, expand SideShow, then select the specific device to run the test. The name of the computer is show after the device name.
6. In the Available Jobs pane, select “WDKLogoTestEnhancedDriver” test job

7. Click Add Selected.

8. When you are ready to run the jobs, select “Load”

9. Use the Job Monitor to track the progress of jobs as they are executed

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running Windows SideShow Enhanced Device Test

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


CreateSurface

Type: Automated Test

Overview

Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.

Details

This test validates that display drivers gracefully handle CreateSurface calls for all pixel formats supported by the DirectDraw hardware emulation layer (HEL). Drivers are not required to support the entire pixel format list. Drivers can choose to fail any format they do not want to support. The primary purpose of this test is to ensure that drivers can respond correctly to unsupported formats. The suggested return code is DDERR_UNSUPPORTEDFORMAT, but drivers are free to return whatever error code is most appropriate.
The pixel format list consists of the following formats:
Offscreen plain surfaces:
Pal 1-bit
Pal 2-bit
Pal 4-bit
Pal 8-bit
RGB 16-bit 5:6:5
RGB 16-bit 5:5:5
ARGB 16-bit 1:5:5:5 Premult
ARGB 16-bit 1:5:5:5
RGB 24-bit 8:8:8
BGR 24-bit 8:8:8
RGB 32-bit 8:8:8
BGR 32-bit 8:8:8
ARGB 32-bit 8:8:8:8
ABGR 32-bit 8:8:8:8
ARGB 32-bit 8:8:8:8 Premult
ABGR 32-bit 8:8:8:8 Premult
565+16 RGBZ
555+16 RGBZ
ARGB16-bit 4:4:4:4 Premult
ARGB16-bit 4:4:4:4
Texture surfaces:
Pal 1-bit
Pal 1-bit - Indexed8
Pal 2-bit
Pal 2-bit - Indexed8
Pal 4-bit
Pal 4-bit - Indexed8
Pal 8-bit
RGB 8-bit 3:3:2
ARGB16-bit 4:4:4:4
RGB 16-bit 5:6:5
BGR 16-bit 5:6:5
RGB 16-bit 5:5:5
ARGB 16-bit 1:5:5:5
RGB 24-bit 8:8:8
BGR 24-bit 8:8:8
RGB 32-bit 8:8:8
BGR 32-bit 8:8:8
ARGB 32-bit 8:8:8:8
ABGR 32-bit 8:8:8:8
Luminance 8-bit
Alpha Luminance 8-bit
U8V8 bumpmap
U5V5L6 bumpmap
U8V8L8 bumpmap
16 bit Z buffer
32 depth/stencil 8S:24Z
32 depth/stencil 24Z:8S
16 depth/stencil 15z:1s
16 depth/stencil 1s:15z
32 bit Z buffer
DXT1
DXT2
DXT3
DXT4
DXT5
Alpha 8
A4I4 luminance
ARGB 16-bit 8:3:3:2
A8P8
UYVY
YUY2
RGB 16-bit 4:4:4
X8L8V8U8 Bump Luminance

Note Note that this list does not represent all possible formats. Display drivers should be written in a way to gracefully reject all unsupported formats.

The test cycles through all supported bit-depths (8, 16, 24, and 32-bpp) at 640x480 resolution.
Test Executable: Fnddraw.exe dd_surf.pro

Run Time: 00:00:10
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Display adapater with DDraw capabilities

Running CreateSurface

No specific steps to follow for this test

Command Syntax

Command option | Description
fnddraw.exe dd_surf.pro -r -c -p"m%MONITOR%" | The %monitor% parameter needs to be replaced with a 1 based index that corresponds to the display under test.

Cautions

The screen saver should be turned off and the power management should be disabled before running this test. Mode changes, full screen apps can cause failures and should be avoided.

Reference Documentation

DirectX SDK (Version 7.0 or Later)

Code Tour

File Manifest

File | Location
fnddraw.exe | multimediatest\video\ddraw
fnswtt.dll | multimediatest\video\ddraw
dd_surf.pro | multimediatest\video\ddraw\pro

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Alpha Blended Cursor (Manual)

Overview

The test tool displays an icon on the window and allows the tester to decide if the icon has been drawn correctly or not

Details

The test tool creates a window and loads a cursor from a resource file. This cursor is then painted on the window using AlphaBlend. The window then waits for the tester to look at the drawn cursor.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Windows 2000
  • Windows 9x
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running Alpha Blended Cursor (Manual)

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WDDM Scheduler Stress (Always Repatch)

Type: Automated Test

Overview

The WDDM Scheduler Stress (Always Repatch) test verifies system stability while running many GPU-bound memory intensive applications when all patch locations are always repatched via the Patch DDI.

Details

The WDDM Scheduler Stress (Always Repatch) test creates many processes that do D3D9 rendering with a large video memory working set. This causes preemption and paging to occur on the GPU. The test puts the operating system into a mode that causes it to repatch all patch locations via the Patch DDI. Display drivers must not cause the system to crash or hang while running this test.
Run Time: 30 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM Scheduler Stress (Always Repatch)

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-70 Display driver functions properly, and does not generate hangs or faults, under prolonged stress
Test Assertion GUID: 85ad15b6-d938-43d0-9142-094375997519

Windows Logo Program: GRAPHICS-0038 Display driver functions properly and does not generate hangs or faults under prolonged stress

Additional Information:


WGF Stream Out

Type: Automated Test

Overview

Verifies graphics drivers/hardware D3D stream out behavior meets Microsoft D3D specifications.

Details

StreamOut Conformance Test Plan Outline
General Stream Out Test Cases
  • Pass input data into pipeline via VB and stream out transformed data from either VS or GS.
    • In the GS case consider amplification issues by emitting more than one output primitive per input primitive.
  • Cycle on different primitive types, buffer sizes, emit counts, buffer offsets.
  • Test appending SO data by making multiple Draw() calls.
  • For GS, cycle on shaders with different "maxvertexcount" properties.
    • Occasionally overflow this value. Making sure that only complete primitives are kept.
  • Possibly cycle on different input primitive types and output topologies.
  • Verify expected query results.
    • STREAMOUTPUTSTATS
    • STREAMOVERFLOWPREDICATE
  • Test incomplete primitive writes.
  • Test winding order and leading-vertex handling.
  • Up to 227 SO vertices per SO buffer allowed.
    • Probably only one or two test cases since this is an obscenely large resource.
Simple Single-Buffer Tests
  • Cycle on several declaration scenarios.
    • Simple.
    • Leave gaps.
    • Split output registers across multiple SO elements.
    • Merge output register into single SO element.
  • Cycle on different SO vertex sizes.
    • Verify limit of 64-component SO vertices.
Simple Multi-Buffer Tests
  • Mixup buffer sizes/offsets so that buffers will overflow at different times.
  • Cycle on several declaration scenarios.
    • Simple.
    • Skip output slot.
    • Split output registers across multiple SO elements.
    • Stream out partial register components.
    • Stream out to single buffer in non-zero slot.
Ping Ponging of Stream Output Buffers
  • Similar to simple single-buffer and simple multi-buffer tests with a twist.
    • Initially bind buffers A and B with a positive offset.
    • Bind buffer A using -1 offset value.
    • Draw()
    • Bind buffer B using -1 offset value.
    • Draw()
    • Repeat as needed.
  • In multiple buffer scenarios consider optionally ping-ponging only some of the SO buffers between Draw() calls.
Changing SO Vertex Size Using Same Target Buffer
  • Custom test case which focuses on setting "fat" vertex strides to a single buffer, then Draw(), then set "skinny" SO vertex stride, then Draw() again.
  • Examine STREAMOUTPUTSTATS.
  • Watch for overflow during "fat" vertex streaming and make sure that skinny vertices cannot be appended to target.
    • Consider ping-ponging when doing this to make sure that the overflowed state is "sticky" on the buffer.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running WGF Stream Out

No specific steps to follow for this test.

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WDDM Bit Flip - Invalid Param

Type: Automated Test

Overview

Bit Flip - Invalid Param is an invalid parameter stability test that verifies that kernel-mode display drivers correctly validate command buffers and private driver data passed from user-mode.

Details

Bit Flip - Invalid Param is a kernel mode video driver stability test. It runs in the layer between the user-mode display driver and the kernel mode display driver. The test intercepts calls from user mode to kernel mode. It then modifies the data associated with these calls. Kernel mode display drivers must be robust enough to handle invalid parameters coming from any user mode module without crashing or hanging.
Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM Bit Flip - Invalid Param

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-70 Display driver functions properly, and does not generate hangs or faults, under prolonged stress
Test Assertion GUID: 85ad15b6-d938-43d0-9142-094375997519

Windows Logo Program: GRAPHICS-0038 Display driver functions properly and does not generate hangs or faults under prolonged stress

Additional Information:


Display Power Test (32-bit)

Type: Automated Test

Overview

Display Power Test verifies that display device still maintain refresh rate at all supported low-power states.

Details

APMDISP uses the undocumented WM_MONITORPOWER message to initiate User.exe's power management state setting code. This is the same code that is executed when a suspend/resume cycle is initiated. This, in effect, causes the main VDD to set the display card into D0, D2, or D3. On a transition from any sleep state greater than D0 to D0, the test polls the refresh rate using an IDirectDraw, IDirectDraw4, or IDirectDraw7 interface coupled with GetMonitorFrequency(failing on NT only), GetVerticalBlackStatus, and WaitForVerticalBlanck(). The test then compares its results against each other against a tolerance of 1Hz.

Run Time:
Log File: apmdisp
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running Display Power Test (32-bit)

Windows XP operating system must be installed, as well as DirectX version 8 or later

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WDDM Four Character Code Surface Stability Test

Type: Automated Test

Overview

The Four Character Code Surface Stability Test verifies that the system is stable when IHV-specific 4CC surfaces are created and used.

Details

The Four Character Code Surface Stability Test enumerates all IHV-specific 4CC surface formats supported by the display driver. The test then creates surfaces with these IHV-specific formats and uses them. Drivers must not cause the system to crash or hang while running this test.
Run Time: 1 hour
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM Four Character Code Surface Stability Test

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-70 Display driver functions properly, and does not generate hangs or faults, under prolonged stress
Test Assertion GUID: 85ad15b6-d938-43d0-9142-094375997519

Windows Logo Program: GRAPHICS-0038 Display driver functions properly and does not generate hangs or faults under prolonged stress

Additional Information:


WDDM Blt - DepthFill

Type: Automated Test

Overview

WDDM Blt - DepthFill validates that drivers correctly implement the DepthFill DDI.

Details

WDDM Blt - DepthFill validates that drivers correctly implement the DepthFill DDI. In particular, it creates video memory depth-stencil surfaces and asks the user-mode driver to fill them with a value. Drivers must not crash or hang while running this test. Additionally, drivers must not fail the DepthFill DDI call.
Run Time: 10 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM Blt - DepthFill

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-69 Display adapter or chipset complies with the DirectX DDK specification
Test Assertion GUID: 7af8c5fb-d668-426c-a663-5c27038e8a01

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification

Additional Information:


PC99 #12 downloadable RAMDAC

Type: Automated Test

Overview

Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.

Details

This test verifies that the display adapter supports DirectDraw’s gamma ramp API. Test maps blue and green components to zero leaving only red.
For details on implementing Gamma Support, see the “Gamma Control” chapter of the DirectX8.0 Driver Development Kit (DDK) documentation.
Test Executable: Fnddraw.exe

Run Time: 00:12:12
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Display adapater with DDraw capabilities

Running PC99 #12 downloadable RAMDAC

No specific steps to follow for this test

Command Syntax

Command option | Description
fnddraw.exe dd_GAMMA.pro -r -c -p"m%MONITOR%" | The %monitor% parameter needs to be replaced with a 1 based index that corresponds to the display under test.

Cautions

The screen saver should be turned off and the power management should be disabled before running this test. Mode changes, full screen apps can cause failures and should be avoided.

Reference Documentation

DirectX SDK (Version 7.0 or Later)

Code Tour

File Manifest

File | Location
fnddraw.exe | multimediatest\video\ddraw
fnswtt.dll | multimediatest\video\ddraw
dd_GAMMA.pro | multimediatest\video\ddraw\pro

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WDDM Handles - Invalid Param

Type: Automated Test

Overview

The WDDM Handles - Invalid Param test verifies that kernel-mode drivers are stable when asked to process invalid handles.

Details

WDDM Handles - Invalid Param test verifies the stability of kernel-mode drivers when user mode-drivers are passed invalid resource handles, and resource handles of the incorrect type. The test intercepts handles returned from the OS kernel to the user-mode driver. It then modifies the handles returned to the user-mode driver. User-mode drivers may then generate invalid commands and handle lists which are passed to the kernel-mode driver. Kernel-mode drivers must not crash or hang during this test.
Run Time: 20 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM Handles - Invalid Param

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-70 Display driver functions properly, and does not generate hangs or faults, under prolonged stress
Test Assertion GUID: 85ad15b6-d938-43d0-9142-094375997519

Windows Logo Program: GRAPHICS-0038 Display driver functions properly and does not generate hangs or faults under prolonged stress

Additional Information:


WDDM Deadlock

Type: Automated Test

Overview

The WDDM deadlock test verifies that user-mode and kernel-mode drivers correctly synchronize calls from multiple processes and threads.

Details

The WDDM deadlock test calls into the user-mode and kernel-mode display drivers concurrently from multiple processes and threads. Display drivers must correctly synchronize access to shared data structures to ensure that the system is stable in this scenario. Drivers pass this test if they do not cause the system to crash or hang while the test is running.
Run Time: 2 hours
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM Deadlock

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-70 Display driver functions properly, and does not generate hangs or faults, under prolonged stress
Test Assertion GUID: 85ad15b6-d938-43d0-9142-094375997519

Windows Logo Program: GRAPHICS-0038 Display driver functions properly and does not generate hangs or faults under prolonged stress

Additional Information:


GL Utilities Coverage Tests

Overview

The GL Utilities Coverage test ensures that OpenGL implementation covers all the GL Utility APIs.

Details

The GL Utilities Coverage tests are designed to test all API functions within the OpenGL 1.1 library. Specified valid and invalid parameters are passed to these functions to ensure they are handled properly.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Windows 2000
  • Windows 9x
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running GL Utilities Coverage Tests

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


TVOut Test

Type: Automated Test

Overview

TVOut Test is a quality assurance application for display card secondary output ports (generically referred to as TV Output ports).

Details

Currently, the output of video content to VGA monitors and TVs (analog, component etc) does not produce a consumer level quality experience. Color quality and image semantics problems exist both in the content sourcing devices and with display devices. Significant changes are required to maintain the integrity of the signal through the entire pipeline and to provide user level adjustments to correct for issues on the output displays.
The new LDDM display model has an internal kernel mode component called the DMM.

DMM enumerates all “video present sources” and “video present targets” and then maps the paths connecting the two

This modeling is called VidPN (Video Present Network)
“Video present targets” are the physical connections on a display card

These include HD-15, DVI, CD, S-Video and RCA connectors

Devices can be connected to these “VidPN Targets” include digital and analog monitors, High and Standard definition TVs, etc

The DMM does its best to detect the presence of these devices and their characteristics

Some targets will send a “signal” when they arrive/depart from the port

Some targets can be polled at periodic intervals to determine whether this is/not a device connected

Some targets (RCA connectors, S-Video) cannot even be polled, so SDTV defaults are used

This detection is covered by Monitor Hot Plug Detection
If a device is connected, then DMM can attempt to get the device’s EDID

EDID (extended display identification data) is a format that lets the display supply the host with information about its identity and capabilities independent of the communications protocol used between the monitor and host.
The TVOutTst enumerates and exercises the DirectX API ChangeDisplaySettingsEx(), which is used to configure the TV Out ports on display cards.

Run Time: 10 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running TVOut Test

The test log will provide details on any failures.

Command Syntax

Command option | Description
TVOutTst.exe | Without any options, silently enumerate devices
TVOut_WTT_FVT.pro | the .profile of testcases to be run

Code Tour

File Manifest

File | Location
tvouttst.exe | [testbinroot]\nttest\multimediatest\avcore\vidcap
TVOut_WTT_FVT.pro | [testbinroot]\nttest\multimediatest\avcore\vidcap

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WDDM PnPStop Device Test

Type: Automated Test

Overview

WDDM PnPStop Device Test - This test disables the display adapter.

Details

WDDM PnPStop Device Test - The test disables the display adapter. Setupapi calls are made use of to disable the display device.
Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM PnPStop Device Test

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification

Additional Information:


WDDM Passthrough

Type: Automated Test

Overview

The WDDM Passthrough test verifies that user-mode display drivers correctly handle failures originating from runtime callbacks.

Details

The WDDM Passthrough test intercepts calls from the user-mode display driver into the OS. The test injects failures into these calls and verifies that drivers fail the corresponding DDI call. Drivers must not crash when they see a failure from the OS, and they must also fail the corresponding DDI call when an OS callback fails. This test variation injects failures into the following callbacks:
CreateDeviceCB
DestroyDeviceCB
CreateContextCB
DestroyContextCB
AllocateCB
DeallocateCB
UpdateOverlayCB
FlipOverlayCB
CreateOverlayCB
DestroyOverlayCB
SetDisplayModeCB

Run Time: 20 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM Passthrough

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-69 Display adapter or chipset complies with the DirectX DDK specification
Test Assertion GUID: 7af8c5fb-d668-426c-a663-5c27038e8a01

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification

Additional Information:


TVWLPTest : ehome - premium display tests

Type: Automated Test

Overview

This discusses ehome - premium display tests. These tests are all enacted by a program called TVWLPTest and up to four DShow filters it invokes.
These job verifies that system is capable of supporting premium Media Center TV playback functionality. Tests portions of GRAPHICS-0001 devoted to content protection, GRAPHICS-0043, and GRAPHICS-0055

Details

TvWLPTest is a command line program invoked by the DTM that verifies most of the Media Center requirement. Any failures on any requirment will cause the whole job to fail.

GRAPHICS-0001

This tests the content protection portion of this requirement. Other parts of this requirement are tested in the <> test?
Title: Test Display Adaptor Supports and Exposes Video Output Connector
Success:
This test will succeed if the display adapter supports APS or Macrovision copy protection. It will succeed if display adapter expose required timings. It will succeed if test able to switch TV-out to TV playback mode while TV-out connected to TV Display device and while in this mode display adapter disables flicker filter and overscan compensation. Also it should be in proper TV standard that is NTSC, PAL or SECAM. Then test will switch it to Win Graphics mode while TV-out connected to VGA Display device and if it will switch successfully test will succeed. Also, display adapter must have TV standard set to WIN VGA in order to pass the test.
Failure:
This test will fail if the user aborts the test. If display adapter does not supports APS or Macrovision copy protection. If it does not expose required timings. It also will fail if test will not be able to switch TV-out to TV playback mode while TV-out connected to TV Display device. If display adapter does not disable flicker filter and overscan compensation while in TV playback mode and does not report proper TV standard such as NTSC, PAL, SECAM. It will also fail if driver fails to report required values that used to determine if it in proper mode and have disabled flicker filter and overscan compensation. It will fail in test enable to switch it to Win Graphics mode while TV-out connected to VGA Display adapter and if it does not have WIN VGA TV standards on TV-out while in this mode. Also, it will fail if test fails to set TV Standards and playback modes or driver fails to report required values.

GRAPHICS-0043

Title: Test Display Driver Supports Minimum Display Timing and Modes
Success:
This test will succeed if the display device supports required timings and modes.
Failure:
This test will fail if one or more of the required timings or modes are not supported by the display adapter.

GRAPHICS-0055

Title: Test Display Sub-System Supports Digital TV Resolution and Timing
Success:
This test will succeed if the display device has a digital interfaces and support required digital timings and modes. It will also succeed if the display adapted does not have a digital interface, because this test does not required timings and modes to be checked for display adapters that do not have a digital interface.
Failure:
This test will fail if a display adaptor with a digital interface does not support one or more of the required digital timings or modes.

Run Time: 1 min
Log File: TVWLPTest.xml
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • May need a video display connected to video out port of the display card ????

Running TVWLPTest : ehome - premium display tests

1) Run this job
- this will iterate and test each of the requirements listed above
2) Handle prompts as they occur.

Command Syntax

Command option | Description
tvwlptest <test case ID> “<Device ID of device you want to test>” |

Troubleshooting

If the jobs are too big and hence difficult to debug, run the individual requirement through the DTM as manually scheduled job using the WDKDeviceID parameter and the requirement name (e.g. STREAM-0011) and PnP-ID (50+ character name) as described above in the Alternate Installation Steps
An analog TV monitor of the correct broadcast format. If the card supports digital TV output, a digital TV to connect to. For portable devices, a external computer monitor is also required.

Code Tour

File Manifest

File | Location
TVWLPTest.exe |
TVWLPAudioMonitor.ax |
TVWLPSourceFilter.ax |
TVWLPMPeg2Monitor.ax |
TVWLPVBIMonitor.ax |

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WDDM Sch_Stress

Type: Automated Test

Overview

The WDDM Sch_Stress test verifies system stability while running many GPU-bound memory intensive applications.

Details

The WDDM Sch_Stress test creates many processes that do D3D9 rendering with a large video memory working set. This causes preemption and paging to occur on the GPU. Display drivers must not cause the system to crash or hang while running this test.
Run Time: 30 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM Sch_Stress

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-70 Display driver functions properly, and does not generate hangs or faults, under prolonged stress
Test Assertion GUID: 85ad15b6-d938-43d0-9142-094375997519

Windows Logo Program: GRAPHICS-0038 Display driver functions properly and does not generate hangs or faults under prolonged stress

Additional Information:


Video Memory Management Tests

Type: Automated Test

Overview

Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.
You do not need fnswtt.dll unless you want WTT logging.

Details

Test verifies that video memory is accurately reported and managed.
The following Fnddraw cases make up this test:
MEMMAN_GetAvailableVidMem
This test case examines compares memory values returned by various GetAvailableVidMem calls. The sum of AGP and local video memory amounts should equal the total video memory.
MEMMAN - Video Memory Reuse Test
This test verifies that freed video memory can be reallocated.
MEMMAN - Rand Create/Release Video Memory surfaces 100X Test
This test randomly creates and releases video memory surfaces. As each surface is created, a byte pattern is written to it. Upon release of that surface, the byte pattern is read back to verify surface integrity.
MEMMAN - Consume All Video Mem Test
This test tries to allocate all video memory (local and AGP). As each surface is allocated a byte pattern is written to it. The byte pattern is read back before all surfaces are released to verify integrity.
Test Executable: Fnddraw.exe

Run Time: 01:20:40
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Display adapater with DDraw capabilities

Running Video Memory Management Tests

No specific steps to follow for this test

Command Syntax

Command option | Description
fnddraw.exe dd_vmem.pro -r -c -p"m%MONITOR%" | The %monitor% parameter needs to be replaced with a 1 based index that corresponds to the display under test.

Cautions

The screen saver should be turned off and the power management should be disabled before running this test. Mode changes, full screen apps can cause failures and should be avoided.

Reference Documentation

DirectX SDK (Version 7.0 or Later)

Code Tour

File Manifest

File | Location
fnddraw.exe | multimediatest\video\ddraw
fnswtt.dll | multimediatest\video\ddraw
dd_vmem.pro | multimediatest\video\ddraw\pro

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Read Scan Line

Type: Automated Test

Overview

Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.

Details

Test ensures that the DirectDraw graphics adapter blts are able to report the current scan-line being drawn. Test ensures that reported scan lines are reasonable based on display resolution.
Test Executable: Fnddraw.exe
Test Case Name: API_GetScanLine

Run Time: 00:01:50
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Display adapater with DDraw capabilities

Running Read Scan Line

No specific steps to follow for this test

Command Syntax

Command option | Description
fnddraw.exe dd_scan.pro -r -c -p"m%MONITOR%" | The %monitor% parameter needs to be replaced with a 1 based index that corresponds to the display under test.

Cautions

The screen saver should be turned off and the power management should be disabled before running this test. Mode changes, full screen apps can cause failures and should be avoided.

Reference Documentation

DirectX SDK (Version 7.0 or Later)

Code Tour

File Manifest

File | Location
fnddraw.exe | multimediatest\video\ddraw
fnswtt.dll | multimediatest\video\ddraw
dd_scan.pro | multimediatest\video\ddraw\pro

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Blt Basic - System Memory to Primary Memory

Type: Automated Test

Overview

Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.

Details

This test performs a simple DirectDraw Blt from a system memory surface to the Primary.
The test compares the resulting image against it’s own simulation. Since this is a simple 1 to 1 copy Blt, the test expects the DirectDraw Blt and the simulation to match exactly.
This test runs in all reported display modes.
Because all blts are performed directly to the Primary, you can visually inspect the results. Use the <Pause> key to give yourself more time.
DirectDraw is capable of performing this Blt operation in it’s emulation layer if the driver does not support it. Driver support is indicated by means of the DDCAPS_CANBLTSYSMEM flag, and the various dwSVB fields of the DDNTCORECAPS struct.
Support for System to Video Blts is not required. If the driver does not report the appropriate caps, the DCT will not even run this test.
Test Executable: Fnddraw.exe

Run Time: 00:02:10
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running Blt Basic - System Memory to Primary Memory

No specific steps to follow for this test

Command Syntax

Command option | Description
fnddraw.exe ..\pro\dd_svb.pro -r -c -p"m%MONITOR%" | The %monitor% parameter needs to be replaced with a 1 based index that corresponds to the display under test.

Cautions

The screen saver should be turned off and the power management should be disabled before running this test. Mode changes, full screen apps can cause failures and should be avoided.

Reference Documentation

DirectX SDK (Version 7.0 or Later)

Code Tour

File Manifest

File | Location
fnddraw.exe | multimediatest\video\ddraw
fnswtt.dll | multimediatest\video\ddraw
dd_svb.pro | multimediatest\video\ddraw\pro

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Blt - Stretch - Video Memory to Primary Memory

Type: Automated Test

Overview

Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.

Details

Test ensures that the DirectDraw graphics adapter is able to process a variety of DirectDraw stretch (and shrink) blts from video memory to the primary surface.
The follow Fnddraw cases make up this test
BLT, Stretch (Wx2, Hx.75), VMem to Pri
BLT, Shrink, (3/4), VMem To Primary
BLT Shrink (1/2), VMem to Primary
BLT Stretch x 1.5, VMem to Primary
BLT Stretch x 2, VMem to Primary
Test Executable: Fnddraw.exe

Run Time: 00:35:26
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Display adapater with DDraw capabilities

Running Blt - Stretch - Video Memory to Primary Memory

No specific steps to follow for this test

Command Syntax

Command option | Description
fnddraw.exe dd_sbvv.pro -r -c -p"m%MONITOR%" | The %monitor% parameter needs to be replaced with a 1 based index that corresponds to the display under test.

Cautions

The screen saver should be turned off and the power management should be disabled before running this test. Mode changes, full screen apps can cause failures and should be avoided.

Reference Documentation

DirectX SDK (Version 7.0 or Later)

Code Tour

File Manifest

File | Location
fnddraw.exe | multimediatest\video\ddraw
fnswtt.dll | multimediatest\video\ddraw
dd_sbvv.pro | multimediatest\video\ddraw\pro

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WDDM ManagedPrimary

Type: Automated Test

Overview

The WDDM ManagedPrimary test verifies that display drivers correctly implement managed primary functionality.

Details

The WDDM ManagedPrimary test verifies that display drivers support managed primaries. In particular, this test creates primary surfaces and then calls the user-mode SetDisplayMode DDI. After this the test renders some frames into the surfaces and flips in between them. Next the test changes the display mode (which causes the managed primaries to become unpinned from video memory). Finally the test calls the SetDisplayMode DDI again to cause the managed primaries to become pinned into video memory again. Drivers must not fail calls to the SetDisplayMode DDI during this test.
Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM ManagedPrimary

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-69 Display adapter or chipset complies with the DirectX DDK specification
Test Assertion GUID: 7af8c5fb-d668-426c-a663-5c27038e8a01

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification

Additional Information:


DDraw AGP Memory Tests

Type: Automated Test

Overview

Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.

Details

The DDraw AGP Memory test ensures that the DirectDraw graphics adapter creates basic AGP surfaces.
Test Executable: Fnddraw.exe

Run Time: 00:03:05
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Display adapater with DDraw capabilities

Running DDraw AGP Memory Tests

No specific steps to follow for this test

Command Syntax

Command option | Description
fnddraw.exe dd_agp.pro -r -c -p"m%MONITOR%" | The %monitor% parameter needs to be replaced with a 1 based index that corresponds to the display under test.

Cautions

The screen saver should be turned off and the power management should be disabled before running this test. Mode changes, full screen apps can cause failures and should be avoided.

Reference Documentation

DirectX SDK (Version 7.0 or Later)

Code Tour

File Manifest

File | Location
fnddraw.exe | multimediatest\video\ddraw
fnswtt.dll | multimediatest\video\ddraw
dd_agp.pro | multimediatest\video\ddraw\pro

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


DXGI - Mode Enumeration (32-bit)

Type: Automated Test

Overview

The test verifies correct implementation of IDXGIOutput::FindClosestMatchingMode.

Details

The test generates a predetermined set of target modes, enumerates the available modes and, for each target mode, predicts the mode that should be returned by FindClosestMatchingMode. In accordance with the DXGI specification, the test prioritizes mode attributes as follows when seeking a match: format bit depth, width, height, refresh rate. A failure is reported if the mode returned by the method does not match the predicted mode, or if the method fails when a matching mode does exist.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running DXGI - Mode Enumeration (32-bit)

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Fast User Switching - VideoTest

Overview

Tests video drivers when an MPEG video is being played, on one or more users, and fast-user-switching occurs.

Details

This test will create users on a system and start MPEG video playback on one of the users. Without logging the user out, it will switch to another user via Fast User Switching and start MPEG video playback on that user as well. In a process of the test user switching will happen multiple times. Test failures indicate problems such as failure to switch the user or failure to start an MPEG video playback on a user. The purpose of the test is to make sure that video drivers do not bugcheck while user switching occurs.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running Fast User Switching - VideoTest

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


PC99 #3 system uses WC

Type: Automated Test

Overview

Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.

Details

Test determines whether a display adapter driver meets PC98 requirement no. 2 for Graphics Adapters (System uses WC with higher-performance processors).
The test works by invoking DirectDraw to allocate an off-screen buffer in video memory, performing row-wise and column-wise fills of the buffer and computing the ratio of the speed of the row-wise fill to the speed of the column-wise fill. If the buffer is implemented with write-combining, the row-wise fill will be dramatically faster than the column-wise fill---a pass is reported as long as the ratio is greater than or equal to 2.
Test Executable: Fnddraw.exe

Run Time: 00:00:05
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Display adapater with DDraw capabilities

Running PC99 #3 system uses WC

No specific steps to follow for this test

Command Syntax

Command option | Description
fnddraw.exe dd_wc.pro -r -c -p"m%MONITOR%" | The %monitor% parameter needs to be replaced with a 1 based index that corresponds to the display under test.

Cautions

The screen saver should be turned off and the power management should be disabled before running this test. Mode changes, full screen apps can cause failures and should be avoided.

Reference Documentation

DirectX SDK (Version 7.0 or Later)

Code Tour

File Manifest

File | Location
fnddraw.exe | multimediatest\video\ddraw
fnswtt.dll | multimediatest\video\ddraw
dd_wc.pro | multimediatest\video\ddraw\pro

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Blt - Exotic

Type: Automated Test

Overview

Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.

Details

This test analyzes the GetBltStatus, Zbuffer Blt, Blt FOURCC, and Copy FOURCC functions.
This group of tests evaluates a variety of miscellaneous Blt operations.
3D_Depth Fill Blt Test
Performs a Z-Fills operations on both 16 and 32bpp z-buffers.
BLT_OffscreenOverlap
Performs blts on a variety of offscreen surfaces where the source and destination surface are the same. Blt rects are chosen such that they overlap. The blts are simulated by the tests internal software blitter and compared. Because the blts are simple copies, the expectation is that the real blt and simulation will match exactly.
BLT_GetBltStatusPostFlip
Tests the reliability of the GetBltStatus function before, during, and after a Flip operation.
BLT_GetBltStatusMultBlts
Tests the reliability of the GetBltStatus function before, during, and after a Blt operation.
BLT_ZBuffer
Performs blts between Z-buffer surfaces, and compares.
BLT, FourCC to FourCC
Performs simple copy blts between a variety of offscreen surface formats including FourCC formats. FourCC formats are only tested if the driver sets the DDCAPS2_COPYFOURCC flag which drivers are required to set.
BLT, FourCC to RGB conversion
Performs Blts from YUV (FOURCC) surfaces to an RGB primary. This test is only run if the driver sets the DDCAPS_BLTFOURCC flag.
BLT, FourCC to RGB stretch
Performs Stretched Blts from YUV (FOURCC) surfaces to an RGB primary. This test is only run if the driver sets the DDCAPS_BLTFOURCC and DDCAPS_BLTSTRETCH flags.
Test Executable: Fnddraw.exe

Run Time: 00:08:26
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Display adapater with DDraw capabilities

Running Blt - Exotic

No specific steps to follow for this test

Command Syntax

Command option | Description
fnddraw.exe dd_ob.pro -r -c -p"m%MONITOR%" | The %monitor% parameter needs to be replaced with a 1 based index that corresponds to the display under test.

Cautions

The screen saver should be turned off and the power management should be disabled before running this test. Mode changes, full screen apps can cause failures and should be avoided.

Reference Documentation

DirectX SDK (Version 7.0 or Later)

Code Tour

File Manifest

File | Location
fnddraw.exe | multimediatest\video\ddraw
fnswtt.dll | multimediatest\video\ddraw
dd_vvb.pro | multimediatest\video\ddraw\pro

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WDDM Passthrough - QueryResidency

Type: Automated Test

Overview

The WDDM Passthrough - QueryResidency test ensures that drivers correctly implement the QueryResourceResidency DDI.

Details

The WDDM Passthrough - QueryResidency test calls the user-mode QueryResourceResidency DDI. It then injects specific return codes into the QueryResidencyCB callback and verifies that drivers correctly map these return codes into the return code from the QueryResourceResdiencyDDI. The correct mapping is defined the DDK documentation.
Run Time: 5 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM Passthrough - QueryResidency

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-69 Display adapter or chipset complies with the DirectX DDK specification
Test Assertion GUID: 7af8c5fb-d668-426c-a663-5c27038e8a01

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification

Additional Information:


DDraw Blt - Stretch - AGP to Primary

Type: Automated Test

Overview

Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.

Details

Test ensures that the DirectDraw graphics adapter is able to process blts stretched from AGP surfaces to the primary surface.
Test Executable: Fnddraw.exe

Run Time: 00:28:32
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Display adapater with DDraw capabilities

Running DDraw Blt - Stretch - AGP to Primary

No specific steps to follow for this test

Command Syntax

Command option | Description
fnddraw.exe dd_sbav.pro -r -c -p"m%MONITOR%" | The %monitor% parameter needs to be replaced with a 1 based index that corresponds to the display under test.

Cautions

The screen saver should be turned off and the power management should be disabled before running this test. Mode changes, full screen apps can cause failures and should be avoided.

Reference Documentation

DirectX SDK (Version 7.0 or Later)

Code Tour

File Manifest

File | Location
fnddraw.exe | multimediatest\video\ddraw
fnswtt.dll | multimediatest\video\ddraw
dd_sbav.pro | multimediatest\video\ddraw\pro

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Blt - Stretch & Color Key - System Memory to Primary Memory

Type: Automated Test

Overview

Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.

Details

Test ensures that the DirectDraw graphics adapter is able to process combinations of stretched (and shrunk) blts as well as SOURCE and DESTINATION color key blts from system memory to the primary surface.
The follow Fnddraw cases make up this test
BLT,Stretch(width only), SRCKEY, Sys to pri
BLT,Stretch, SRCKEY, System to primary
Test Executable: Fnddraw.exe

Run Time: 00:15:50
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Display adapater with DDraw capabilities

Running Blt - Stretch & Color Key - System Memory to Primary Memory

No specific steps to follow for this test

Command Syntax

Command option | Description
fnddraw.exe dd_scksv.pro -r -c -p"m%MONITOR%" | The %monitor% parameter needs to be replaced with a 1 based index that corresponds to the display under test.

Cautions

The screen saver should be turned off and the power management should be disabled before running this test. Mode changes, full screen apps can cause failures and should be avoided.

Reference Documentation

DirectX SDK (Version 7.0 or Later)

Code Tour

File Manifest

File | Location
fnddraw.exe | multimediatest\video\ddraw
fnswtt.dll | multimediatest\video\ddraw
dd_scksv.pro | multimediatest\video\ddraw\pro

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WDDM PnPStart Device Test

Type: Automated Test

Overview

PnPStart Device Test - The tests enables the display adapter.

Details

PnPStart Device Test - It is a user mode test which enables the display adapter. There will no reboot required with the new Windows device driver model.
Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM PnPStart Device Test

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification

Additional Information:


Color Fill (64-bit)

Type: Automated Test

Overview

This test verifies proper implementation of the driver functionality that supports the Direct3D9 method IDirect3DDevice9::ColorFill.

Details

This test verifies proper implementation of the driver functionality that supports the Direct3D9 method IDirect3DDevice9::ColorFill.
The set of test cases is defined in terms of a Cartesian product of several sets of attributes:
  • Type of the destination surface for the ColorFill operation. Valid types are:
    • Render targets
    • Offscreen plain surfaces in the D3DPOOL_DEFAULT memory pool.
    • Surfaces belonging to render target textures.
  • Note that the destination surface is always in the D3DPOOL_DEFAULT memory pool.
  • Format of the destination surface.
  • Destination Rectangle. This includes rectangles varying by size, aspect ratio and location and includes horizontal and vertical lines.
  • Color
The test validates each case by verifying that the ColorFill operation succeeded and by comparing the result with a reference image. The surface verification algorithm is applied to the entire destination surface, rather than only to the destination rectangle.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Windows 2000
  • Windows 9x
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x64

Running Color Fill (64-bit)

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

The adapter and driver correctly support the IDirect3DDevice9::ColorFill method.
Test Assertion GUID: 5.89.1


DDraw Blt - Stretch & Color Key - AGP to Primary

Type: Automated Test

Overview

Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.

Details

Test ensures that the DirectDraw graphics adapter is able to process various combinations of stretch and color key blts from AGP surfaces to the primary surface.
Test Executable: Fnddraw.exe

Run Time: 00:12:40
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Display adapater with DDraw capabilities

Running DDraw Blt - Stretch & Color Key - AGP to Primary

No specific steps to follow for this test

Command Syntax

Command option | Description
fnddraw.exe dd_sckav.pro -r -c -p"m%MONITOR%" | The %monitor% parameter needs to be replaced with a 1 based index that corresponds to the display under test.

Cautions

The screen saver should be turned off and the power management should be disabled before running this test. Mode changes, full screen apps can cause failures and should be avoided.

Reference Documentation

DirectX SDK (Version 7.0 or Later)

Code Tour

File Manifest

File | Location
fnddraw.exe | multimediatest\video\ddraw
fnswtt.dll | multimediatest\video\ddraw
dd_sckav.pro | multimediatest\video\ddraw\pro

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Wait For VBlank (32-bit)

Type: Automated Test

Overview

The test verifies proper driver implementation of the vertical blank synchronization functionality that underlies the implementation of IDirect3DDevice9Ex::WaitForVBlank.

Details

The test is automatically executed against several display modes. For each mode, the test determines the expected interval between consecutive vertical retrace periods, based on the mode's refresh rate. It then performs 101 calls to WaitForVBlank and measures the 100 intervals between the return times. Each interval is expected to be comparable to the one predicted by the refresh rate and the test will report a failure if more than 10% of the intervals each differ from the expected interval by more than 2ms.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running Wait For VBlank (32-bit)

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Registry Validation

Type: Automated Test

Overview

This test verifies that display drivers create the correct registry entries.

Details

This test validates the registry entries made by a video card driver to make sure they are complete and sensible. Correct entries in the registry are important for the performance and stability of the Windows graphics stack.

During installation, video card drivers must create registry entries. The GRFX-51 assertion lists the registry entries verified by this test. The test verifies that the registry entries exist and that they contain information of the correct type. Additionally, string registry entries must contain at least one character and must not contain the word “Microsoft.”

Finally, the file version set on the display driver DLL file must conform to the standards described in the test assertions.
Run Time: 1 minute
Log File: registry.log
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Windows 2000
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running Registry Validation

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-51 Device driver install applications for display adapter or chipset create required registry entries
Test Assertion GUID: df423661-f187-441d-89f0-8f3231aded00

Windows Logo Program: GRAPHICS-0034 Device driver install applications for display adapter or chipset create required registry entries

Additional Information:


Conformance ECP [-]

Overview

Test analyzes pixel-by-pixel verification. The concept of an equivalent computational path, ECP, is introduced to test the same functionalities.

Details

The Conformance ECP [x] tests check the functionality of various OpenGL operations to ensure the driver's implementation is valid. This includes viewport clamping and transformations, matrix stacks, vertex orders, transforms, buffer operations, color ramping, masking, selection, feedback, clipping, alpha and stencil planes, dithering, logical operations, pixel operations, rasterizations, polygon operations, lighting, fog, texture mapping, mipmapping, display lists, and evaluator vertex testing.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Windows 2000
  • Windows 9x
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running Conformance ECP [-]

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Update Surface (64-bit)

Type: Automated Test

Overview

The test automatically verifies correct implementation of the driver functionality that underlies the IDirect3DDevice9::UpdateSurface method.

Details

The test uses IDirect3D9::CheckDeviceFormat to determine the combinations of formats and surface types supported by the driver.
For all valid surface type combinations, the test performs a comprehensive set of UpdateSurface operations including full surface and subrect copies, with and without translation.
Automatic verification is accomplished by rendering both the destination surface and a reference surface and comparing the rendered images. The test uses D3DX9's LoadSurfaceFromSurface function to prepare reference images.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Windows 2000
  • Windows 9x
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x64

Running Update Surface (64-bit)

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Stretch Rect (64-bit)

Type: Automated Test

Overview

The test automatically verifies correct implementation of the driver functionality that underlies the IDirect3DDevice9::StretchRect method.

Details

The test uses IDirect3D9::CheckDeviceFormat to determine the combinations of formats and surface types supported by the driver. It also uses IDirect3D9::CheckDeviceFormatConversion to determine the color conversion operations that the driver supports.
For all valid surface type combinations, the test performs a comprehensive set of StretchRect operations, including those that involve stretching, color conversion and copies to or from a subrect. In these test cases, the source surface may be a texture surface (RT or non-RT), an offscreen render target or an offscreen plain surface. The destination must be a render target or RT texture surface.
Under D3D9L, the test also considers a more complete set of source- and destination surface type combinations: each surface may be a non-RT texture surface, an RT texture surface, an offscreen RT or an offscreen plain surface. All sixteen combinations are tested, but, in accordance with D3D9L specifications, the StretchRect operations are limited to those that involve only full-surface copies without stretching or color-conversion.
Automatic verification is accomplished by rendering both the destination surface and a reference surface and comparing the rendered images. The test uses D3DX9's LoadSurfaceFromSurface function to prepare reference images.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Windows 2000
  • Windows 9x
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x64

Running Stretch Rect (64-bit)

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


COPPTest

Type: Automated Test

Overview

These tests execute COPP commands to test display drivers for COPP compatibility.

Details

There are three assertions:
a) The display driver must support COPP driver interfaces
b) The display driver must support CGMS-A and APS
c) The display driver must support HDCP
For all the assertions, application will go through COPP initialization protocol. If initialization fails, all of the assertions will fail. Tests will not actually verify each protection schema but only query the driver for the availability.

Run Time: 5 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running COPPTest

All the connectors that needs to be test should have already been connected and be enabled on Vista.

Command Syntax

Command option | Description
ShellRunnerApp.exe -x [basic/premium] -c [Profile_Name] | Launches the test application for audio profile.

Click to show or hide information. Test Assertions

Test Assertions

1.1 The display driver must support COPP driver interfaces
Test Assertion GUID: E486D7C9-997E-4778-8553-72C4FFFB92CC

1.2 The display driver must support CGMS-A and APS
Test Assertion GUID: AE3ACD54-E11B-4968-8516-D076E37D3EB8

1.3 The display driver must support HDCP
Test Assertion GUID: 2ECA271F-59E9-4206-9471-D698B28A1A71


OPMTest

Type: Automated Test

Overview

These tests execute OPM commands to test display drivers for OPM compatibility.

Details

There are three assertions:
a) The display driver must support PVP-OPM driver interfaces
b) The display driver must support CGMS-A and APS
c) The display driver must support HDCP
For all the assertions, application will go through PVP-OPM initialization protocol. If initialization fails, all of the assertions will fail for premium SKUs (and skip for basic SKUs). Tests will not actually verify each protection schema but only query the driver for the availability.

Run Time: 5 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running OPMTest

All the connectors that needs to be test should have already been connected and be enabled on Vista.

Command Syntax

Command option | Description
ShellRunnerApp.exe -x [basic/premium] -c [Profile_Name] | Launches the test application for audio profile.

Click to show or hide information. Test Assertions

Test Assertions

1.1 The display driver must support PVP-OPM driver interfaces
Test Assertion GUID: E486D7C9-997E-4778-8553-72C4FFFB92CC

1.2 The display driver must support CGMS-A and APS
Test Assertion GUID: AE3ACD54-E11B-4968-8516-D076E37D3EB8

1.3 The display driver must support HDCP
Test Assertion GUID: 2ECA271F-59E9-4206-9471-D698B28A1A71


WDDM SetDXMode

Type: Automated Test

Overview

The WDDM SetDXMode test verifies that display drivers can successful set all display modes that they enumerate.

Details

The WDDM SetDXMode test attempts to set all display modes supported by all outputs on all adapters on the system. The test fails if an attempt to set a display mode fails. Drivers must be able to set all display modes that they enumerate and must not cause the system to crash or hang while executing this test.
Run Time: 2 hours
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM SetDXMode

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-69 Display adapter or chipset complies with the DirectX DDK specification
Test Assertion GUID: 7af8c5fb-d668-426c-a663-5c27038e8a01

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification

Additional Information:


DDraw Blt - Color Key - AGP to Primary

Type: Automated Test

Overview

Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.

Details

Test ensures that the DirectDraw graphics adapter is able to process Color key blts from AGP surfaces to the primary surface.
Test Executable: Fnddraw.exe

Run Time: 00:06:40
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Display adapater with DDraw capabilities

Running DDraw Blt - Color Key - AGP to Primary

No specific steps to follow for this test

Command Syntax

Command option | Description
fnddraw.exe dd_ckav.pro -r -c -p"m%MONITOR%" | The %monitor% parameter needs to be replaced with a 1 based index that corresponds to the display under test.

Cautions

The screen saver should be turned off and the power management should be disabled before running this test. Mode changes, full screen apps can cause failures and should be avoided.

Reference Documentation

DirectX SDK (Version 7.0 or Later)

Code Tour

File Manifest

File | Location
fnddraw.exe | multimediatest\video\ddraw
fnswtt.dll | multimediatest\video\ddraw
dd_ckav.pro | multimediatest\video\ddraw\pro

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WDDM ModeChange

Type: Automated Test

Overview

The WDDM ModeChange test verifies system stability during display mode changes.

Details

The WDDM ModeChange test changes the display mode of all display outputs on the system and concurrently locks primary surfaces for use by the CPU. The test may put the system into rotated modes. Display drivers must not crash or hang while this test is running.
Run Time: 60 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM ModeChange

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-70 Display driver functions properly, and does not generate hangs or faults, under prolonged stress
Test Assertion GUID: 85ad15b6-d938-43d0-9142-094375997519

Windows Logo Program: GRAPHICS-0038 Display driver functions properly and does not generate hangs or faults under prolonged stress

Additional Information:


Blt - Textures

Type: Automated Test

Overview

Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.

Details

This series of tests verify that graphics adapters correctly perform blts between a variety of texture formats. The tests are broken out by the memory type of the source and destination textures (System, Video and AGP). The tests are implemented in the Fnddraw.exe, and consist of the following specific tests:
Blt_Texture Vid to Vid
Blt_Texture Sys to AGP
Blt_Texture Sys to Vid
Blt_Texture Sys to Sys
Each test runs through a variety of pixel formats, blitting between the memory types expressed in the test name. Each blt is a simple copy (no stretching or color keying in this revision of the test). The test expects the destination to perfectly match the source after the blt. Any deviation is considered a failure.
All blts are performed on off-screen surfaces (textures). However, the results are copied to the screen to aid in debugging. (Some detail is likely lost in converting from the texture pixel format to the pixel format of the primary.)
Currently the test will tolerate a driver returning DDERR_UNSUPPORTED on the Blt call, and not consider it a failure. This is likely to change in the future.
In our internal testing we discovered a vast number of failures resulted from drivers allowing textures to be created in unsupported pixel formats. Drivers should be sure to fail CanCreateSurface() for all non-system memory textures whose pixel formats they do not support. The test blindly runs through a pre-determined list of pixel formats. It trusts that the driver will fail the surface creation, if the pixel format is not supported.
Test Executable: Fnddraw.exe

Run Time: 00:01:00
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Display adapater with DDraw capabilities

Running Blt - Textures

No specific steps to follow for this test

Command Syntax

Command option | Description
fnddraw.exe dd_txblt.pro -r -c -p"m%MONITOR%" | The %monitor% parameter needs to be replaced with a 1 based index that corresponds to the display under test.

Cautions

The screen saver should be turned off and the power management should be disabled before running this test. Mode changes, full screen apps can cause failures and should be avoided.

Reference Documentation

DirectX SDK (Version 7.0 or Later)

Code Tour

File Manifest

File | Location
fnddraw.exe | multimediatest\video\ddraw
fnswtt.dll | multimediatest\video\ddraw
dd_txblt.pro | multimediatest\video\ddraw\pro

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Stretch Rect (32-bit)

Type: Automated Test

Overview

The test automatically verifies correct implementation of the driver functionality that underlies the IDirect3DDevice9::StretchRect method.

Details

The test uses IDirect3D9::CheckDeviceFormat to determine the combinations of formats and surface types supported by the driver. It also uses IDirect3D9::CheckDeviceFormatConversion to determine the color conversion operations that the driver supports.
For all valid surface type combinations, the test performs a comprehensive set of StretchRect operations, including those that involve stretching, color conversion and copies to or from a subrect. In these test cases, the source surface may be a texture surface (RT or non-RT), an offscreen render target or an offscreen plain surface. The destination must be a render target or RT texture surface.
Under D3D9L, the test also considers a more complete set of source- and destination surface type combinations: each surface may be a non-RT texture surface, an RT texture surface, an offscreen RT or an offscreen plain surface. All sixteen combinations are tested, but, in accordance with D3D9L specifications, the StretchRect operations are limited to those that involve only full-surface copies without stretching or color-conversion.
Automatic verification is accomplished by rendering both the destination surface and a reference surface and comparing the rendered images. The test uses D3DX9's LoadSurfaceFromSurface function to prepare reference images.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Windows 2000
  • Windows 9x
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86

Running Stretch Rect (32-bit)

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Color Fill (32-bit)

Type: Automated Test

Overview

This test verifies proper implementation of the driver functionality that supports the Direct3D9 method IDirect3DDevice9::ColorFill.

Details

The set of test cases is defined in terms of a Cartesian product of several sets of attributes:
  • Type of the destination surface for the ColorFill operation. Valid types are:
    • Render targets
    • Offscreen plain surfaces in the D3DPOOL_DEFAULT memory pool.
    • Surfaces belonging to render target textures.
  • Note that the destination surface is always in the D3DPOOL_DEFAULT memory pool.
  • Format of the destination surface.
  • Destination Rectangle. This includes rectangles varying by size, aspect ratio and location and includes horizontal and vertical lines.
  • Color
The test validates each case by verifying that the ColorFill operation succeeded and by comparing the result with a reference image. The surface verification algorithm is applied to the entire destination surface, rather than only to the destination rectangle.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Windows 2000
  • Windows 9x
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86

Running Color Fill (32-bit)

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WDDM Sync - VolBlt

Type: Automated Test

Overview

The WDDM Sync VolBlt test verifies that user-mode drivers properly synchronize the CPU and GPU when resources are used by the CPU and GPU.

Details

The WDDM Sync - VolBlt test creates a video memory volume texture. It then uses the VolBlt DDI to ask the user-mode driver to program the GPU to write into the volume texture. The test then locks the texture with the CPU and verifies that the texture contents read by the CPU match the contents that should have been written into the texture via the VolBlt DDI.

Run Time: 20 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM Sync - VolBlt

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-69 Display adapter or chipset complies with the DirectX DDK specification
Test Assertion GUID: 7af8c5fb-d668-426c-a663-5c27038e8a01

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification

Additional Information:


WDDM Passthrough - Lock

Type: Automated Test

Overview

The WDDM Passthrough test verifies that user-mode display drivers correctly handle failures originating from runtime callbacks.

Details

The WDDM Passthrough test intercepts calls from the user-mode display driver into the OS. The test injects failures into these calls and verifies that drivers fail the corresponding DDI call. Drivers must not crash when they see a failure from the OS, and they must also fail the corresponding DDI call when an OS callback fails. This test variation injects failures into the following callbacks:
LockCB

UnlockCB

Run Time: 5 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM Passthrough - Lock

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-69 Display adapter or chipset complies with the DirectX DDK specification
Test Assertion GUID: 7af8c5fb-d668-426c-a663-5c27038e8a01

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification

Additional Information:


Blt Basic - Video Memory to Primary Memory

Type: Automated Test

Overview

Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.

Details

Performs a variety of Blt tests where both the source and destination are in video memory. Drivers are required to support these blts. Support is expressed by means of the DDCAPS_BLT flag.
The test compares the Blt results against it’s own simulation. Since these are simple 1 to 1 copy Blts, the test expects the DirectDraw Blt and the simulation to match exactly.
The following Fnddraw cases make up this test
BLT_OnscreenOverlap – Performs blts where the source and destination are on the same surface. To further complicate things, the blt rectangles are chosen such that they overlap.
BLT_BltFrontToBackBuff – Performs a blt from the front buffer of a primary flipping chain to the back buffer.
BLT_BltFast From/To Same Surface – This is the original overlapping blt test. From a driver standpoint it’s a simpler version of Blt_OnscreenOverlap mentioned above.
BLT Basic, VMem to Primary – Performs a basic blt from an offscreen video memory surface to the Primary. The blt is compared against a test generated reference image. The images are expected to match exactly.
BLT Basic, Offscreen Surfaces – Performs blts from a variety of memory types.
Test Executable: Fnddraw.exe

Run Time: 00:02:10
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Display adapater with DDraw capabilities

Running Blt Basic - Video Memory to Primary Memory

No specific steps to follow for this test

Command Syntax

Command option | Description
fnddraw.exe dd_vvb.pro -r -c -p"m%MONITOR%" | The %monitor% parameter needs to be replaced with a 1 based index that corresponds to the display under test.

Cautions

The screen saver should be turned off and the power management should be disabled before running this test. Mode changes, full screen apps can cause failures and should be avoided.

Reference Documentation

DirectX SDK (Version 7.0 or Later)

Code Tour

File Manifest

File | Location
fnddraw.exe | multimediatest\video\ddraw
fnswtt.dll | multimediatest\video\ddraw
dd_vvb.pro | multimediatest\video\ddraw\pro

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WDDM Scheduler Stress (No PrePatching)

Type: Automated Test

Overview

The WDDM Scheduler Stress (No PrePatching) test verifies system stability while running many GPU-bound, memory intensive applications when pre-patching of DMA buffers is disabled.

Details

The WDDM Scheduler Stress (No PrePatching) test creates many processes that do D3D9 rendering with a large video memory working set. This causes preemption and paging to occur on the GPU. The test puts the operating system into a mode that causes it to never pre-patch DMA buffers. Display drivers must not cause the system to crash or hang while running this test.
Run Time: 30 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM Scheduler Stress (No PrePatching)

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-70 Display driver functions properly, and does not generate hangs or faults, under prolonged stress
Test Assertion GUID: 85ad15b6-d938-43d0-9142-094375997519

Windows Logo Program: GRAPHICS-0038 Display driver functions properly and does not generate hangs or faults under prolonged stress

Additional Information:


CopyRects Functionality (64-bit)

Type: Automated Test

Overview

The test automatically verifies the functionality provided by the IDirect3DDevice8::CopyRects method by comparing surfaces generated by tested operations with reference surfaces generated by the test itself.

Details

For each D3D8 format, the test uses IDirect3D8::CheckDeviceFormat to determine the surface types, if any, supported by the driver. The test then generates representative surfaces for each combination of format and surface type and performs a set of CopyRects operations for each pair of source and destination surfaces that share the same format. These operations include full-surface copies, subrect copies with and without translation, and copies of multiple overlapping rectangles. In each case, the result of the operation is evaluated automatically by comparing the content of the destination surface with that of a reference surface generated by the test.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Windows 2000
  • Windows 9x
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x64

Running CopyRects Functionality (64-bit)

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Automatic Verification of IDirect3DDevice8::CopyRects.
Test Assertion GUID: 5.13.1


WDDM GammaRamp

Type: Automated Test

Overview

The WDDM GammaRamp test verifies that kernel-mode display drivers succeed attempts to set gamma ramps.

Details

The WDDM GammaRamp test is a basic test of LDDM gamma ramp functionality. It sets gamma ramps via GDI and via OS kernel-mode entry points. Drivers must not crash or fail during this process.
Run Time: 2 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM GammaRamp

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-69 Display adapter or chipset complies with the DirectX DDK specification
Test Assertion GUID: 7af8c5fb-d668-426c-a663-5c27038e8a01

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification

Additional Information:


WDDM ModifyVAD

Type: Automated Test

Overview

The WDDM ModifyVAD test verifies that drivers correctly protect accesses to user-mode virtual addresses.

Details

The WDDM ModifyVAD test adjusts the access rights associated with command buffers and patch location lists. Kernel-mode drivers must use __try/__except when accessing these buffers to avoid crashing the system. Drivers pass this test if they do not cause the system to crash or hang.
Run Time: 2 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM ModifyVAD

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GRFX-70 Display driver functions properly, and does not generate hangs or faults, under prolonged stress
Test Assertion GUID: 85ad15b6-d938-43d0-9142-094375997519

Windows Logo Program: GRAPHICS-0038 Display driver functions properly and does not generate hangs or faults under prolonged stress

Additional Information:


D3D Cross Process Sharing

Overview

Verify support for D3D9L Cross process resource sharing.

Details

Test cases:
CONF:Create - Create shared resource
CONF:Open - Create and open shared resource in same proccess.
CONF:ClientOpen - Create shared in Proccess1 and open in Process2.
CONF:Verify - Process2 verify that opened resource's content is correct.
CONF:Fill - Process2 fills open resource and Process1 verify content.
CONF:Lock - Process1 locks resource, Process2 locks (should fail), Process2 unlock (should fail), Process1 unlock, Process2 lock (should fail), Process2 unlock (should fail), Process1 unlock (should fail).
CONF:ReleaseSourceUseOpen - Process1 create resource, Proccess2 open resource, Proccess2 verify content of resource, Proccess1 release resource, Process2 use resource, Process1 open resource, Process1 update resource content.
The test cycles on resources types or you can control lock onto just one resource type using the command line.
To run with only one resource type use -ResourceType:<ResourceType>
Resource types that can be used are:
OFFSCREENPLAIN
DEPTHSTENCIL
RENDERTARGET
TEXTURE
VOLUMETEXTURE
VERTEXBUFFER
INDEXBUFFER

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running D3D Cross Process Sharing

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


VPE and Kernel Tests

Type: Automated Test

Overview

Most of the DirectDraw tests are housed in Fnddraw.exe. You can run Fnddraw outside of the DCT shell, and select initial tests. Use the “Tests->Select Tests” menu item.
The test titles listed in the DCT shell, do not directly match the test names in Fnddraw. In fact the names in the DCT often refer to a group of Fnddraw tests. You can obtain the Fnddraw test case names from the DCT log file.
Many Fnddraw tests (especially Blt related tests) can be paused to give you time to visually analyze the blt results. Use the <Pause> key to pause and resume.
Use <ESC> to abort a test run. Be patient, some tests are more responsive than others.

Details

Tests perform a variety of sub tests including VideoPort flipping, scan-line and vblank synchronization, and bandwidth and pixel format reporting.
If the display driver claims to support VPE (via the DDCAPS_VPE flag), then there must be DVD and/or Analog Capture hardware available for the test. The analog decoder must have a valid video signal, and the DVD player should have a disc loaded.
KERNEL_ReleaseKernelHandle

KERNEL_GetKernelHandle

VPE_UpdateVideo

VPE_GetVideoPortConnectInfo

VPE_StopVideo

VPE_StartVideo

VPE_CreateVideoPort

VPE_QueryVideoPortStatus

VPE_GetFieldPolarity

VPE_GetVideoSignalStatus

VPE_SetTargetSurface

VPE_Flip

VPE_WaitForSync

VPE_GetBandwidthInfo

VPE_GetInput/OutputFormats
Test Executable: Fnddraw.exe

Run Time: 00:00:05
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Display adapater with DDraw capabilities

Running VPE and Kernel Tests

No specific steps to follow for this test

Command Syntax

Command option | Description
fnddraw.exe dd_vpe.pro -r -c -p"m%MONITOR%" | The %monitor% parameter needs to be replaced with a 1 based index that corresponds to the display under test.

Cautions

The screen saver should be turned off and the power management should be disabled before running this test. Mode changes, full screen apps can cause failures and should be avoided.

Reference Documentation

DirectX SDK (Version 7.0 or Later)

Code Tour

File Manifest

File | Location
fnddraw.exe | multimediatest\video\ddraw
fnswtt.dll | multimediatest\video\ddraw
dd_vpe.pro | multimediatest\video\ddraw\pro

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Conformance ECP [3]

Overview

Test analyzes pixel-by-pixel verification. The concept of an equivalent computational path, ECP, is introduced to test the same functionalities.

Details

The Conformance ECP [x] tests check the functionality of various OpenGL operations to ensure the driver's implementation is valid. This includes viewport clamping and transformations, matrix stacks, vertex orders, transforms, buffer operations, color ramping, masking, selection, feedback, clipping, alpha and stencil planes, dithering, logical operations, pixel operations, rasterizations, polygon operations, lighting, fog, texture mapping, mipmapping, display lists, and evaluator vertex testing.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Windows 2000
  • Windows 9x
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running Conformance ECP [3]

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WDDM HPD Notification Test

Type: Automated Test

Overview

WDDM HPD Notification Test -Test for HPD removal and arrival notification event.

Details

WDDM HPD Notification Test - It is a user mode test. The user has to first generate a HPD removal event by plugging out a monitor. Then the user is required to plug in a monitor. The tests reports success if it detect the arrival event after it detected the removal event.
Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WDDM HPD Notification Test

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:

Windows Logo Program: GRAPHICS-0015 Display adapter or chipset complies with the DirectX DDK specification

Additional Information:


Game Devices Testing

This section describes how to test storage devices and controllers in order to qualify them for the "Designed for Windows" logo.

Common Controller Testing

USB Gaming Device Testing


Common Controller Testing

Common Controller Testing Overview

Preparing for Common Controller Testing

Common Controller Tests


Common Controller Testing Overview

These procedures test your product for proper functionality by using the Microsoft Windows Driver Kit (WDK) and the Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as requried for the device.

Common Controller Tests

© 2006 Microsoft Corporation
Send feedback on this topic
DTM Releases
Built on April 19, 2006
Build machine: CAPEBUILD


Preparing for Common Controller Testing

Before running the Common Controller tests on a test system or systems, you must install and configure the system hardware, choose the target Windows operating system and install and configure the Device Test Manager (DTM). This section summarizes the Common Controller related requirements and procedures. For information about installing and configuring the DTM, see Driver Test Manager.

Test System Configuration

Use the following procedure to prepare the test systems for testing the Common Controller for your target operating system.

To configure test systems for Common Controller testing
  1. Attach a USB 2.0 Hub to your test system.
  2. Attach a Common Controller to the USB 2.0 Hub, with the headset attached to theCommon Controller.
  3. Open Joy.cpl and ensure that the Common Controller shows up in joy.cpl
  4. If you have not done so already, install the the DTM controller and the DTM Studio. On each test system, install the DTM client. For information, see Driver Test Manager


Running the Common Controller Tests (HID)

After you have installed the test devices and drivers in the test clients, and have set up the DTM controller, studio, and clients, you can begin running the logo tests.

To use DTM to run the Common Controller logo tests for the HID device
  1. Start DTM studio.
  2. Switch to the Device Console window.
  3. Select the Submission button.
  4. Select new submission.
  5. Select OS, Select Device Submission, Game Devices, Common Controller, select Qualification Level.

    Name your submission and select your machine pool where the devices are installed.

    Check the ‘no driver files’ (This is because drivers are in box).

    Find and select your device under the Human Interface Device node.

    Finish

  6. Select all the test, click on the Add Selected button.
  7. When you are ready to run the jobs, select Schedule.
  8. Use the Job Monitor to track the progress of jobs as they are executed.

    Once all jobs have passed, right on anything in the decvice pane and select Create Submission.

Driver Reliability Signature Program

If you are submitting a driver with your device submission, you must also run the Driver Reliability (DRS) tests and tools. For more information, see Driver Reliability Tools and Tests.


USB Gaming Device Testing Overview

These procedures test your USB gaming device for proper functionality by using the Microsoft Windows Driver Kit (WDK) and the Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as required for the device.

USB Gaming Device Tests

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Preparing for USB Gaming Device Testing

Before running the USB Gaming Device tests on a test system or systems, you must install and configure the system hardware, choose the target Microsoft Windows operating system, and install and configure the Device Test Manager (DTM). This section summarizes the USB Gaming Device related requirements and procedures. For information about installing and configuring the DTM, see Driver Test Manager.

Test System Configuration

Use the following procedure to prepare the test systems for testing the USB Gaming Device for your target operating system.

  1. Attach a USB 2.0 Hub to your test system.
  2. Attach a USB Gaming Device to the USB 2.0 Hub, with the headset attached to theUSB Gaming Device.
  3. Open Joy.cpl and ensure that the USB Gaming Device shows up in Joy.cpl.
  4. If you have not done so already, install the the DTM controller and the DTM Studio.
  5. On each test system, install the DTM client. For information, see Driver Test Manager.


Running the USB Gaming Device Tests

After you have installed the test devices and drivers in the test clients, and have set up the DTM controller, studio, and clients, you can begin running the logo tests.

To run the USB Gaming Device logo tests
  1. Start DTM studio.
  2. Switch to the Device Console window.
  3. Click Submission.
  4. Select new submission.
  5. Click OS, Select Device Submission, Game Devices, DirectInput, and Qualification Level.
  6. Name your submission and select your machine pool where the devices are installed.
  7. Select No driver files (because drivers are in-box).
  8. Find and select your device under the Human Interface Device node.
  9. Click Finish.
  10. Select all of the tests, and then click the Add Selected button.
  11. When you are ready to run the jobs, click Schedule.
  12. Use the Job Monitor to track the progress of jobs as they are executed.
  13. After all jobs have passed, right-click anything in the device pane and click Create Submission.

Driver Reliability Signature Program

If you are submitting a driver with your device submission, you must also run the Driver Reliability (DRS) tests and tools. For more information, see Driver Reliability Tools and Tests.


Troubleshooting USB Gaming Device Testing


HID Tests

Test name | Target operating system | Test description
DirectInput Game | Windows Vista | This test is mostly automated, with some manual input at the very beginning to test axis functionality. This test relies on Dinput alone to ensure that the device you are testing is functioning as expected.
MCE Remote Control Certification Tool | Windows Vista | Verifies IR Remote control support premium Media Center functionality. Tests INPUT-0006 For a remote to be certified, it must satisfy two criteria: - all the buttons on the remote must work - all the required buttons must be on the remote.
XBOX 360 Controller Feature Test | Windows Vista | Manual test to ensure that all functions of the common controller work as expected. Buttons, Axis, Rumble, Audio
XBOX 360 Controller State and Audio Test | Windows Vista | Manual test that allows tester to get instant feedback as to what functions of the common controller are working, as well as view the capabilities of the controller.


DirectInput Game

Type: Manual Test

Overview

This test is mostly automated, with some manual input at the very beginning to test axis functionality. This test relies on Dinput alone to ensure that the device you are testing is functioning as expected.

Details

Joydrv relies on the DirectInput API to test your device. This test is almost completely automated, except for the first axis functionality tests. Test results are given at the end of the test, in the test harness itself.
Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running DirectInput Game

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


MCE Remote Control Certification Tool

Type: Manual Test

Overview

Verifies IR Remote control support premium Media Center functionality. Tests INPUT-0006
For a remote to be certified, it must satisfy two criteria:
- all the buttons on the remote must work
- all the required buttons must be on the remote.

Details

The MCE Remote Control Certification Tool allows the user to test and certify Media Center remote controls. For a remote to be certified, it must satisfy two criteria:
    • All the buttons on the remote must work.
    • All the required buttons must be on the remote.
See details below.
(Note - details in the document came from link below - including here for change tracking. Remove from final docs
http://ehome/TeamSites/TV/TVDK/WDK%20Docs/MCE%20Remote%20Self%20Certification%20Tool%20Specification.doc
)

Run Time:
Log File: RCTester.xml ???
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • Media Center IR remote control and receiver

Running MCE Remote Control Certification Tool

[This is preliminary documentation and subject to change.]
The MCE Remote Control Certification Tool allows the user to test and certify Media Center remote controls. For a remote to be certified, it must satisfy two criteria:
    • All the buttons on the remote must work.
    • All the required buttons must be on the remote.
This tool runs in two modes, a self test mode useful for diagnosing problems, and a certification tool used for the logo program. The Main menu allows you to specify which mode to run it in.
For the Remote control logo, the certification part must be run.
Definitions and abbreviations
  • MCE: Media Center Edition
  • OEM: Original Equipment Manufacturer (e.g. Dell, Gateway, Hewlett-Packard)
  • RC6: A Philips remote control protocol where pressing the same key twice triggers a toggle bit. This means, even if the signal is temporarily blocked, the sensor can tell if you’ve been holding the button down or pressing it multiple times.
  • UI: User Interface
  • Teletext: Located only in Europe, it’s “the poor man’s internet.”
  • The Green Button: featuring a picture of the eHome flag, it launches Media Center
  • Optional Buttons
    • My Music, My Pictures, My TV, My Videos, Radio
    • DVD Angle, DVD Audio, DVD Subtitle, Aspect
    • OEM 1, OEM 2, OEM 3: OEMs specify the function of these buttons
    • #, *
    • Print, Recorded TV (these are required for the credit card remote)
    • Teletext On/Off, Teletext Index, Red, Green, Yellow, Blue (these are required in Europe)
  • Restricted Buttons (these have not yet been implemented but will be in the future)
    • Display
    • Orange (Teletext)
    • Eject
    • Messenger
    • Remote Setup
  • Full-Size Remote Required Buttons (every MCE desktop and some MCE laptops)
    • 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
    • Channel/Page Up, Channel/Page Down, Volume Up, Volume Down, Mute
    • Arrow Up, Arrow Down, Arrow Left, Arrow Right
    • Back, Clear, Enter/OK, More Info
    • Play, Stop, Rewind, Fast Forward, Pause, Replay, Skip, Record
    • Live TV, Guide, DVD Menu
    • The Green Button, Standby
  • Credit Card Remote Required Buttons (some MCE laptops)
    • Channel/Page Up, Channel/Page Down, Volume Up, Volume Down, Mute
    • Arrow Up, Arrow Down, Arrow Left, Arrow Right
    • Back, Enter/OK, More Info
    • Play, Stop, Rewind, Fast Forward, Pause, Replay, Skip, Record
    • Live TV, Guide, DVD Menu, Recorded TV
    • The Green Button, Standby
    • Recorded TV, Print
  • Features
    • Main Menu
      • Description
Provide the main menu from which the user can
    1. Launch the Self-test tool
    2. Launch the Self-certification tool
    3. Exit the program. (Not shown here.)
Current Design:
Figure 1.1
    • Self-Test Tool
      • Description
Allow users to test individual buttons on their remote, so they can figure out which ones work and which ones don’t. When a button on the remote control is pressed, it checks for the Hid usage and the key associated with it and populate a row with the proper values, as indicated by the column names. If a key fails it populates the name as unassigned (which was not in the design shown here.).
  • Column Names :
    • Name
      • Name of the button pressed
    • Button Code
      • Button identifier assigned by Windows
    • Required?
      • Tells if button required or optional
    • HID Page
      • Classifies group to which button belongs
    • HID Usage
      • Classifies group to which button belongs
    • HID Value
      • Classifies group to which button belongs
    • Windows Mapping
      • Windows function to which button maps
    • Warning
      • Error information about button pressed
    • Decoder ID
      • ID of decoder (NEC, RC6, etc) used to interpret signal
    • Code Value
      • Value button press sends
    • Code Bit Length
      • Length of code in bits
    • Self-Certification Tool
      • Description
Take users through the certification process, making them test each required button and giving them the choice to test optional ones. Produce an encrypted file containing the results for the user to return to the appropriate Microsoft representative, who, at this point, is michni.
Select Country: This is the country that the OEM is shipping the remote for.
Optional Buttons: The OEM needs to check any optional buttons that the remote is going to include so that we are covering those buttons by testing them and make sure they are passing.
RC6 Remote Control: We support 2 protocols and they are Philips RC6 and Samsung protocol. The OEM needs to check this if the remote he is shipping is using RC6 protocol. This needs special testing and when this check box is checked, this tool will ask the OEM to press each button twice to make sure that every time the key is toggled and this is the RC6 protocol logic.
      • Issues and Solutions
Current Design:
Figure 3.1.1
Signal Quality Test Form:
This form will decide whether the key you are pressing and holding on the remote is received properly by the receiver or not. The user needs to hold the button till it asks you to otherwise it reports that the test cannot continue. Screen shots are attached to give you a better idea on how this works.
Figure 3.2.1.1
Figure 3.2.1.2
Figure 3.2.1.3
Figure 3.2.2
Remote Control Self-Certify Test Form:
Figure 3.3.1
This form is the one that allows OEMs to enter all the required buttons on the remote and any optional buttons that they specified in the previous form. The user is supposed to enter the button that is displayed on this form and if anything else is pressed other than the required button or if the hid code is implemented wrongly in the remote itself, then the last result will be failed.
The save button is enabled once all the required and optional buttons are tested and the OEM can save the log file.
    • In the “Press the following button on your remote control” field, display the name of a button from the buttons-to-test list.
      • The buttons-to-test list includes (a) all required buttons and (b) the optional buttons that were checked on the previous page of the wizard. For a list of which buttons are required for which remotes, refer to the Definitions and Abbreviations section of this document.
    • When the user presses that button on the remote control, verify that it is functioning and transmitting correctly.
      • If so, display “Pass” in the Last Result field.
        • If the user is self-certifying an RC6 remote and this button has not yet passed twice, display the name of this button in the “Press the following button on your remote control” field so that the user pushes it again. This is to test the toggle bit.
        • Otherwise, log the fact that this button is working, remove it from the buttons-to-test list and display the name of the next applicable button in the “Press the following button on your remote control” field. If there are no buttons remaining, log the fact that all buttons passed certification and take the user to the next page in the wizard.
      • If not, display “Fail.” Do not remove the button from the list of buttons-to-test.
If the user selects “Skip,” display the name of the next applicable button from the buttons-to-test list

Command Syntax

Command option | Description

Cautions

Standard issues with IR remote controls should be observed. For example, the remote control must be reasonably close to the receiver and pointed at it.

Troubleshooting

The tool may be used in self-test mode to isolate problems with particular buttons.
Add links to: the 'Green Button Spec' (currently on : \\ehomefs\eHome\Private\beta\OPKDocs\OPKDocs_040306\Green_Button_Guidelines\Green Button Guidelines.doc) the 'RC Spec' (Currently on: \\ehomefs\eHome\Teams\User Interaction\IR Receiver Docs\Windows Vista IR Hardware Requirements.doc)

Code Tour

File Manifest

File | Location
RCTester.exe |

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


XBOX 360 Controller Feature Test

Type: Manual Test

Overview

Manual test to ensure that all functions of the common controller work as expected.
Buttons, Axis, Rumble, Audio

Details

XNACCTST was created to ensure that the common controller device as a whole is responding as it should, through the XINPUT API. This tests all of the capabilities that the device you have running is capable of. This test will determine what type of common controller device is attached, and adjust its tests accordingly, i.e. wheels test differently than arcade sticks. This is a completely manual test, with the GUI giving you prompts and instructions on what action to perform. There is an xml output created with test results after each completed pass.
Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running XBOX 360 Controller Feature Test

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


XBOX 360 Controller State and Audio Test

Type: Manual Test

Overview

Manual test that allows tester to get instant feedback as to what functions of the common controller are working, as well as view the capabilities of the controller.

Details

XNAState is the test app that can be used to view the capabilities of all the devices connect to the PC, and their real time data. This test is a manual test, that is used to check if the XInput APIs function correctly when the controllers ‘ objects are maneuvered. This test displays data from the controller in a GUI. You will be asked to hit a button on the controller, then the GUI will pop. Test that each button you touch gives you a response in the right spot, that the left and right motors work (rumble), that both motors work together, and that you can control the strength of the motors. Use the audio portion of this test to listen and communicate with other controllers audio by running multiple instances of this test and selecting different ports for each device. By selecting the view capabilities button, you can view what buttons the device is capable of using. There is no xml output for this as it is all visual testing by direct interaction with the controller.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running XBOX 360 Controller State and Audio Test

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Imaging Testing

This section describes how to test storage devices and controllers in order to qualify them for the "Designed for Windows" logo.

Imaging > Scanning


Scanner Testing Overview

The procedures presented in this section outline the process for testing your scanner for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as requried for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

Scanner Tests

The list of test you need to run depend upon the capabilities of the device or system being tested. To see the complete list of tests that could be required for your device, see the .

Run time: approximately <TBD> hours

Hardware requirements

The following hardware is required for Scanner testing. Additional hardware may be required if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • Basic WDK Test Setup (Controller, Studio, and Client systems)
  • At least one scanner installed on a Client system

Software requirements

It is good practice to clean install the OS on Client systems before final test passes to ensure the system is in a known clean state.

The following software is required to run the Scanner tests:

  • Install correct OS build on the WDK Client for intended Logo program
  • AppVerifier – see below for details
  • The driver package being tested installed on a Client System

For Beta 2 of the OS you will need to manually install AppVerifier on client systems in order for the tests to work properly and pass. AppVerifier can be downloaded from the link below. Install AppVerifier on all client systems. The WDK tests will launch AppVerifier as needed. Uninstalling the kit will not uninstall [image] AppVerifier.

Tester knowledge requirements

To run the Scanner tests, testers must know how to accomplish the following tasks:

  • Install a scanner on a Client system
  • Use WDK Studio to create new submissions and package results


Preparing for Scanner Testing

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see the .

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, see .

Test system configuration

The Scanner test kit uses a basic WDK lab setup. Once the controller has been setup, and a machine pool has been created you need to apply the Scanner config dimension to the pool before adding any client systems to the pool.

  1. Right click the pool and choose properties
  2. Choose the “MCU Policy” tab from the pool properties menu
  3. Choose the “Wdk\ConfigureScanner” dimension and add it to the pool.
  4. Click “Apply” and then “OK”


Running the Scanner Tests

Follow the general directions for creating a new logo submission and scheduling jobs found in the WDK documentation.


Troubleshooting Scanner Testing

Refer to the specific test documentation for troubleshooting help.


Imaging Tests

Test name | Target operating system | Test description
WIA Tester | Windows Vista | This test tool verifies that all WIA properties for pre-Vista style drivers are implemented according to WDK and Windows Vista Logo requirements. It also verifies the correct structure of WIA Items tree built by pre Vista scanner driver. It will help driver developers to detect properties and item tree implementation errors.
WIA Error Handler Tool | Windows Vista | This is an automated Windows Driver Kit (WDK) tool for testing behavior of WIA minidrivers related to error handler. This tool verifies that a driver does not cause applications or the WIA service to crash or hang in edge conditions when the driver sends a message to an error handler or receives a message in its error handler. It also guarantees a consistent and quality experience for the user (Windows come and go when expected, and the driver handles messages from error handlers appropriately by canceling transfers, etc).
WIA Tree and Properties | Windows Vista | This test tool verifies that all WIA properties for Vista style drivers are implemented according to WDK and Windows Vista Logo requirements. It also verifies the correct structure of WIA Items tree built by Vista style scanner driver. It will help driver developers to detect properties and item tree implementation errors.
Twain Tester | Windows Vista | This is a GUI test wizard to test driver’s TWAIN compliance.
WIA Data Transfer Tool | Windows Vista | The WIA Data Transfer tool is an automated Windows Driver Kit (WDK) tool for testing behavior of WIA minidrivers related to data transfer. This tool verifies that a driver does not cause applications or the WIA service to crash or hang in edge conditions during data transfer. It also verifies that the correct behavior is implemented by the driver in different configurations, sequences of actions, and errors that may occur during transfer. This tool ensures that there is no ambiguity in driver's behavior in these scenarios and hence guarantees compatibility between all WIA drivers and WIA applications.
Imaging BVTs | Windows Vista | This tool includes imaging build verification tests (BVTs).
WIA Filters Test | Windows Vista | It helps WIA driver developers to implement their WIA filters in accordance with Windows Driver Kit (WDK) and Windows Logo requirements.
Scanner WinColor Test | Windows Vista | This test validates that a scanner conforms to the Windows Color Compliancy requirements for scanners. For more information about the Windows Color Compliancy requirements, please refer to http://www.microsoft.com/whdc/device/display/color/ColorTest.mspx .


WIA Tester

Type: Automated Test

Overview

This test tool verifies that all WIA properties for pre-Vista style drivers are implemented according to WDK and Windows Vista Logo requirements. It also verifies the correct structure of WIA Items tree built by pre Vista scanner driver.
It will help driver developers to detect properties and item tree implementation errors.

Details

This tool uses information stored in an XML file and test scripts to verify correct implementation of WIA Properties. Each WIA property defined in Windows SDK and WDK documentation has the following attributes: data type, access type, items where required, items where optional, legal values (list or range), and dependencies on other properties. The tool consists of a test application, an XML file listing all properties, and one test script per property. The test application allows a tested property or set of properties to be specified through command line parameters, reads property test script(s) and XML data, and compares the results to the property implementation in a WIA Driver. The test fails if the expected property attributes and implemented property attributes do not match. The test succeeds if all tested properties are implemented according to WDK requirements.
Tool components:
Console test application WIATester.exe - supports multiple command line parameters, outputs test info to WTT log file, console and custom log window (optional).
GUI application WiaTestGui.exe - collects test parameters through UI and runs WiaTreeProperties.exe to do the actual testing.
WiaTestLog.exe - custom log window, may be used for displaying test output. See -w command switch.
WiaPropDB.dll - managed assembly for reading WIA Properties XML database stored in WiaTreeProp.xml file
*.wis files - test suites (groups of test scripts)
*.wia files - test scripts, used by WIATester.exe application

Run Time: 20 mins
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running WIA Tester

Command Syntax

Command option | Description
-r <TestSuiteOrScript> | Which test script or suite to run.Required parameter.
-D <WiaDeviceID> | Which device to test. Default: First WIA device with Windows Vista compatible driver.
-q, -v, -debug | Log details level - quiet, verbose, debug. Default: quiet.
-I <TestRuns> | How many times to run each test. Default: 1.
-p | Prompt user between test iterations.
-w | Display custom log window
-R <Folder> | Specify which folder to use for images acquired during test. Default: Images
-x <XmlFileName> | Which XML file contains WIA Properties database. Default: WiaTreeProp.xml

Cautions

Do not install or uninstall imaging devices during test. Do not run any imaging applications during test execution

Code Tour

File Manifest

File | Location
scripts folder (recursively) | %controller%\tests\<arch>\nttest\PrintScanTest\WIA\LDK\wiatester\scripts
All WIS, WSF, XSD, XML files | %sdxroot%\testsrc\printscantestdata\REDIST\wia\ldk\WiaTester\
All EXE, DLL files | %sdxroot%\testsrc\printscantestdata\REDIST\wia\ldk\WiaTester\

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WIA Error Handler Tool

Type: Automated Test

Overview

This is an automated Windows Driver Kit (WDK) tool for testing behavior of WIA minidrivers related to error handler.
This tool verifies that a driver does not cause applications or the WIA service to crash or hang in edge conditions when the driver sends a message to an error handler or receives a message in its error handler. It also guarantees a consistent and quality experience for the user (Windows come and go when expected, and the driver handles messages from error handlers appropriately by canceling transfers, etc).

Details

This test runs either from the WDK or standalone from the command line. It logs results to the console and to a WTT log file, and can be configured to log at two different levels of verbosity. This test runs all test cases by default. However, individual test cases can be specified as well. The test requires the device ID of the WIA device that is being tested to be specified.
Run Time: 30 min
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements

    • Processor

  • x86
  • x64

Running WIA Error Handler Tool

Install WIA device to be tested.
Register WiaTestLog.dll using RegSvr32.
Run WiaErrorHandlerTool.

Command Syntax

Command option | Description
WiaErrorHandlerTool.exe |
[/help] | Optional; List available command-line options.
[/log:<logfilename>] | Optional; Default is "ErrorHandler.wtl".
[verboselog:<0 or 1>] | Optional: Specifies whether to log with maximum verbosity. Default is "1".
/device:<deviceID of device> | Required: Four digit device ID of WIA device that is being tested.
[/case:<case number>] | Optional, for debugging purposes: Run only specified test case. Test will not log a pass unless all tests are run.

Cautions

This tool performs error handler tests during data transfers. Therefore, data transfers must work correctly for this test to pass. Errors related to data transfer will be logged in the same format as by the Data Transfer WDK tool.

Troubleshooting

Use with command-line option /verboselog:1. Detailed logging goes into WTT log file.

Code Tour

File Manifest

File | Location
WiaErrorHandlerTool.exe | %controller%\tests\<arch>\nttest\PrintScanTest\WIA\WiaErrorHandlerTool
WiaTestLog.dll | %controller%\tests\<arch>\nttest\PrintScanTest\WIA\WiaErrorHandlerTool

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WIA Tree and Properties

Type: Automated Test

Overview

This test tool verifies that all WIA properties for Vista style drivers are implemented according to WDK and Windows Vista Logo requirements. It also verifies the correct structure of WIA Items tree built by Vista style scanner driver.
It will help driver developers to detect properties and item tree implementation errors.

Details

This tool uses information stored in an XML file and test scripts to verify correct implementation of WIA Properties. Each WIA property defined in Windows SDK and WDK documentation has the following attributes: data type, access type, items where required, items where optional, legal values (list or range), and dependencies on other properties. The tool consists of a test application, an XML file listing all properties, and one test script per property. The test application allows a tested property or set of properties to be specified through command line parameters, reads property test script(s) and XML data, and compares the results to the property implementation in a WIA Driver. The test fails if the expected property attributes and implemented property attributes do not match. The test succeeds if all tested properties are implemented according to WDK requirements.
Tool components:
Console test application WiaTreeProperties.exe - supports multiple command line parameters, outputs test info to WTT log file, console and custom log window (optional).
GUI application WiaTreePropertiesGUI.exe - collects test parameters through UI and runs WiaTreeProperties.exe to do the actual testing.
WiaTestLog.exe - custom log window, may be used for displaying test output. See -w command switch.
WiaPropDB.dll - managed assembly for reading WIA Properties XML database stored in WiaTreeProp.xml file
*.wis files - test suites (groups of test scripts)
*.wia files - test scripts, used by WiaTreeProperties.exe application

Run Time: 20 min
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements

    • Processor

  • x86
  • x64
  • Hard drive with min 20GB on current partition (where test files will be installed)

Running WIA Tree and Properties

Steps for testing Vista-compatible WIA Minidrivers:
1) Install scanner with Vista-compatible WIA driver. Turn it on and load all scanning units with enough documents.
2) Open a console window and navigate to a local folder where tool files are installed.
3) Run "cscript.exe RegAssembly.wsf WiaPropDB.dll" - this needs to be done only once.
4) Run the application by one of these methods:
a) Run WiaTreeProperties.exe. Device ID may be specified with -D option. If skipped the first installed device will be used. See test documentation for other possible arguments.
b) Alternatively, Run WiaTreePropertiesGUI.exe. A dialog will provide a dropdown list control for selecting WIA device and other configuration options. Use the "Start" button to run the test when ready.
5) The test logs results and runtime information to the WiaTestLog window (or the console if WiaTreeProperties.exe is used) and to the WTT log file (.wtl) in the tool's directory. The console can be used for test output too. At the end of log test a summary is displayed.

Command Syntax

Command option | Description
NOTE: All command line argument below are for WiaTreeProperties.exe test. |
-r <TestSuiteOrScript> | Which test script or suite to run.Required parameter.
-D <WiaDeviceID> | Which device to test. Default: First WIA device with Windows Vista compatible driver.
-q, -v, -debug | Log details level - quiet, verbose, debug. Default: quiet.
-I <TestRuns> | How many times to run each test. Default: 1.
-p | Prompt user between test iterations.
-w | Display custom log window
-R <Folder> | Specify which folder to use for images acquired during test. Default: Images
-x <XmlFileName> | Which XML file contains WIA Properties database. Default: WiaTreeProp.xml

Cautions

Do not install or uninstall imaging devices during test. Do not run any imaging applications during test execution.

Troubleshooting

If failure is reported somewhere in the middle of a huge log file, try to determine which test script caused it. Then run this script only. For example:
WiaTreeProperties.exe -r scripts\DPA\DPA_DEVICE_TIME.wia -debug -w
If test crashes, try running WiaTreeProperties.exe from console under debugger to determine crash reason.
WiaTreePropTest.htm lists supported command-line options, examples, known issues, and FAQs.

Reference Documentation

TBD

Code Tour

File Manifest

File | Location
All WIS, WSF, XSD, XML files | %controller%\tests\<arch>\nttest\PrintScanTest\WIA\WiaTreeProp\scripts
All EXE, DLL files | %controller%\tests\<arch>\nttest\PrintScanTest\WIA\WiaTreeProp

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Twain Tester

Type: Automated Test

Overview

This is a GUI test wizard to test driver’s TWAIN compliance.

Details

This is a basic TWAIN compliance tool and it will load the data source, tests all the required capabilities for a source, all available pixel types and data transfer mechanisms of the source.
Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running Twain Tester

To run the compliance test, use the File | Select source option to select the source to test, Tools| Source Settings to configure logging level and log location. Go to Test Wizard | Launch Test Wizard to open the test wizard, select and run all the test cases. Results will be shown in the final summary page as well as in the specified log file.

Command Syntax

Command option | Description
-auto | Optional; For running automated tests
-name:<Friendly name> | Optional; to test the specified device

Code Tour

File Manifest

File | Location
TwainTester.exe | %controller%\x86\nttest\PrintScanTest\WIA\TwainTest
ntlog.dll |
wttlog.dll |

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WIA Data Transfer Tool

Type: Automated Test

Overview

The WIA Data Transfer tool is an automated Windows Driver Kit (WDK) tool for testing behavior of WIA minidrivers related to data transfer.
This tool verifies that a driver does not cause applications or the WIA service to crash or hang in edge conditions during data transfer. It also verifies that the correct behavior is implemented by the driver in different configurations, sequences of actions, and errors that may occur during transfer. This tool ensures that there is no ambiguity in driver's behavior in these scenarios and hence guarantees compatibility between all WIA drivers and WIA applications.

Details

The WIA Data Transfer tool runs either from the WDK or standalone from the command line. It logs results to the console and to a WTT log file, and can be configured to log at two different levels of verbosity. By default, it runs all test cases but individual test cases can be specified as well.
Run Time:
Log File: DataTransfer.wtl
System Restart Required:
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements

    • Processor

  • x86
  • x64

Running WIA Data Transfer Tool

  1. Install WIA device to be tested.
  2. Register WiaTestLog.dll using RegSvr32.
  3. Run WiaTransferTool.

Command Syntax

Command option | Description
WiaTransferTool.exe |
[/help] | Optional; List available command-line options.
[/log:<logfilename>] | Optional; Default is "DataTransfer.wtl".
[verboselog:<0 or 1>] | Optional; Specifies the level of verbosity. Default is "1".
/device:<deviceID of device 1> | Required; Four-digit device ID of WIA device to test.
[/device2:<deviceID of device 2>] | Optional; Run all test cases, including those requiring two devices. Test will not log a pass unless all tests are run.
[/case:<case number>] | Optional, for debugging purposes; Run only specified test case. Test will not log a pass unless all tests are run.

Troubleshooting

Use with command-line option /verboselog:1. Detailed logging goes into WTT log file.

Code Tour

File Manifest

File | Location
WiaTransferTool.exe | %controller%\tests\<arch>\nttest\PrintScanTest\WIA\WiaTransferTool
wiatestlog.dll | %controller%\tests\<arch>\nttest\PrintScanTest\WIA\WiaTransferTool

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Imaging BVTs

Overview

This tool includes imaging build verification tests (BVTs).

Details

These BVTs will test the effects and hit testing functionality of the Imaging System.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • Video card configurations that at least match the Microsoft Windows Vista minimum requirements or recommended configuration requirements.

Running Imaging BVTs

Schedule the Windows Driver Kit (WDK) jobs to run the tests.

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WIA Filters Test

Overview

It helps WIA driver developers to implement their WIA filters in accordance with Windows Driver Kit (WDK) and Windows Logo requirements.

Details

Test consists of a single executable, which uses wttlog.dll to write test results to the console and to a WTT log file (WiaFilters.wtl) in the current directory. Command-line parameters can be used to specify the device under test, to log output details, and do error handling - all parameters are optional. If a device ID is not specified at the command line, the first installed WIA device with a Windows Vista-compatible driver will be selected for testing.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements

    • Processor

  • x86
  • x64
  • Al least 20 GB disk space available on current partition.

Running WIA Filters Test

  1. Install Windows Vista and wttlog.dll in DLL search path.
  2. Install scanner and its Windows Vista-compatible WIA driver. Scanner should be ready for scanning - paper loaded in ADF unit, film/transparency adapter ready, and so on.
  3. Copy WiaFilters.exe to a local folder.
  4. Run WiaFilters.exe and look at console output and generated WiaFilters.wtl file for test results.

Command Syntax

Command option | Description
-D:<DeviceID> | for example "{6BDD1FC6-810F-11D0-BEC7-08002BE2092F}\0001". If missing, first scanner device found will be tested.
-R:<FolderPath> | Folder for the acquired images. The path should be relative to current directory. Defaults to WiaFiltersTemp.
-v:<LogDetails> | Log detail level: quiet, verbose, or debug. Defaults to quiet.
-e:<ErrorHandling> | C++ and SEH exception handling: none, filter, all. Defaults to filter (only exceptions from WIA filters are handled and logged).
-name:<deviceName> | Name of the device to be tested, either DeviceID or Devicename has to be given

Cautions

Do not run any other scanning applications while you are running the test. Do not install/uninstall imaging devices.

Troubleshooting

Recommendation: test when only the device under test is installed on test machine.
Use debug logging (-v:debug) if quiet logging output does not provide enough information.
Run test under debugger and trace calls into filters code.

Reference Documentation

TBD

Code Tour

File Manifest

File | Location
WiaFilters.exe | %controller%\tests\<arch>\nttest\PrintScanTest\WIA\wiafilters

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Scanner WinColor Test

Type: Automated Test

Overview

This test validates that a scanner conforms to the Windows Color Compliancy requirements for scanners. For more information about the Windows Color Compliancy requirements, please refer to http://www.microsoft.com/whdc/device/display/color/ColorTest.mspx .

Details

The test scans a color target. The scanned target is compared against the expected colors of the standard. The differences are then averaged and square root summed. If the average or square root sum is greater than the Windows Color Compliancy requirements allow, a failure is reported. For more information of the methods used and the calculations, please refer to http://www.microsoft.com/whdc/device/display/color/ColorTest.mspx .
Run Time: 2 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running Scanner WinColor Test

Command Syntax

Command option | Description

Troubleshooting
http://www.microsoft.com/whdc/device/display/color/ColorTest.mspx

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Input Testing

This section describes how to test storage devices and controllers in order to qualify them for the "Designed for Windows" logo.

Input > Media Center Edition Remote Control

Input > Smartcard Reader


Media Center Remote Control Testing Overview

The procedures presented in this section outline the process for testing your Media Center Remote Control Logo Test for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as requried for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

Using the Test Procedure Help Topics

The test procedures are divided into the following types of topics:

Overview: The overview topics describe the hardware, software, and tester knowledge requirements.

Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.

Running: The running topics describe how to run to run the tests for your device or system.

Media Center Remote Control Logo Program Certification

The Media Center Remote Control Logo Program Certification requires IHVs to first contact Microsoft for remote control button usage and layout design approval prior to running the MCE Remote Control Certification Tool to verify button functionality. See step1 of the “Running the Remote Control Logo Program Certification Test” below for more details.

The list of test you need to run depend upon the capabilities of the device or system being tested. To see the complete list of tests that could be required for your device, see the MCE Remote Control Certification Tool.

Run time: approximately 15 minutes

Hardware requirements

The following hardware is required for Media Center Remote Control Logo Test. Additional hardware may be required if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • Remote control being certified
  • Any supported MCE IR Receiver
  • Client machine running Vista and the WLP/DTM client

Software requirements

The following software is required to run the Media Center Remote Control Logo Test:

  • WLP/DTM client

The Remote Control Certification Tool program may be run standalone to test the buttons. Running the program in this mode will not be applicable to WLP. See the MCE Remote Control Certification Tool for more details.

Tester knowledge requirements

To run the Media Center Remote Control Logo Program Certification program, testers must be able to:

  • Install and run the WLP DTM
  • Install an IR receiver on a client machine
  • Have access to the client machine
  • Press remote control buttons as requested in the prompt


Preparing for Media Center Remote Control Testing

Before attempt to logo a Media Center remote control through WLP, please contact Microsoft as prescribed in step 1 below. (The test may be without this step, but you will not be able to logo the remote.)

Before running the tests, configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see the MCE Remote Control Certification Tool.

Test system configuration

  • Connect an approved Media Center IR receiver to the client machine.


Running the Media Center Remote Control Tests

  1. Remote Control Design Verification
    1. 1.Download and fill out InfoPath form. Contact remotemc@microsoft.com >
    2. Once the form is filled out, send it to remotemc@microsoft.com
    3. After the MCE Remote Control team verifies and approves the information submitted, an approval will be sent back.
    4. Save this file in a known location. (This returned form will be digitally signed by Microsoft, and the signature will be used verify authorization in step 2-4 below.)

  2. Remote Control Button Verification
    1. Receiver should be plugged into the client machine.
    2. Launch Remote Control Self-Certification Tool
    3. Two options will be available:
      1. Self-Test Tool: Verifies button functionality without submitting the result for logo certification
      2. Self-Certification Tool: testing of button functionality will be performed as well as additional information about the remote control being verified. The results of the test along with the additional information will be submitted to Microsoft for final certification approval.
      Select the Self-Certification Tool.
    4. Fill in the information on the next form regarding the type of remote control being tested and where the remote control will be released.

      Note: the approval received in step 1-3 above will need to be included at this point.

    5. The remainder of the tool is in wizard format which will walk through verification of the signal and then verification of each button functionality.

      The “Press the following button on your remote control” field, display the name of a button from the buttons-to-test list. Press the corresponding button on the remote control. The result will be captured and displayed on the screen.

      Cancel: take the user back to the main menu
      Previous: take the user to the previous page
      Next: if the buttons-to-test list is not empty, bring up the Testing Not Complete dialogue box. Within this dialogue, if OK is selected, take the user to the next page, log the fact that not all buttons passed certification and log the names of the delinquent buttons. Otherwise, remain on the current page.
      Skip: Skips the current button in the buttons-to-test list and prompts the user for the next one. This button would be used for example if a particular button did not pass and the user would like to proceed with verification of the remaining buttons. This action will be captured in the log file.
    6. Once all buttons have been verified, a profile screen will be presented where additional company information can be entered.
    7. The final step is for the user to submit the results of the test to Microsoft. The log file must be sent in order for the rest of the certification process to occur. There is an option to view the log file viewed prior to submitting it.
    8. Once the log file is submitted, then clicking on Finish will exit the program.


Troubleshooting Media Center Remote Control Testing

The program used to test the remote control may be run separately outside the logo process to isolate any problems with the remote control prior to submitting the logo request. Information on this may be found in the MCE Remote Control Certification Tool.


Smartcard Reader Testing Overview

The procedures presented in this section outline the process for testing your Smartcard Reader for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as requried for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

Using the Test Procedure Help Topics

The test procedures are divided into the following types of topics:

Overview: The overview topics describe the hardware, software, and tester knowledge requirements.

Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.

Running: The running topics describe how to run to run the tests for your device or system.

Smartcard Reader Tests

The list of tests you need to run depends upon the capabilities of the device or system being tested. The following is the complete list of tests that could be required for your test device:

Card Reader Test

Device Path Exerciser

System - Sleep Stress with IO

Disable Enable with IO

Plug and Play Driver Test

Stress Test

Core Stress Test

If you are submitting a driver:

DR - Driver Verifier

DR - Prefast for Drivers Test

DR - Static Driver Verifier Test

Run Inf Test against a single INF

If your device is connected via 1394:

1394 Configuration Tests

If your device is connected via Cardbus:

CardBus Card Configuration Space Register

CardBus Card Common Silicon Guidelines

CardBus Bridge Power Management Register

If your device is connected via PCI:

Vista:
PCI Compliance Test (LOGO)

Windows XP & Windows Server 2003:
PCI Compliance Test 2.1 (LOGO)

If your device is connected via USB:

USB Address Description

USB Descriptor Test

USB Device Control Requests

USB Device Framework (CV)

USB Enumeration Stress

USB HIDView (CV)

USB Selective Suspend

USB Serial Number

USB Specification Compliance

Run time: approximately 3-4 hours

Hardware requirements

The following hardware is required for Smartcard Reader testing. Additional hardware may be required if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One test device
    If the device supports Universal Serial Bus (USB), two test devices are needed to run the USB Serial Number test.
  • One Personal Computer / Smart Card (PC/SC) workgroup test card set for the Windows Logo Program for Hardware
    This card set can be purchased from the PC/SC web site. Test your product with the smart cards included in the PC/SC workgroup test card set. Do not include these smart cards with your test submission.

    Note: United States Customs duty charges might be applied to your order.

  • One computer with the following:
    Minimum requirements published for the test OS
    CD-ROM drive
    ACPI BIOS that complies with the Windows Logo Program for Hardware requirements, with ACPI mode enabled by default
    One monitor, one keyboard, and one mouse (or any pointing/drawing device)

    Important: The test system must be included in the Windows Catalog.

  • One USB 2.0 high-speed hub if device is connected via USB.

Software requirements

The following software is required to run the Smartcard Reader tests:

  • One of the following operating systems
    Microsoft Windows Vista
    Microsoft Windows XP Professional with Service Pack 2 (SP2)
    Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
    Microsoft Windows Server 2003, Datacenter Edition, with SP1
    Microsoft Windows Server XP Professional x64 Edition
    Microsoft Windows Server 2003, Enterprise x64 Edition
    Microsoft Windows Server 2003, Datacenter x64 Edition
    Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
    Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems
  • Any drivers that are not shipped with the operating system
  • The current release of Microsoft WDK

Tester knowledge requirements

To run the Smartcard Reader tests, testers must know how to accomplish the following tasks:

  • Install the operating system from the product CD.
  • Install and operate the test device.
  • Install the manufacturer-supplied device driver, if necessary.
  • Install DTM Client.
  • Launch tests from DTM Studio’s Device Console (Submission mode).


Preparing for Smartcard Reader Testing

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see the Smartcard Reader Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, see .

Test system configuration

  1. Install the appropriate Microsoft Windows operating system.
  2. Install the test device and any accessories.
    If the test device is connected via USB:
    Connect the USB 2.0 controller to the High Speed USB 2.0 hub.
    Connect the test device to the downstream port of the high-speed USB 2.0 hub.

    Note: Do not connect the USB test device directly to the root hub of the USB 2.0 controller.

  3. Install the device driver that is supplied by the manufacturer, if necessary.
  4. Install DTM Client.
  5. Configure the machine for testing in DTM Studio.
    Add the machine to a machine pool.
    Deploy the “WDK\ConfigureSmartcardReader” dimension.


Running the Smartcard Reader Tests

Open Device Console in DTM Studio.

Create a new submission for “Input > Smartcard Reader”.

During the submission make sure to load the same driver you installed on the system in step 3 of Test system configuration.

If you are not loading a driver, make sure to select your card reader under the Smartcard Readers node in the device list.

Select the tests which you wish to launch, choose Add Selected, and then click schedule.

Important: IFDTest2 requires manual user intervention. Please schedule this test alone and proceed to the test console after scheduling.

IFDTest2

Inputs:

This test takes no command-line input. This test requires the use of the PC/SC workgroup test card set.

Setup:

This test requires no change to the standard setup. The test itself will stop the Smartcard service while it is running.

Precaution:

If you have more than one card reader connected to the system, be sure to select the same reader that you associated with the submission when running the test.

The power management test cases in Part D require that the user manually hibernate the system and remove and/or reinsert any smart card in the test smart card reader. For this test it may shorten the test time to turn off password prompting when returning from hibernation:

Windows Vista

  • Open Power Options in Control Panel.
  • Click “Require Password on wakeup” in the left details panel.
  • Select “Don’t require a password on wakeup”.

Windows XP / Server 2003

  • Open Power Options in Control Panel.
  • In the Advanced tab, uncheck “Prompt for password when computer resumes from standby.”

More Info:

DR - Device Path Exerciser

More Info:

DR - Sleep Stress with IO

More Info:

DR - Disable Enable with IO

More Info:

DR - Plug and Play Driver Test

More Info:

DR - Stress Test

More Info:

DR - Stress Test with low resource simulation

More Info:

DR - Sleep Stress Disable Enable with IO

More Info:

DR - Driver Verifier

Note: This test will only appear if you load a driver.

More Info:

DR - Prefast for Drivers Test

Note: This test will only appear if you load a driver.

More Info:

DR - Static Driver Verifier Test

Note: This test will only appear if you load a driver.

More Info:

Run Inf Test against a single INF

Note: This test will only appear if you load a driver.

More Info:

1394 Configuration Tests

Note: This test will only appear if your device is connected via 1394.

More Info:

CardBus Card Configuration Space Register

Note: This test will only appear if your device is connected via CardBus.

Precaution: Please remove all other CardBus cards before running this test.

More Info:

CardBus Card Common Silicon Guidelines

Note: This test will only appear if your device is connected via CardBus.

Precaution: Please remove all other CardBus cards before running this test.

More Info:

CardBus Bridge Power Management Register

Note: This test will only appear if your device is connected via CardBus.

Precaution: Please remove all other CardBus cards before running this test.

More Info:

PCI Compliance Test

Note: This test will only appear if your device is connected via PCI and the test machine is running Windows Vista.

More Info:

PCI Compliance Test 2.1

Note: This test will only appear if your device is connected via PCI and the test machine is running Windows XP or Windows Server 2003.

More Info:

USB Address Description

Note: This test will only appear if your device is connected via USB.

More Info:

USB Descriptor Test

Note: This test will only appear if your device is connected via USB.

More Info:

USB Device Control Requests

Note: This test will only appear if your device is connected via USB.

More Info:

USB Device Framework (CV)

Note: This test will only appear if your device is connected via USB.

More Info:

USB Enumeration Stress

Note: This test will only appear if your device is connected via USB.

More Info:

USB HIDView (CV)

Note: This test will only appear if your device is connected via USB.

More Info:

USB Selective Suspend

Note: This test will only appear if your device is connected via USB.

More Info:

USB Serial Number

Note: This test will only appear if your device is connected via USB.

More Info:

USB Specification Compliance

Note: This test will only appear if your device is connected via USB.

More Info:


Troubleshooting Smartcard Reader Testing

  • Before you create a submission make sure your client is in Ready () Mode. If it is not, right click the machine and choose Change Status > Reset.
  • If you plug in your device and it does not appear in DTM Studio try clicking the refresh button in Device Console before creating a submission. If the device still does not appear, try restarting the client machine.
  • If jobs are not getting your devices parameters check the following:
    • Right click on the job in Job Monitor’s Job Execution Status pane.
    • Choose View Result Report.
    • Check the Effective Parameters section at the bottom of the report.
    • If the parameters are incorrect you may have associated the wrong device with the submission, the device may be installed incorrectly, or the installed driver may be wrong.
    • If this is empty your submission may be invalid.
    • Create a new submission and launch the test again.
    • If the parameters are still empty your client installation may be corrupt.
    • Delete the machine from the machine pool, uninstall the client then repeat steps 8 & 9 of Test System Configuration.

  • If jobs are appearing incorrectly.
    • Please ensure that you have done step 9 of Test System Configuration.


Smart Card Tests

Test name | Target operating system | Test description
CardBus Bridge Power Management Register Test | Windows Vista Windows XP | The CardBus Bridge Power Management Register test searches the CardBus Bridge/Card configuration space for each of the CardBus device functions and verifies that the power management registers are correctly implemented.
CardBus Card Configuration Space Register test | Windows Vista Windows XP | This test determines the correct implementation of the CardBus card’s configuration space support registers.
Card Reader Test | Windows Vista Windows XP | The Card Reader test verifies the functionality of the smart card reader by validating the PC/SC workgroup test cards.
CardBus Card Common Silicon Guidelines test | Windows Vista Windows XP | This test determines whether the CardBus card’s configuration space supports the Common Silicon Guidelines as described in PC Card Standard Guidelines, Volume 10.


Card Reader Test

Type: Automated Test

Overview

The Card Reader test verifies the functionality of the smart card reader by validating the PC/SC workgroup test cards.

Details

This test verifies the functionality of the smart card reader by validating the revision two of the PC/SC workgroup test cards. The test requires one PC/SC workgroup test card-set for the “Designed for Microsoft Windows” Logo Program. You can purchase this card-set from the PC/SC Workgroup Web site. Two card-sets exist: card set 1 and 2. Card-set 1 is tested by the Ifdtest.exe binary, whereas card-set 2 is tested with Ifdtest2.exe. Card set 1 has been discontinued; as such, it will not be required for the “Designed for Microsoft Windows” Logo Program.
The test suite and its hardware must be able to execute specific IFD tests and produce a test report. Specific requirements deal with nominal operation and exceptional operation (error conditions). In addition, these must be applied to all protocols supported by the reader subsystem.
IFDTEST performs three basic types of tests: Reader Interface tests are performed without anything inserted in the reader. Resource Manager Status tests are performed as a sample card is inserted into and removed from the reader, and are concerned with handling of card insertion detection under various conditions (any card can be used for this test). These two classes are unchanged with new card-set.
Card Protocol tests involve operation both with inserted representative commonly available smart cards and with special cards that exhibit certain specially programmed behaviors. The tests using commonly available cards will perform routine operations on cards selected to represent a variety of communication speed and protocol combinations. These tests have changed with the new card-set.
Resource Manager Status tests
Part A
The card monitor tests check for proper detection of smart card insertion state and proper handling of operations interrupted by the unexpected removal of the card.
  1. Test detection of empty readers using IOCTL_SMARTCARD_IS_PRESENT
  2. Test detection of inserted card using IOCTL_SMARTCARD_IS_PRESENT
  3. Test removal of inserted card using IOCTL_SMARTCARD_IS_ABSENT
  4. Test correct handling of randomly timed card insert and remove actions for 15 seconds
  • Verify that IOCTL_SMARTCARD_IS_PRESENT and IOCTL_SMARTCARD_IS_ABSENT produce valid results
Part C
The resource manager tests test successful completion of state change operations normally expected to be commanded by the smart card resource manager.
  1. Verify IOCTL_SMARTCARD_GET_STATE succeeds with no card
  2. Verify returned state is valid
  3. Verify correct return from IOCTL_SMARTCARD_IS_PRESENT
  4. Verify correct return from IOCTL_SMARTCARD_IS_ABSENT
  5. Operator inserts a card
  6. Verify IOCTL_SMARTCARD_GET_STATE succeeds with card inserted
  7. Verify returned state is valid
  8. Verify correct return from IOCTL_SMARTCARD_IS_ABSENT
  9. Cold reset the card
  10. Verify card state is SCARD_NEGOTIABLE
  11. Set Card Protocol to T0 or T1
  12. Verify card state is CARD_SPECIFIC
  13. Verify success of IOCTL_SMARTCARD_POWER to power down the card
  14. Operator removes the card
  15. Verify IOCTL_SMARTCARD_GET_STATE succeeds with no card
Part E
The power management tests verify that the driver returns the correct state information for the reader across hibernation sequences, even when the state of the reader is changed during hibernation by insertion or removal of a card.
  1. Operator removes all cards
  2. Operator hibernates computer
  3. Operator starts computer
  4. Verify reader state SCARD_ABSENT on return from hibernate
  5. Operator Inserts card
  6. Operator hibernates computer
  7. Operator starts computer
  8. Verify reader state SCARD_PRESENT on return from hibernate
  9. Operator removes card
  10. Operator hibernates computer
  11. Operator removes card during hibernate
  12. Operator starts computer
  13. Verify reader state SCARD_ABSENT on return from hibernate
  14. Operator hibernates computer
  15. Operator inserts card during hibernate
  16. Operator starts computer
  17. Verify reader state SCARD_PRESENT on return from hibernate
Reader Interface tests
Part B
Reader interface tests check for the proper implementation property and state information at the reader driver.
  1. Check attributes reported by the reader with a sample card inserted
  2. Test that device name reported by the driver is WDM PnP compliant
  3. Test that driver correctly handles attribute read requests with NULL return buffer
  4. Test that driver correctly terminates pending i/o requests if the driver is closed and reopened with an i/o operation pending
  5. Test read attributes with no card inserted
    1. SCARD_ATTR_VENDOR_NAME : non-zero length string
    2. SCARD_ATTR_VENDOR_IFD_TYPE : non-zero length string
    3. SCARD_ATTR_DEVICE_UNIT : a 4 byte or greater length value
    4. SCARD_ATTR_ATR_STRING : read attempt fails
    5. SCARD_ATTR_DEFAULT_CLK : 1000 <= value <= 20000
    6. SCARD_ATTR_MAX_CLK : 1000 <= value <= 20000
    7. SCARD_ATTR_DEFAULT_DATA_RATE : read attempt succeeds
    8. SCARD_ATTR_MAX_DATA_RATE : read attempt succeeds
    9. SCARD_ATTR_MAX_IFSD : 1 <= value <= 254
    10. SCARD_ATTR_CURRENT_PROTOCOL_TYPE : read attempt fails
  6. Test read attributes with a card inserted
    1. SCARD_ATTR_VENDOR_NAME : non-zero length string
    2. SCARD_ATTR_VENDOR_IFD_TYPE : non-zero length string
    3. SCARD_ATTR_DEVICE_UNIT : a 4 byte or greater length value
    4. SCARD_ATTR_ATR_STRING : read attempt succeeds
    5. SCARD_ATTR_DEFAULT_CLK : value 1000 <= value <= 20000
    6. SCARD_ATTR_MAX_CLK : value 1000 <= value <= 20000
    7. SCARD_ATTR_DEFAULT_DATA_RATE : read attempt succeeds
    8. SCARD_ATTR_MAX_DATA_RATE : read attempt succeeds
    9. SCARD_ATTR_MAX_IFSD : 1 <= value <= 254
    10. SCARD_ATTR_CURRENT_PROTOCOL_TYPE : value = 0
  7. Read card state with card removed using IOCTL_SMARTCARD_GET_STATE : state <= SCARD_SWALLOWED
  8. Reset card : verify result is ERROR_UNRECOGNIZED_MEDIA
Card Protocol Tests
Part D
Infineon Technologies PC/SC Compliance Test Card (Card 0 / Unlabeled)
ATR: 3B EF 00 00 81 31 20 49

00 5C 50 43 54 10 27 F8

D2 76 00 00 38 33 00 4D
    1. Attempt read with buffer too small
    2. Waiting time extension request – route request figure to file 0001, read back and verify
    3. Block chaining resync test on file 0002: card accepts 1st block, then repeatedly requests retransmission of block 2; host resyncs – expect ERROR_IO_DEVICE
    4. Block chaining resync test on file 0002: card repeatedly declares EDC error on block 2; host resyncs – expect ERROR_IO_DEVICE
    5. Wrong block sequence by read to file 0003 – expect ERROR_IO_DEVICE
    6. Ifsc request file id 0004
    7. Force timeout by read to file 0005 – expect ERROR_IO_DEVICE
    8. Read and process result file (A000), parse and report errors
Athena T0 Test Card (Card 1)
ATR: 3B D6 18 00 80 B1 80 6D

1F 03 80 51 00 61 10 30

9E
    1. Reset with long (approx 900 mSec) ATR transmission time
    2. Set Protocol to T0, expect success
    3. Erase all card files by proprietary command, expect success
    4. Create test file 0002, expect success
    5. Select test file 0002, expect success
    6. Write 256 bytes as 4 blocks of 64 bytes, expect success
    7. Read and verify 256 bytes as 4 blocks of 64 bytes, expect success
    8. Write 255 bytes as a single block, expect success. The card will receive the bytes in single-byte mode until 8 bytes remain, at which point the rest of the data will be requested from the host as a single block, expect success
    9. Set receive buffer to 9 bytes and attempt to receive 10 bytes response from card, expect ERROR_INSUFFICIENT BUFFER
    10. Send malformed (Lc inconsistent with data length) select command 00 a4 00 00 08 00, expect ERROR_INVALID_PARAMETER
    11. Select nonexistent file, expect 6A 82
    12. Send command to silence the card (80 00 01 00 01 11), expect ERROR_SEM_TIMEOUT
    13. Reset the card
    14. Send echo command to card to test request wait time extension for extension counts of 1, 2, 5, and 30 extensions, expect success
Athena\Inverse Convention Test Card (Card 2)
ATR: 3F 96 18 80 01 80 51 00

61 10 30 9F
    1. Reset with long (approx 900 mSec) ATR transmission time
    2. Set Protocol to T0, expect success
    3. Erase all card files by proprietary command, expect success
    4. Create test file 0002, expect success
    5. Select test file 0002, expect success
    6. Write 256 bytes as 4 blocks of 64 bytes, expect success
    7. Read and verify 256 bytes as 4 blocks of 64 bytes, expect success
    8. Write 255 bytes as a single block, expect success. The card will receive the bytes in single-byte mode until 128 bytes remain, at which point the rest of the data will be requested from the host as a single block, expect success
    9. Set receive buffer to 9 bytes and attempt to receive 10 bytes response from card, expect ERROR_INSUFFICIENT BUFFER
    10. Send malformed (Lc inconsistent with data length) select command 00 a4 00 00 08 00, expect ERROR_INVALID_PARAMETER
    11. Select nonexistent file, expect 6A 82
    12. Send command to silence the card (80 00 01 00 01 11), expect ERROR_SEM_TIMEOUT
    13. Reset the card
    14. Send echo command to card to test request wait time extension for extension counts of 1, 2, 5, and 30 extensions, expect success
Axalto 32K eGate Test Card (Card 3)
ATR: 3B 95 18 40 FF 62 01 02

01 04
    1. Attempt set protocol T=1, expect ERROR_NOT_SUPPORTED
    2. Set protocol T=0
    3. Authenticate using card transport key, expect success
    4. Clean card state by deleting files from previous runs (Remove RSA public and private key files, the user PIN file, and the test file), expect success
    5. Create new test file 0055, expect success
    6. Test write blocks 1, 25, 75, 128 bytes to test file, expect success
    7. Test read 128 bytes from test file, compare data, expect success
    8. Delete test file 0055, expect success
    9. Create PIN file, expect success
    10. Set user PIN to 00000000, expect success
    11. Create private key file, expect success
    12. Create public key file, expect success
    13. Select private key file, expect success
    14. Authenticate user with PIN, expect success
    15. Generate key pair, expect success
    16. Hash 16 bytes data, expect success
    17. Get response data to hash operation, 20 bytes + 2 bytes response, expect success
Infineon SiCrypt Card Module Test Card (Card 4)
ATR: 3B DF 18 00 81 31 FE 67

00 5C 49 43 4D D4 91 47

D2 76 00 00 38 33 00 58
    1. Attempt to set protocol T=0, expect ERROR_NOT_SUPPORTED
    2. Set protocol T=1, expect success
    3. Authenticate using PIN 12345678, expect success
    4. Remove files from previous runs if existing
    5. Create new test file 0007, expect success
    6. Select file 0007, expect success
    7. Record system time
    8. Write test blocks of 1, 25, 50, 75, 100, 125, 128 bytes to the card – Read and verify the data after each block write, expect success
    9. Get system time and show elapsed time in seconds for test completion
    10. Select file 0007, expect success
    11. Write 128 byte block of byte value 55, Read back and verify, expect success
    12. Write 128 byte block of byte value AA, Read back and verify, expect success
    13. Write 128 byte block of byte value 00, Read back and verify, expect success
    14. Write 128 byte block of byte value FF, Read back and verify, expect success
    15. Select nonexistent file 7777, expect 9404
    16. Select MF by 00 a4 00 00, expect 90 00 (success)
    17. Select invalid file 77, expect 94 04
    18. Send malformed (Lc inconsistent with data length) select command 00 a4 00 00 08 00, expect 94 04
    19. Send malformed (too short) select command by 00 a4 00, expect 67 00
    20. Create DF 5555 from the MF, expect success
    21. Select into 5555, expect success
    22. Create DF 5656 from 5555, expect success
    23. Select into 5656, expect success
    24. Create File 5757 in DF 5656, expect success
    25. Select that file from MF by full path, expect success
    26. Write 8 bytes to file, Read back and verify, expect success
    27. Delete the selected file, expect success
    28. Attempt to select that file by full path, expect 94 04
    29. Select and delete DF 5656, expect success
    30. Select and delete DF 5555, expect success
    31. Select and delete file 0007, expect success

Run Time: 20 minutes
Log File: IFDTest.wtl
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • PC/SC Workgroup test cards

Running Card Reader Test

Important For the power management test cases in Part D, the computer will hibernate and you may need to remove or reinsert a smart card in the test smart card reader.
Parts A, B, C, and E
Follow the instructions on the screen for Parts A, B, C, and E by using the cards from the PC/SC workgroup test card-set 2. When you are prompted, insert and then remove each smart card from the test smart card reader.
Part D
Follow the instructions on the screen for Part D to complete the four power management test cases. When you are prompted, insert or remove the smart card from the test smart card reader and hibernate or restart the test computer.
To run the Test 1 Card Out/Card Out test case

    1. Remove the smart card from the test smart card reader.
    2. The computer will automatically hibernate after 15 seconds.
    3. Allow the computer to hibernate for 30 to 60 seconds.
    4. Press the computer power button to bring the computer out of hibernation and continue the test.
    5. When you are prompted, reinsert the smart card in the test smart card reader.
To run the Test 2 Card In/Card Out test case

    1. Verify that the smart card is in the test smart card reader.
    2. The computer will automatically hibernate after 15 seconds.
    3. Allow the computer to hibernate for 30 to 60 seconds.
    4. Remove the smart card from the test smart card reader.
    5. Press the computer power button to bring the computer out of hibernation
    6. When you are prompted, reinsert the smart card in the test smart card reader before you start the next test case.
To run the Test 3 Card In/Card In test case

    1. Verify that the smart card is in the test smart card reader.
    2. The computer will automatically hibernate after 15 seconds.
    3. Allow the computer to hibernate for 30 to 60 seconds.
    4. Press the computer power button to bring the computer out of hibernation.
    5. When you are prompted, remove the smart card from the test smart card reader before you start the next test case.
To run the Test 4 Card Out/Card in test case
    1. Verify that there is no smart card in the test smart card reader.
    2. The computer will automatically hibernate after 15 seconds.
    3. Allow the computer to hibernate for 30 to 60 seconds.
    4. Reinsert the smart card in the test smart card reader.
    5. Press the computer power button to bring the computer out of hibernation. The smart card reader test is completed.
    6. View the test log files.
    7. Run all of the other required tests.
    8. After you successfully complete all of the tests that are required for this test submission, return the test results.

Command Syntax

Command option | Description
IFDTest2.exe | use /? for details

Cautions

Important For the power management test cases in Part D, the computer will hibernate and you may need to remove or reinsert a smart card in the test smart card reader.

Code Tour

File Manifest

File | Location
IFDTest.exe | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk
IDSTest2.exe | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk

Click to show or hide information. Test Assertions

Test Assertions

A.1 User must follow onscreen instructions
Test Assertion GUID: d58966e8-cb2e-11da-94f8-00123f3a6b60

A.2 Device should support IOCTL_SMARTCARD_IS_PRESET.
Test Assertion GUID: d58966e9-cb2e-11da-94f8-00123f3a6b60

A.3 User must follow onscreen instructions
Test Assertion GUID: d58966ea-cb2e-11da-94f8-00123f3a6b60

A.4 Device should support IOCTL_SMARTCARD_IS_ABSENT.
Test Assertion GUID: d58966eb-cb2e-11da-94f8-00123f3a6b60

A.5 User must follow onscreen instructions
Test Assertion GUID: d58966ec-cb2e-11da-94f8-00123f3a6b60

B.1 Device name and class should be WDM PNP compliant.
Test Assertion GUID: d58966ed-cb2e-11da-94f8-00123f3a6b60

B.2 IOCTL_SMARTCARD_GET_ATTRIBUTE should fail when called with a null output buffer.
Test Assertion GUID: d58966ee-cb2e-11da-94f8-00123f3a6b60

B.3 IOCTL_SMARTCARD_GET_ATTRIBUTE should succed for SCARD_ATTR_VENDOR_NAME and return a non-empty string.
Test Assertion GUID: d58966ef-cb2e-11da-94f8-00123f3a6b60

B.4 IOCTL_SMARTCARD_GET_ATTRIBUTE should succed for SCARD_ATTR_VENDOR_IFD_TYPE and return a non-empty string.
Test Assertion GUID: d58966f0-cb2e-11da-94f8-00123f3a6b60

B.5 IOCTL_SMARTCARD_GET_ATTRIBUTE should succed for SCARD_ATTR_DEVICE_UNIT and return 4 bytes or more.
Test Assertion GUID: d58966f1-cb2e-11da-94f8-00123f3a6b60

B.6 IOCTL_SMARTCARD_GET_ATTRIBUTE should succed for SCARD_ATTR_ATR_STRING when a card is inserted and fail when no card is inserted.
Test Assertion GUID: d58966f2-cb2e-11da-94f8-00123f3a6b60

B.7 IOCTL_SMARTCARD_GET_ATTRIBUTE should succed for SCARD_ATTR_DEFAULT_CLK and return a long between 1000 and 20000.
Test Assertion GUID: d58966f3-cb2e-11da-94f8-00123f3a6b60

B.8 IOCTL_SMARTCARD_GET_ATTRIBUTE should succed for SCARD_ATTR_DEFAULT_MAX_CLK and return a long between 1000 and 20000.
Test Assertion GUID: d58966f4-cb2e-11da-94f8-00123f3a6b60

B.9 IOCTL_SMARTCARD_GET_ATTRIBUTE should succed for SCARD_ATTR_DEFAULT_DATA_RATE.
Test Assertion GUID: d58966f5-cb2e-11da-94f8-00123f3a6b60

B.10 IOCTL_SMARTCARD_GET_ATTRIBUTE should succed for SCARD_ATTR_MAX_DATA_RATE.
Test Assertion GUID: d58966f6-cb2e-11da-94f8-00123f3a6b60

B.11 IOCTL_SMARTCARD_GET_ATTRIBUTE should succed for SCARD_ATTR_MAX_IFSD and return a value between 1 and 254.
Test Assertion GUID: d58966f7-cb2e-11da-94f8-00123f3a6b60

B.12 IOCTL_SMARTCARD_GET_ATTRIBUTE should succed for SCARD_ATTR_CURRENT_PROTOCOL_TYPE and return the current protocol.
Test Assertion GUID: d58966f8-cb2e-11da-94f8-00123f3a6b60

B.13 IOCTL_SMARTCARD_GET_ATTRIBUTE should succed for SCARD_ATTR_PROTOCOL_TYPES and return at least T0 and T1 support.
Test Assertion GUID: d58966f9-cb2e-11da-94f8-00123f3a6b60

B.14 Closing the driver with a request pending should terminate the request.
Test Assertion GUID: d58966fa-cb2e-11da-94f8-00123f3a6b60

B.15 Device should support cold reset.
Test Assertion GUID: d58966fb-cb2e-11da-94f8-00123f3a6b60

B.16 Device should support setting protocol to T0 | T1.
Test Assertion GUID: d58966fc-cb2e-11da-94f8-00123f3a6b60

B.17 IOCTL_SMARTCARD_GET_ATTRIBUTE should succed for SCARD_ATTR_ATR_STRING when protocol is T0 | T1 and a card is inserted and fail when no card is inserted.
Test Assertion GUID: d58966fd-cb2e-11da-94f8-00123f3a6b60

B.18 IOCTL_SMARTCARD_GET_ATTRIBUTE should succed for SCARD_ATTR_CURRENT_PROTOCOL_TYPE when in T0 | T1 and return T0 | T1.
Test Assertion GUID: d58966fe-cb2e-11da-94f8-00123f3a6b60

B.19 IOCTL_SMARTCARD_GET_STATE should succeed and report state <= SCARD_SWALLOWED when card is inserted backwards
Test Assertion GUID: d58966ff-cb2e-11da-94f8-00123f3a6b60

B.20 Device should support cold reset.
Test Assertion GUID: d5896700-cb2e-11da-94f8-00123f3a6b60

C.1 IDS_IOCTL_SMARTCARD_GET_STATE should succeed when no card is inserted.
Test Assertion GUID: d5896701-cb2e-11da-94f8-00123f3a6b60

C.2 IDS_IOCTL_SMARTCARD_GET_STATE should return SCARD_ABSENT when no card is inserted.
Test Assertion GUID: d5896702-cb2e-11da-94f8-00123f3a6b60

C.3 IOCTL_SMARTCARD_IS_PRESENT should fail and return ERROR_IO_PENDING when no card is present.
Test Assertion GUID: d5896703-cb2e-11da-94f8-00123f3a6b60

C.4 IDS_IOCTL_SMARTCARD_GET_STATE should succeed when no card is inserted.
Test Assertion GUID: d5896704-cb2e-11da-94f8-00123f3a6b60

C.5 User must follow onscreen instructions
Test Assertion GUID: d5896705-cb2e-11da-94f8-00123f3a6b60

C.6 IDS_IOCTL_SMARTCARD_GET_STATE should succeed when card is inserted.
Test Assertion GUID: d5896706-cb2e-11da-94f8-00123f3a6b60

C.7 IDS_IOCTL_SMARTCARD_GET_STATE should return SCARD_PRESENT when card is inserted.
Test Assertion GUID: d5896707-cb2e-11da-94f8-00123f3a6b60

C.8 IOCTL_SMARTCARD_IS_ABSENT should fail and return ERROR_IO_PENDING when card is present.
Test Assertion GUID: d5896708-cb2e-11da-94f8-00123f3a6b60

C.9 Device should support cold reset.
Test Assertion GUID: d5896709-cb2e-11da-94f8-00123f3a6b60

C.10 IDS_IOCTL_SMARTCARD_GET_STATE should succeed when card is inserted after returning from cold reset.
Test Assertion GUID: d589670a-cb2e-11da-94f8-00123f3a6b60

C.11 GetOverlappedResult should succeed.
Test Assertion GUID: d589670b-cb2e-11da-94f8-00123f3a6b60

C.12 IDS_IOCTL_SMARTCARD_GET_STATE should return SCARD_NEGOTIABLE after a cold reset when card is inserted.
Test Assertion GUID: d589670c-cb2e-11da-94f8-00123f3a6b60

C.13 Device should support setting protocol to T0 | T1.
Test Assertion GUID: d589670d-cb2e-11da-94f8-00123f3a6b60

C.14 IDS_IOCTL_SMARTCARD_GET_STATE should succeed when card is inserted after returning from cold reset and setting protocol to T0 | T1.
Test Assertion GUID: d589670e-cb2e-11da-94f8-00123f3a6b60

C.15 GetOverlappedResult should succeed.
Test Assertion GUID: d589670f-cb2e-11da-94f8-00123f3a6b60

C.16 IDS_IOCTL_SMARTCARD_GET_STATE should return SCARD_SPECIFIC after a cold reset when card is inserted and setting protocol to T0 | T1.
Test Assertion GUID: d5896710-cb2e-11da-94f8-00123f3a6b60

C.17 IOCTL_SMARTCARD_POWER (SCARD_POWER_DOWN) should succeed (or succeed after GetOverlappedResults).
Test Assertion GUID: d5896711-cb2e-11da-94f8-00123f3a6b60

C.18 IDS_IOCTL_SMARTCARD_GET_STATE should succeed.
Test Assertion GUID: d5896712-cb2e-11da-94f8-00123f3a6b60

C.19 GetOverlappedResult should succeed.
Test Assertion GUID: d5896713-cb2e-11da-94f8-00123f3a6b60

C.20 IDS_IOCTL_SMARTCARD_GET_STATE should return SCARD_PRESENT when card is inserted and powered down.
Test Assertion GUID: d5896714-cb2e-11da-94f8-00123f3a6b60

C.21 IDS_IOCTL_SMARTCARD_GET_STATE should succeed.
Test Assertion GUID: d5896715-cb2e-11da-94f8-00123f3a6b60

C.22 User must follow onscreen instructions
Test Assertion GUID: d5896716-cb2e-11da-94f8-00123f3a6b60

C.23 IDS_IOCTL_SMARTCARD_GET_STATE should succeed.
Test Assertion GUID: d5896717-cb2e-11da-94f8-00123f3a6b60

C.24 User must follow onscreen instructions
Test Assertion GUID: d5896718-cb2e-11da-94f8-00123f3a6b60

D.1.0.1 Device should support seeting T0 protocol for T0 card.
Test Assertion GUID: d5896719-cb2e-11da-94f8-00123f3a6b60

D.1.1.1 Device should support cold reset.
Test Assertion GUID: d589671a-cb2e-11da-94f8-00123f3a6b60

D.1.1.2 IDS_IOCTL_SMARTCARD_GET_STATE should return SCARD_NEGOTIABLE after a cold reset when card is inserted.
Test Assertion GUID: d589671b-cb2e-11da-94f8-00123f3a6b60

D.1.1.3 Device should support setting T0 protocol for T0 card.
Test Assertion GUID: d589671c-cb2e-11da-94f8-00123f3a6b60

D.1.1.4 Device should support ERASE APDU, and return 90 00.
Test Assertion GUID: d589671d-cb2e-11da-94f8-00123f3a6b60

D.1.1.5 Selecting an existing file should succeed.
Test Assertion GUID: d589671e-cb2e-11da-94f8-00123f3a6b60

D.1.1.6 Device should support writing data in 64 byte blocks.
Test Assertion GUID: d589671f-cb2e-11da-94f8-00123f3a6b60

D.1.1.7 Device should support reading data in 64 byte blocks, and read data should match that which was previously written.
Test Assertion GUID: d5896720-cb2e-11da-94f8-00123f3a6b60

D.1.1.8 Device should support writing data in single 255 byte block.
Test Assertion GUID: d5896721-cb2e-11da-94f8-00123f3a6b60

D.1.1.9 Device should properly handle Transmit when receive buffer is too small.
Test Assertion GUID: d5896722-cb2e-11da-94f8-00123f3a6b60

D.1.1.10 Device should properly handle the selection of a file where the path is too short.
Test Assertion GUID: d5896723-cb2e-11da-94f8-00123f3a6b60

D.1.1.11 Device should properly handle the selection of a non-existant file.
Test Assertion GUID: d5896724-cb2e-11da-94f8-00123f3a6b60

D.1.1.12 Device should properly handle a command that times out.
Test Assertion GUID: d5896725-cb2e-11da-94f8-00123f3a6b60

D.1.1.13 Device should support setting T0 protocol for T0 card.
Test Assertion GUID: d5896726-cb2e-11da-94f8-00123f3a6b60

D.1.1.14 Device should support restarting work wait time once in a single transaction.
Test Assertion GUID: d5896727-cb2e-11da-94f8-00123f3a6b60

D.1.1.15 Device should support restarting work wait time twice in a single transaction.
Test Assertion GUID: d5896728-cb2e-11da-94f8-00123f3a6b60

D.1.1.16 Device should support restarting work wait time 5 times in a single transaction.
Test Assertion GUID: d5896729-cb2e-11da-94f8-00123f3a6b60

D.1.1.17 Device should support restarting work wait time 30 times in a single transaction.
Test Assertion GUID: d589672a-cb2e-11da-94f8-00123f3a6b60

D.2.0.1 Device should support seting T0 inverse protocol for T0 inverse card.
Test Assertion GUID: d589672b-cb2e-11da-94f8-00123f3a6b60

D.2.1.1 Device should support cold reset.
Test Assertion GUID: d589672c-cb2e-11da-94f8-00123f3a6b60

D.2.1.2 IDS_IOCTL_SMARTCARD_GET_STATE should return SCARD_NEGOTIABLE after a cold reset when card is inserted.
Test Assertion GUID: d589672d-cb2e-11da-94f8-00123f3a6b60

D.2.1.3 Device should support seeting T0 protocol for T0 card.
Test Assertion GUID: d589672e-cb2e-11da-94f8-00123f3a6b60

D.2.1.4 Device should support ERASE APDU, and return 90 00.
Test Assertion GUID: d589672f-cb2e-11da-94f8-00123f3a6b60

D.2.1.5 Selecting an existing file should succeed.
Test Assertion GUID: d5896730-cb2e-11da-94f8-00123f3a6b60

D.2.1.6 Device should support writing data in 64 byte blocks.
Test Assertion GUID: d5896731-cb2e-11da-94f8-00123f3a6b60

D.2.1.7 Device should support reading data in 64 byte blocks, and read data should match that which was previously written.
Test Assertion GUID: d5896732-cb2e-11da-94f8-00123f3a6b60

D.2.1.8 Device should support writing data in single 255 byte block.
Test Assertion GUID: d5896733-cb2e-11da-94f8-00123f3a6b60

D.2.1.9 Device should properly handle Transmit when receive buffer is too small.
Test Assertion GUID: d5896734-cb2e-11da-94f8-00123f3a6b60

D.2.1.10 Device should properly handle the selection of a file where the path is too short.
Test Assertion GUID: d5896735-cb2e-11da-94f8-00123f3a6b60

D.2.1.11 Device should properly handle the selection of a non-existant file.
Test Assertion GUID: d5896736-cb2e-11da-94f8-00123f3a6b60

D.2.1.12 Device should properly handle a command that times out.
Test Assertion GUID: d5896737-cb2e-11da-94f8-00123f3a6b60

D.2.1.13 Device should support seting T0 inverse protocol for T0 inverse card.
Test Assertion GUID: d5896738-cb2e-11da-94f8-00123f3a6b60

D.2.1.14 Device should support restarting work wait time once in a single transaction.
Test Assertion GUID: d5896739-cb2e-11da-94f8-00123f3a6b60

D.2.1.15 Device should support restarting work wait time twice in a single transaction.
Test Assertion GUID: d589673a-cb2e-11da-94f8-00123f3a6b60

D.2.1.16 Device should support restarting work wait time 5 times in a single transaction.
Test Assertion GUID: d589673b-cb2e-11da-94f8-00123f3a6b60

D.2.1.17 Device should support restarting work wait time 30 times in a single transaction.
Test Assertion GUID: d589673c-cb2e-11da-94f8-00123f3a6b60

D.3.0.1 Device should fail setting unsupported protcol for card with ERROR_NOT_SUPPORTED.
Test Assertion GUID: d589673d-cb2e-11da-94f8-00123f3a6b60

D.3.0.2 Device should support setting T0 protocol for T0 card.
Test Assertion GUID: d589673e-cb2e-11da-94f8-00123f3a6b60

D.3.1.1 Device should support authentication, erasing, and creating of files.
Test Assertion GUID: d589673f-cb2e-11da-94f8-00123f3a6b60

D.3.2.1 Device should suppourt updating 1 byte of file.
Test Assertion GUID: d5896740-cb2e-11da-94f8-00123f3a6b60

D.3.2.2 Device should suppourt updating 25 bytes of file.
Test Assertion GUID: d5896741-cb2e-11da-94f8-00123f3a6b60

D.3.2.3 Device should suppourt updating 75 bytes of file.
Test Assertion GUID: d5896742-cb2e-11da-94f8-00123f3a6b60

D.3.2.4 Device should suppourt updating 128 bytes of file.
Test Assertion GUID: d5896743-cb2e-11da-94f8-00123f3a6b60

D.3.3.1 Bytes read should match those previously written.
Test Assertion GUID: d5896744-cb2e-11da-94f8-00123f3a6b60

D.3.4.1 Device should support selection and deletion of test file.
Test Assertion GUID: d5896745-cb2e-11da-94f8-00123f3a6b60

D.3.5.1 Device should support selection of card's master file.
Test Assertion GUID: d5896746-cb2e-11da-94f8-00123f3a6b60

D.3.5.2 Device should support creation of PIN.
Test Assertion GUID: d5896747-cb2e-11da-94f8-00123f3a6b60

D.3.5.3 Device should support setting of PIN.
Test Assertion GUID: d5896748-cb2e-11da-94f8-00123f3a6b60

D.3.5.4 Device should support selection of card's master file.
Test Assertion GUID: d5896749-cb2e-11da-94f8-00123f3a6b60

D.3.5.5 Device should support creation of a private key.
Test Assertion GUID: d589674a-cb2e-11da-94f8-00123f3a6b60

D.3.5.6 Device should support selection of card's master file.
Test Assertion GUID: d589674b-cb2e-11da-94f8-00123f3a6b60

D.3.5.7 Device should support creation of a public key.
Test Assertion GUID: d589674c-cb2e-11da-94f8-00123f3a6b60

D.3.5.8 Device should support selection of card's master file.
Test Assertion GUID: d589674d-cb2e-11da-94f8-00123f3a6b60

D.3.5.9 Device should support selection of private key.
Test Assertion GUID: d589674e-cb2e-11da-94f8-00123f3a6b60

D.3.5.10 Device should support user authentication.
Test Assertion GUID: d589674f-cb2e-11da-94f8-00123f3a6b60

D.3.5.11 Device should support generation of key pair.
Test Assertion GUID: d5896750-cb2e-11da-94f8-00123f3a6b60

D.3.6.1 Device should support accepting data to hash, and not interfere with card hashing that data.
Test Assertion GUID: d5896751-cb2e-11da-94f8-00123f3a6b60

D.3.6.2 Device should permit reading of hashed data.
Test Assertion GUID: d5896752-cb2e-11da-94f8-00123f3a6b60

D.4.0.1 Device should fail setting unsupported protcol for card with ERROR_NOT_SUPPORTED.
Test Assertion GUID: d5896753-cb2e-11da-94f8-00123f3a6b60

D.4.0.2 Device should support setting T1 protocol for T1 card.
Test Assertion GUID: d5896754-cb2e-11da-94f8-00123f3a6b60

D.4.1.1 Device should support and maintain authentication and selection, deletion, and creation of files and directories.
Test Assertion GUID: d5896755-cb2e-11da-94f8-00123f3a6b60

D.4.2.1 Device should maintain authentication and support selection of files.
Test Assertion GUID: d5896756-cb2e-11da-94f8-00123f3a6b60

D.4.2.2 Device should maintain authentication and support writing 1 byte to existing file.
Test Assertion GUID: d5896757-cb2e-11da-94f8-00123f3a6b60

D.4.2.3 Device should maintain authentication, suppourt reading 1 byte, and store data reliably.
Test Assertion GUID: d5896758-cb2e-11da-94f8-00123f3a6b60

D.4.2.4 Device should maintain authentication and support writing 25 bytes to existing file.
Test Assertion GUID: d5896759-cb2e-11da-94f8-00123f3a6b60

D.4.2.5 Device should maintain authentication, suppourt reading 25 bytes, and store data reliably.
Test Assertion GUID: d589675a-cb2e-11da-94f8-00123f3a6b60

D.4.2.6 Device should maintain authentication and support writing 50 bytes to existing file.
Test Assertion GUID: d589675b-cb2e-11da-94f8-00123f3a6b60

D.4.2.7 Device should maintain authentication, suppourt reading 50 bytes, and store data reliably.
Test Assertion GUID: d589675c-cb2e-11da-94f8-00123f3a6b60

D.4.2.8 Device should maintain authentication and support writing 75 bytes to existing file.
Test Assertion GUID: d589675d-cb2e-11da-94f8-00123f3a6b60

D.4.2.9 Device should maintain authentication, suppourt reading 75 bytes, and store data reliably.
Test Assertion GUID: d589675e-cb2e-11da-94f8-00123f3a6b60

D.4.2.10 Device should maintain authentication and support writing 100 bytes to existing file.
Test Assertion GUID: d589675f-cb2e-11da-94f8-00123f3a6b60

D.4.2.11 Device should maintain authentication, suppourt reading 100 bytes, and store data reliably.
Test Assertion GUID: d5896760-cb2e-11da-94f8-00123f3a6b60

D.4.2.12 Device should maintain authentication and support writing 125 bytes to existing file.
Test Assertion GUID: d5896761-cb2e-11da-94f8-00123f3a6b60

D.4.2.13 Device should maintain authentication, suppourt reading 125 bytes, and store data reliably.
Test Assertion GUID: d5896762-cb2e-11da-94f8-00123f3a6b60

D.4.2.14 Device should maintain authentication and support writing 128 bytes to existing file.
Test Assertion GUID: d5896763-cb2e-11da-94f8-00123f3a6b60

D.4.2.15 Device should maintain authentication, suppourt reading 128 bytes, and store data reliably.
Test Assertion GUID: d5896764-cb2e-11da-94f8-00123f3a6b60

D.4.3.1 Device should maintain authentication and support selection of files.
Test Assertion GUID: d5896765-cb2e-11da-94f8-00123f3a6b60

D.4.3.2 Device should support storing heterogenous bit patterns reliably.
Test Assertion GUID: d5896766-cb2e-11da-94f8-00123f3a6b60

D.4.3.3 Device should support storing alternating bit patterns reliably.
Test Assertion GUID: d5896767-cb2e-11da-94f8-00123f3a6b60

D.4.3.4 Device should support storing alternating bit patterns reliably.
Test Assertion GUID: d5896768-cb2e-11da-94f8-00123f3a6b60

D.4.3.5 Device should support storing alternating bit patterns reliably.
Test Assertion GUID: d5896769-cb2e-11da-94f8-00123f3a6b60

D.4.3.6 Device should support storing alternating bit patterns reliably.
Test Assertion GUID: d589676a-cb2e-11da-94f8-00123f3a6b60

D.4.3.7 Device should support storing alternating bit patterns reliably.
Test Assertion GUID: d589676b-cb2e-11da-94f8-00123f3a6b60

D.4.3.8 Device should support storing alternating bit patterns reliably.
Test Assertion GUID: d589676c-cb2e-11da-94f8-00123f3a6b60

D.4.3.9 Device should support storing alternating bit patterns reliably.
Test Assertion GUID: d589676d-cb2e-11da-94f8-00123f3a6b60

D.4.4.1 Device should maintain authentication and support selection of files.
Test Assertion GUID: d589676e-cb2e-11da-94f8-00123f3a6b60

D.4.4.2 Device should support storing homogenous bit patterns reliably.
Test Assertion GUID: d589676f-cb2e-11da-94f8-00123f3a6b60

D.4.4.3 Device should support storing homogenous bit patterns reliably.
Test Assertion GUID: d5896770-cb2e-11da-94f8-00123f3a6b60

D.4.4.4 Device should support storing homogenous bit patterns reliably.
Test Assertion GUID: d5896771-cb2e-11da-94f8-00123f3a6b60

D.4.4.5 Device should support storing homogenous bit patterns reliably.
Test Assertion GUID: d5896772-cb2e-11da-94f8-00123f3a6b60

D.4.4.6 Device should support storing homogenous bit patterns reliably.
Test Assertion GUID: d5896773-cb2e-11da-94f8-00123f3a6b60

D.4.4.7 Device should support storing homogenous bit patterns reliably.
Test Assertion GUID: d5896774-cb2e-11da-94f8-00123f3a6b60

D.4.4.8 Device should support storing homogenous bit patterns reliably.
Test Assertion GUID: d5896775-cb2e-11da-94f8-00123f3a6b60

D.4.4.9 Device should support storing homogenous bit patterns reliably.
Test Assertion GUID: d5896776-cb2e-11da-94f8-00123f3a6b60

D.4.5.1 Selecting a non-existing file should succeed and return 0x9404, file not found.
Test Assertion GUID: d5896777-cb2e-11da-94f8-00123f3a6b60

D.4.6.1 Selecting a file with no FileID should succeed and select the master file.
Test Assertion GUID: d5896778-cb2e-11da-94f8-00123f3a6b60

D.4.7.1 Issuing a select with a path that is too short should succeed and return 0x9404, file not found.
Test Assertion GUID: d5896779-cb2e-11da-94f8-00123f3a6b60

D.4.8.1 Issuing a select with the wrong Lc should succeed and return 0x9404, file not found.
Test Assertion GUID: d589677a-cb2e-11da-94f8-00123f3a6b60

D.4.9.1 Issuing a command with an incomplete command APDU should succeed and return 0x6700.
Test Assertion GUID: d589677b-cb2e-11da-94f8-00123f3a6b60

D.4.10.1 Selecting a file with no FileID should succeed and select the master file.
Test Assertion GUID: d589677c-cb2e-11da-94f8-00123f3a6b60

D.4.10.2 Device should support authentication.
Test Assertion GUID: d589677d-cb2e-11da-94f8-00123f3a6b60

D.4.10.3 Device should support creating a directory.
Test Assertion GUID: d589677e-cb2e-11da-94f8-00123f3a6b60

D.4.10.4 Device should support selecting a directory.
Test Assertion GUID: d589677f-cb2e-11da-94f8-00123f3a6b60

D.4.10.5 Device should support creating a directory.
Test Assertion GUID: d5896780-cb2e-11da-94f8-00123f3a6b60

D.4.10.6 Device should support selecting a directory.
Test Assertion GUID: d5896781-cb2e-11da-94f8-00123f3a6b60

D.4.10.7 Device should support creating a file.
Test Assertion GUID: d5896782-cb2e-11da-94f8-00123f3a6b60

D.4.10.8 Device should support selecting a file with the file's fully qualified path.
Test Assertion GUID: d5896783-cb2e-11da-94f8-00123f3a6b60

D.4.10.9 Device should support writing to a file.
Test Assertion GUID: d5896784-cb2e-11da-94f8-00123f3a6b60

D.4.10.10 Device should support reading from a file and storing data reliably.
Test Assertion GUID: d5896785-cb2e-11da-94f8-00123f3a6b60

D.4.10.11 Device should support erasing file.
Test Assertion GUID: d5896786-cb2e-11da-94f8-00123f3a6b60

D.4.10.12 Selecting a file that has been erased should return 0x9404, file not found.
Test Assertion GUID: d5896787-cb2e-11da-94f8-00123f3a6b60

D.4.10.13 Device should support selecting a directory with it's full path.
Test Assertion GUID: d5896788-cb2e-11da-94f8-00123f3a6b60

D.4.10.14 Device should support erasing a directory.
Test Assertion GUID: d5896789-cb2e-11da-94f8-00123f3a6b60

D.4.10.15 Device should support selecting a directory with it's full path.
Test Assertion GUID: d589678a-cb2e-11da-94f8-00123f3a6b60

D.4.10.16 Device should support erasing a directory.
Test Assertion GUID: d589678b-cb2e-11da-94f8-00123f3a6b60

D.4.10.17 Device should support selecting a file.
Test Assertion GUID: d589678c-cb2e-11da-94f8-00123f3a6b60

D.4.10.18 Device should support erasing file.
Test Assertion GUID: d589678d-cb2e-11da-94f8-00123f3a6b60

D.5.0.1 Device should fail setting unsupported protcol for card with ERROR_NOT_SUPPORTED.
Test Assertion GUID: d589678e-cb2e-11da-94f8-00123f3a6b60

D.5.0.2 Device should support setting T1 protocol for T1 card.
Test Assertion GUID: d589678f-cb2e-11da-94f8-00123f3a6b60

D.5.1.1 Calling IOCTL_SMARTCARD_TRANSMIT with too small of a receive buffer should fail with ERROR_INSUFFICIENT_BUFFER.
Test Assertion GUID: d5896790-cb2e-11da-94f8-00123f3a6b60

D.5.2.1 Device should support selecting an existing file.
Test Assertion GUID: d5896791-cb2e-11da-94f8-00123f3a6b60

D.5.2.2 Device should support a read when the card issues one wait time extension request.
Test Assertion GUID: d5896792-cb2e-11da-94f8-00123f3a6b60

D.5.2.3 Device should support a read when the card issues two wait time extension requests.
Test Assertion GUID: d5896793-cb2e-11da-94f8-00123f3a6b60

D.5.2.4 Device should support a read when the card issues 5 wait time extension requests.
Test Assertion GUID: d5896794-cb2e-11da-94f8-00123f3a6b60

D.5.2.5 Device should support a read when the card issues 30 wait time extension requests.
Test Assertion GUID: d5896795-cb2e-11da-94f8-00123f3a6b60

D.5.3.1 Device should support selecting an existing file.
Test Assertion GUID: d5896796-cb2e-11da-94f8-00123f3a6b60

D.5.3.2 Upon issuing a write the card will respond with a RESYNC request, device should fail the write and return ERROR_IO_DEVICE.
Test Assertion GUID: d5896797-cb2e-11da-94f8-00123f3a6b60

D.5.3.3 Upon issuing a read the card will respond with a RESYNC request, device should fail the read and return ERROR_IO_DEVICE.
Test Assertion GUID: d5896798-cb2e-11da-94f8-00123f3a6b60

D.5.4.1 Device should support selecting an existing file.
Test Assertion GUID: d5896799-cb2e-11da-94f8-00123f3a6b60

D.5.4.2 Card will respond to read request with a response that contains the wrong sequence number; device should fail the read and return ERROR_IO_DEVICE.
Test Assertion GUID: d589679a-cb2e-11da-94f8-00123f3a6b60

D.5.5.1 Device should support selecting an existing file.
Test Assertion GUID: d589679b-cb2e-11da-94f8-00123f3a6b60

D.5.5.2 Device should handle writing a transaction greater than the cards IFSC.
Test Assertion GUID: d589679c-cb2e-11da-94f8-00123f3a6b60

D.5.6.1 Device should support selecting an existing file.
Test Assertion GUID: d589679d-cb2e-11da-94f8-00123f3a6b60

D.5.6.2 Card will timeout, device should fail the read and return ERROR_IO_DEVICE.
Test Assertion GUID: d589679e-cb2e-11da-94f8-00123f3a6b60

D.5.6.1 Device should support selecting an existing file.
Test Assertion GUID: d589679f-cb2e-11da-94f8-00123f3a6b60

D.5.6.2 Device should support selecting a
Test Assertion GUID: d58967a0-cb2e-11da-94f8-00123f3a6b60

D.5.6.3 Card has not been reset since running EFwtx test and result of test was as expected.
Test Assertion GUID: d58967a1-cb2e-11da-94f8-00123f3a6b60

D.5.6.4 Card has not been reset since running EFresync read test and result of test was as expected.
Test Assertion GUID: d58967a2-cb2e-11da-94f8-00123f3a6b60

D.5.6.5 Card has not been reset since running EFresync write test and result of test was as expected.
Test Assertion GUID: d58967a3-cb2e-11da-94f8-00123f3a6b60

D.5.6.6 Card has not been reset since running EFseqnum test and result of test was as expected.
Test Assertion GUID: d58967a4-cb2e-11da-94f8-00123f3a6b60

D.5.6.7 Card has not been reset since running EFifsc test and result of test was as expected.
Test Assertion GUID: d58967a5-cb2e-11da-94f8-00123f3a6b60

D.5.6.8 Card has not been reset since running EFifsd test and result of test was as expected.
Test Assertion GUID: d58967a6-cb2e-11da-94f8-00123f3a6b60

D.5.6.9 Card has not been reset since running EFtimeout test and result of test was as expected.
Test Assertion GUID: d58967a7-cb2e-11da-94f8-00123f3a6b60

E.1 Device reports SCARD_ABSENT when returning from hibernate when no card was inserted.
Test Assertion GUID: d58967a8-cb2e-11da-94f8-00123f3a6b60

E.2 Device reports SCARD_PRESENT when returning from hibernate when card was inserted before the computer was hibernated.
Test Assertion GUID: d58967a9-cb2e-11da-94f8-00123f3a6b60

E.3 Device reports SCARD_ABSENT when returning from hibernate when card was removed during hibernation.
Test Assertion GUID: d58967aa-cb2e-11da-94f8-00123f3a6b60

E.4 Device reports SCARD_PRESENT when returning from hibernate when card was inserted during hibernation.
Test Assertion GUID: d58967ab-cb2e-11da-94f8-00123f3a6b60


Portable Media Devices Testing Overview

These procedures test your Portable Media Device for proper functionality by using the Microsoft Windows Driver Kit (WDK) and the Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as required for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

For specific requirements about testing a Windows Portable Device over Terminal Server, see Terminal Server PNP Redirection Testing Overview.

The test procedures are divided into the following types of topics:

  • Overview: The overview topics describe the hardware, software, and tester knowledge requirements.
  • Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.
  • Running: The running topics describe how to run the tests for your device or system.

Run time: approximately <TBD> hours

Hardware Requirements

The following hardware is required for Portable Media Device testing. You might need additional hardware if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One computer that is running Microsoft Windows Vista (DSCs and Cell Phones) or Windows XP with Service Pack 2 (SP2) (Cell Phones) with an internal or external USB port connected. USB 2.0 is recommended.
  • A device with a USB cable.

Software Requirements

The following software is required to run the Portable Media Device tests:

  • For digital still cameras:
    • No additional software is required.
    • Your device must install with the Microsoft Media Transfer Protocol class driver.
    • Your device must appear under “Portable Devices” in Device Manager in Windows Vista.
  • For cellular handsets:
    • On Windows XP SP2, you need to download and install Windows Media Player 11.
    • You need to provide your Windows Portable Devices cellular phone driver. The driver INF file must install the device as a WPD class with the following ClassGUID:

      Class=WPD
      ClassGUID={EEC5AD98-8080-425f-922A-DABF3DE3F69A}

    • Your device must appear under the “Portable Devices” category (on Windows Vista) or the “Windows Portable Devices” category (on Windows XP SP2) in Device Manager.

Tester Knowledge Requirements

To run the Portable Media Device tests, testers must know how to accomplish the following tasks:

  • Switch a device to a computer connectivity mode before plugging it in.
  • Plug in a device to a USB port of the PC and maintain the connectivity throughout the test run.
  • Provide continuous power to the device during the duration of the test run.
  • Troubleshoot device installation, by checking if the device is installed successfully in Device Manager or by looking at the SetupAPI device installation logs.

After you have reviewed the necessary requirements, you can prepare to test your Portable Media Device.

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Preparing for Portable Media Device Testing

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see the Portable Media Devices Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, For more information about autologon, see [image] How to turn on automatic logon in Windows XP.

Test system configuration

To set the logo test dimension for the machine pool for Portable Media Device tests, do the following:

  1. Switch to the Job Monitor window. You can also open a new Job Monitor window by clicking Explorers and then clicking Job Monitor.
  2. In the Machine Pool tab of the Job Monitor window, right-click the machine pool that contains the computers whose dimensions you want to set for logo testing, and click Properties.
  3. In the Machine Pool Properties dialog box, click the MCU Policy tab.
  4. In the Available Dimensions pane, select the Wdk\ConfigureCellularHandsetsPortableDevice and Wdk\ConfigureDigitalStillCameraPortableDevice logo test dimensions, and then click Add.

    The logo test dimensions that you select are shown in the Dimensions in Policy pane.

  5. Click Apply, and then click OK.


Running the Portable Media Device Tests

The following procedures describe how to run the Portable Media Device tests.

To run the cellular phone logo tests
  1. Connect a WPD cellular phone device to the DTM test client computer.
  2. Install the WPD cellular phone driver for this device.
  3. From Device Console, locate this device in the "WPD" node on the left pane.
  4. Select and run the following jobs from the Portable Media Device -> Cellular Handsets category:
    • WPD Compliance Tests (WDK)
    • WPD Compliance Stress Tests (WDK)
    • USB Device Framework (CV)
    • USB HIDView (CV)
    • USB Specification Compliance
    • USB Selective Suspend
    • USB Enumeration Stress
    • USB Device Control Requests
    • USB Descriptor test
    • USB Address Description Test
    • USB Serial Number

To run the cellular phone Terminal Server logo tests
  • For more information about running cellular phone Terminal Server logo tests, see Running the Terminal Server PNP Redirection Tests.

To run the digital still camera logo tests
  1. Connect a PTP or MTP camera to the DTM test client computer.
  2. After the camera device appears in Device Manager, locate this device in the “WPD” node in the left pane.
  3. Select and run the following jobs from the Portable Media Device ->“DSC category, depending on where you are applying for a Gold or Silver logo for the device:
    • MTP Camera or Camcorder [Gold Logo] Mtp Test
    • PTP Camera or Camcorder [Silver Logo] Mtp Test


Troubleshooting Portable Media Device Testing

This topic describes how to troubleshoot the cellular handset and digital still camera logo tests.

Note For more information about troubleshooting cellular phone Terminal Server logo tests, see Troubleshooting Terminal Server PNP Redirection Testing.

Troubleshooting the Cellular Handset Logo Tests

If the tests do not run after you schedule them, the tests require the WPD\PortableDeviceType Exists constaint before you can run them.

To enable this constraint, you need to apply the Wdk\ConfigureCellularHandsetsPortableDevice dimension on your test machine pool. (For more information about apply this dimension, see the “Test system configuration” section of Preparing for Portable Media Device Testing.)

On Windows XP SP2 computer, you also need to install Windows Media Player 11 before you run the cellular handset logo tests (For more information about the Windows Media Player 11 requirement, see the "Software Requirements" section of Portable Media Devices Testing Overview.)

If many tests start to fail after some time, especially when you are running the Stress test, do the following to check that the device has not gone into a bad state:

  • Verify that the device is still connected to the test machine and is turned on.
  • Verify that the device node is still visible in Device Manager.
  • Browse the device's contents in My Computer by viewing objects or files in the device storage. If the device stops responding (that is, hangs), the driver or device might have gone into a bad state.

If the device has gone into a persistent bad state, reset the device or remove and insert the batteries.

Troubleshooting the Digital Still Camera Logo Tests

To run the digital still camera logo tests manually, do the following:

  1. Plug in the device under test.
  2. Run Mtpinfup.exe. This application will update or disable the in-box driver to a test driver and then generate an XML file that contains the list of active devices.
  3. Place that XML file that Mtpinfup.exe generated in the same folder as the MtpTest binaries if you ran Mtpinfup.exe from a different folder. The in-box driver will not be able to talk the device; instead, MtpTest will talk with the device.
  4. Run MtpTest, and select and run the appropriate test cases.
  5. Run mtpinfup.exe /post to return to the original setup so that test driver is updated to an in-box driver and the in-box driver "talks" to the device (that is, you can browse the device's contents My Computer).

Note You need to unplug some devices and plug them back in every time the driver (that is, the INF file) has been updated.

Note If the device has gone into a persistent bad state, reset the device or remove and insert the batteries.

Note To update drivers, you need Administrator privileges.


Terminal Server PNP Redirection Testing Overview

These procedures test your Windows Portable Device (WPD) over Terminal Server for proper functionality by using the Microsoft Windows Driver Kit (WDK) and the Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as required for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

The test procedures are divided into the following types of topics:

  • Overview: The overview topics describe the hardware, software, and tester knowledge requirements.
  • Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.
  • Running: The running topics describe how to run the tests for your device or system.

Run time: approximately 1-2 hours

Hardware Requirements

The following hardware is required for Terminal Server PNP Redirection testing:

  • Two computers that are running Microsoft Windows Vista (the Terminal Server (TS) Client computer and Terminal Server (TS) Server computer).
  • An internal or external USB port connected to the TS client computer. USB 2.0 is recommended.
  • A WPD device connected with a USB cable to the TS client computer.
  • The TS Server computer should be running Windows Vista Enterprise or Windows Vista, Ultimate Edition.

Software Requirements

The following software is required to run the Terminal Server PNP Redirection tests:

  • For cellular handsets, you need to provide your Windows Portable Devices (WPD) cellular phone driver. The driver INF file must install the device as a WPD class with the following ClassGUID:

    Class=WPD
    ClassGUID={EEC5AD98-8080-425f-922A-DABF3DE3F69A}

  • Your device must appear under “Windows Portable Device” or “Portable Device” in Device Manager.
  • Your driver INF file must support TS PNP Device Redirection. For more information about this support, see Authoring INF Files to Support TS PNP Device Redirection.

Tester Knowledge Requirements

To run the Terminal Server PNP Redirection tests, testers must know how to accomplish the following tasks:

  • Plug in a device to a USB port of a computer and maintain the connectivity throughout the test run.
  • Provide continuous power to the device during the duration of the test run.
  • Troubleshoot device installation, by checking if the device is installed successfully by using Device Manager or by looking at the SetupAPI device installation logs.

After you have reviewed the necessary requirements, you can prepare to test your Windows Portable Device (WPD) over Terminal Server.

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Authoring INF Files to Support TS PNP Device Redirection

To enable PNP device redirection, there is a generic INF file (Ts_generic.inf) that resides on the Terminal Server and that is loaded for any device that is redirected. This file simply loads the redirection driver (Usbdr.dll) as the driver for the device, and the driver then redirects any I/O calls between applications and the client computer.

In theory, the Ts_generic.inf file would be sufficient to redirect devices. However, in some case, this redirection does not work so easily. For example, some driver INF files might install user-mode components that help an application communicate with the driver, and other INF files write values in the registry that the application consumes. With a generic INF file, such scenarios do not work. Instead, you must author your device-specific INF file with certain redirection sections. This updated device INF file will combine the functionality of Ts_generic.inf and add any device-specific installation.

To create your device-specific INF file
  1. Start with the local INF file for your device, enumerate the hardware identifiers (IDs) that the device supports, and identify the IDs that you want to support for redirection. The following code example shows a typical device section of an INF file.

    [Generic.NTx86]
    “My Device A”=SectionA, HardwareIDA
    “My Device B”=SectionB, HardwareIDB

    In the preceding example, the INF file includes two hardware (or compatibility) IDs. SectionA and SectionB are the sections that get run for device A and device B, respectively.

  2. If you want to support redirection for device A, add a hardware ID for the redirected version in the list. The following code example shows the preceding example with an additional hardware ID for the redirected version.

    [Generic.NTx86]
    “My Device A”=SectionA, HardwareIDA
    “My Device B”=SectionB, HardwareIDB
    “My Redirected Device A”=SectionARedirected, TS_HardwareIDA

  3. Add the following sections to the new SectionARedirected section to refer to drivers and services section of Ts_generic.inf:
    • Any device-specific information for your device (from [SectionARedirect.hwl]), such as registry entries. Make sure that you do not include your own driver installation. Your driver should be replaced by the redirection driver.
    • Any services that applications need (copy entries that are needed from [SectionA.Services]).
    • Any coinstallers that are needed (copy from [SectionA.CoInstallers])

    The following code examples show where you should add the preceding information to SectionARedirected.hw and SectionARedirected.Wdf.

    [SectionARedirected.hw]
    Include=ts_generic.inf
    Needs=TS_Generic_Install.hw
    ; Add any device-specific information for your device (the information
    from [SectionARedirect.hwl), such as registry entries. Make sure that you
    do not include your own driver installation here. Your driver should be
    replaced by the redirection driver that the preceding lines specify.

    [SectionARedirected.Services]
    Include=ts_generic.inf
    Needs=TS_Generic_Install.Services
    ; Add any services that applications need (copy entries needed from [SectionA.Services]).

    [SectionARedirected.CoInstallers]
    Include=ts_generic.inf
    Needs=TS_Generic_Install.CoInstallers
    ; Add any coinstallers that are needed (from [SectionA.CoInstallers]).

    [SectionARedirected.Wdf]
    Include=ts_generic.inf
    Needs=TS_Generic_Install_WdfBasic
    UmdfServiceOrder=UsbDr


Preparing for Terminal Server PNP Redirection Testing

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see the Terminal Server PNP Redirection Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, For more information about autologon, see [image] How to turn on automatic logon in Windows XP.

Test System Configuration

To configure your test system for Terminal Server PNP Redirection tests, do the following:

  1. Ensure that the TS client computer and the TS server computer have the same local Administrator password. The test creates a TS session on the TS server with this Administrator account and password.
  2. If you must update your device INF file to support device redirection (instead of using the Ts_generic.inf file), install the device INF file on the TS server before you start the test.
  3. Both the TS client and TS server computers should be in the same DTM Machine pool.
  4. Update the ADMINPASSWORD Parameter that belongs to the TS_PNPRedirection – WDK job (to be run on the TS client computer) with the correct local Administrator password.
  5. Set the logo test dimension for the machine pool:
    1. Switch to the Job Monitor window. You can also open a new Job Monitor window by clicking Explorers, and then clicking Job Monitor.
    2. In the Machine Pool tab of the Job Monitor window, right-click the machine pool that contains the computers whose dimensions you want to set for logo testing, and click Properties.
    3. In the Machine Pool Properties dialog box, click the MCU Policy tab.
    4. In the Available Dimensions pane, select the Wdk\ConfigureCellularHandsetsPortableDevice and Wdk\ConfigureDigitalStillCameraPortableDevice logo test dimensions, and then click Add.
    5. Ensure that the logo test dimension that you selected is shown in the Dimensions in Policy pane.
    6. Click Apply, and then click OK.


Running the Terminal Server PNP Redirection Tests

To run the Terminal Server PNP redirection logo tests for a cellular phone device:

  1. Connect a WPD Cellular Phone Device to the TS client computer.
  2. Install the WPD Cellular Phone Driver for this device.
  3. If you must update your device INF file to support device redirection (instead of using the Ts_generic.inf file), install the device INF file on the TS Server computer before you start the test.
  4. Update the ADMINPASSWORD Parameter that belongs to the TS_PNPRedirection – WDK job (to be run on the TS client computer) with the correct local Administrator password.
  5. Run the TS_PnpRedirection-WDK DTM job that resides in WDK->TerminalServer->Client DTM category on the TS client computer before you call the DTM device submission user interface (UI).

    Note The S_PnpRedirection-WDK DTM test prepares the system before you start the next set of logo tests.

    Note After you run the TS_PnpRedirection WDK test on TS client computer, the test creates a TS session on the TS Server computer. Do not close this TS session or stop the TS client executable file (that is, Mstsc.exe) after this test is done. This session is required to run the next set of tests.

  6. After you run the TS_PnpRedirection-WDK job on the TC client computer, you should go to the Device Console UI in DTM Studio, look at the TS Server computer, and verify that the WPD device shows up on the server computer. Specifically, from Device Console, locate the test device under the "WPD" node for the TS server computer in the left pane
  7. Start the Logo submission UI to submit the device or driver and target the redirected WPD device that resides on the TS server.
  8. Select and run the following jobs from the TerminalServer->Server->Portable Media Device (TS Redirection) -> Cellular Handsets category:
    • WPD Compliance Tests (WDK)
    • WPD Compliance Stress Tests (WDK)

    Note These tests will be run on the TS server.


Troubleshooting Terminal Server PNP Redirection Testing

This topic describes how to troubleshoot the TS client-side and TS server-side runs.

Troubleshooting the TS Client-side test run for TS_PNPRedirection-WDK

If the test fails, verify that the local Administrator password on both the TS client and TS server computers is the same.

Also, verify that the ADMINPASSWORD parameter for the job is set with the correct local Administrator password.

If the redirected Cellular phone device does not show up in the DTM Device Console UI on the TS server, make sure that you:

  1. Have the correct device INF file on the TS server side.
  2. Check the SetupAPI device installation logs on the server to see what went wrong.
  3. Verify that the TS client computer has started an active TS session to the TS server. You should notice that the workstation on the TS server is locked and this session is consumed by the TS client machine.

Troubleshooting the TS Server-side test run for Cellular Handset Logo Tests

If the tests do not run after you schedule them, the tests require the WPD\PortableDeviceType Exists Exists constaint before you can run them.

To enable this constraint, you need to apply the Wdk\ConfigureCellularHandsetsPortableDevice dimension on your test machine pool. (For more information about apply this dimension, see the “Test system configuration” section of Preparing for Portable Media Device Testing.)

If many tests start to fail after some time, especially when you are running the Stress test, do the following to check that the device has not gone into a bad state:

  • Verify that the device is still connected to the test machine and is turned on.
  • Verify that the device node is still visible in Device Manager.
  • Browse the device's contents in My Computer by viewing objects or files in the device storage. If the device stops responding (that is, hangs), the driver or device might have gone into a bad state.

If the device has gone into a persistent bad state, reset the device or remove and insert the batteries.


Portable Media Devices Tests

Test name Target operating system Test description
Terminal Server PnP Device Redirection Framework Test Tool Windows Vista
TS PnP Device Redirection Framework Compliance Test is a suite of tests that exercises the driver using the WPD API and validates that it is compliant with the Terminal Server Windows Logo requirements.
The target audience for this tool is a third-party driver writer or device vendor who wants to verify that their WPD driver or device that is redirected through a Terminal Services Session over the PnP Device Redirection Framework operates normally.
Note this test requires 2 machines for the test to be run. Kindly refer to the Terminal Server PNP Redirection related lab setup documentation on the details on how to configure the machines prior to starting the test.
There are 2 classes of tests:
a) TerminalServer->Client test: After a Windows Portable Device (WPD) is plugged into the Terminal Server Client machine, vendor is expected to launch the TS_PnPRedirection - WDK automated job (through DTM framework). This job is located in TerminalServer->Client category. The test is responsible for creating a Terminal Server session on the Terminal Server Server machine and redirecting the WPD device on the Terminal Server session. This test doesn’t do any verification and is basically a launching pad for running TerminalServer->Server test. Any Device Logo submission related tasks i.e. launching the Logo Submission UI should be done after this test is run on the client machine targeting the server machine.
b) TerminalServer->Server test: After test a) is run i.e. after the TS_PnpRedirection-WDK job is run on client machine, vendor is expected to go to the Device Console UI in DTM studio and look at the TS Server machine and verify that the WPD device indeed shows up on the server machine. Next, he would launch the Logo Submission UI targeting this redirected device to do a device submission. Finally, run the WPD jobs located under TerminalServer->Server->Windows Portable Device (TS Redirection) category on the TS server machine targeting this redirected device. This will cause the tests to be run on the TS server machine.
Media Transfer Protocol Compliance Test Windows Vista
This test is for the Media Transfer Protocol (MTP) compliance. This suite of tests ensures that the devices that use the MTP class driver that ships with Microsoft Windows Vista and Microsoft Windows Server codenamed "Longhorn" comply with MTP implementation standards. This tool is directed at portable media devices that use the MTP protocol. This test helps to certify that these devices fulfill the requirements for the "Designed for Microsoft Windows" Logo Program for Hardware and work seamlessly with the Windows Portable Devices (WPD) stack as well as with Xbox 360, which can connect to MTP-enabled devices.
This test does not cover:
- Digital Rights Management
- Devices that do not use MTP, but use their own (third-party) drivers to work with the WPD stack
Windows Portable Devices Inf Checker Windows Vista
         You can use Windows Portable Devices (WPD) Inf Checker to verify INF files that are written for WPD devices. This tool verifies that the correct WPD registry entries are specified, values and types are valid, and the Windows Driver Framework (WDF) entries are correctly defined.
Windows Portable Devices Driver Compliance Test Windows Vista
Windows Portable Devices (WPD) Driver Verification Test/Stress tool is a suite of tests that exercises the driver using the WPD API and validates that it is compliant with the Windows Logo requirements.
The target audience for this tool is a third-party driver writer or device vendor who wants to verify that their driver or device fulfils the Windows Logo requirements to work seamlessly with the WPD stack in a protocol-independent way.
This test does not cover:
- Legacy driver testing. Only WPD class drivers will be tested.
- Device-protocol-specific requirements. This will be covered in separate certification tests.
- Digital Rights Management Testing
WMDM Content Transfer Test Windows Vista
         This test verifies that WMA content can be transferred to the device you are testing by using WMDM API.


Terminal Server PnP Device Redirection Framework Test Tool

Type: Automated Test

Overview

TS PnP Device Redirection Framework Compliance Test is a suite of tests that exercises the driver using the WPD API and validates that it is compliant with the Terminal Server Windows Logo requirements.
The target audience for this tool is a third-party driver writer or device vendor who wants to verify that their WPD driver or device that is redirected through a Terminal Services Session over the PnP Device Redirection Framework operates normally.
Note this test requires 2 machines for the test to be run. Kindly refer to the Terminal Server PNP Redirection related lab setup documentation on the details on how to configure the machines prior to starting the test.
There are 2 classes of tests:
a) TerminalServer->Client test: After a Windows Portable Device (WPD) is plugged into the Terminal Server Client machine, vendor is expected to launch the TS_PnPRedirection - WDK automated job (through DTM framework). This job is located in TerminalServer->Client category. The test is responsible for creating a Terminal Server session on the Terminal Server Server machine and redirecting the WPD device on the Terminal Server session. This test doesn’t do any verification and is basically a launching pad for running TerminalServer->Server test. Any Device Logo submission related tasks i.e. launching the Logo Submission UI should be done after this test is run on the client machine targeting the server machine.
b) TerminalServer->Server test: After test a) is run i.e. after the TS_PnpRedirection-WDK job is run on client machine, vendor is expected to go to the Device Console UI in DTM studio and look at the TS Server machine and verify that the WPD device indeed shows up on the server machine. Next, he would launch the Logo Submission UI targeting this redirected device to do a device submission. Finally, run the WPD jobs located under TerminalServer->Server->Windows Portable Device (TS Redirection) category on the TS server machine targeting this redirected device. This will cause the tests to be run on the TS server machine.

Details

The test runs as a C++ application and supports WTT Logging. The TS_PnPRedirection - WDK test under TerminalServer->Client category is the first test to be run on the client machine before starting Logo submission. For the tests under TerminalServer->Server category, t here is a test case selection UI and test suites can be defined using test profiles. The test is fully automated with Pass/Fail on each requirement.
Device classes covered by the test:
- Cellular phone devices
Drivers covered by the test include:
- Vendor (third-party) WPD drivers
The test validates the following for a WPD driver and the device connected to it:
- Device/driver passes these common scenarios for content types and formats that it supports:
  • Object hierarchy enumeration
  • Object property retrieval
  • Object resource reads from device
  • Object resource writes to device
  • Object deletion
  • Power management
  • Device/driver generated events
- Device/driver supports known function categories
- Device/driver supports required object properties and attributes
- Device/driver supports resources and attributes
Function Category Requirements
Cellular Handset:
    • Recommended:
      • WPD_FUNCTIONAL_CATEGORY_STORAGE,
      • WPD_FUNCTIONAL_CATEGORY_DEVICE,
      • WPD_FUNCTIONAL_CATEGORY_SMS
    • Optional:
      • WPD_FUNCTIONAL_CATEGORY_STILL_IMAGE_CAPTURE,
      • WPD_FUNCTIONAL_CATEGORY_AUDIO_CAPTURE
Content Type and Format Requirements
If a content type is not supported, the format support will not be verified. These are provided as a guideline, and there are not strict requirements on the format or content type, since this is typically a device firmware implementation detail.
The driver can report support for any format or content type, as long as it passes the functional scenario tests that use objects of formats that it supports, such as transfer, deletion and enumeration.
Cellular Handset
  • Recommended Content Type:WPD_CONTENT_TYPE_AUDIO
    • Recommended Formats:
      • WPD_OBJECT_FORMAT_WMA,
      • WPD_OBJECT_FORMAT_MP3
  • Optional Content Type: WPD_CONTENT_TYPE_VIDEO
    • Recommended Format: WPD_OBJECT_FORMAT_WMV
  • Optional Content Type: WPD_CONTENT_TYPE_IMAGE
    • Recommended Formats:
      • WPD_OBJECT_FORMAT_BMP,
      • WPD_OBJECT_FORMAT_EXIF,
      • WPD_OBJECT_FORMAT_GIF,
      • WPD_OBJECT_FORMAT_ICON,
      • WPD_OBJECT_FORMAT_JFIF,
      • WPD_OBJECT_FORMAT_JP2,
      • WPD_OBJECT_FORMAT_JPX,
      • WPD_OBJECT_FORMAT_PNG,
      • WPD_OBJECT_FORMAT_TIFF,
  • Optional Content Type: WPD_CONTENT_TYPE_DOCUMENT
    • Optional Formats:
      • WPD_OBJECT_FORMAT_HTML,
      • WPD_OBJECT_FORMAT_TEXT

Run Time: 60 minutes
Log File:
System Restart Required: Yes
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.
    • Unsupported Software:
  • XP or Windows Server 2003

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running Terminal Server PnP Device Redirection Framework Test Tool

More details are available in the Terminal Server PNP Redirection related lab setup documentation.
a) Update the inf file for your WPD Cellular phone driver by looking at the section mentioned "Authoring inf files for your device to support TS PNP device redirection"
b) Install this inf file on the Terminal Server server machine (This step can be skipped if you plan to use the inbox ts_generic.inf file and don’t need to update your inf file to support TS device redirection).
c) Connect a WPD Cellular Phone Device to the DTM Test Client Machine
d) Install the WPD Cellular Phone Driver for this device
e) Run the TerminalServer->Client->TS_PnpRedirection-WDK test which will redirect this device on the TS server
f) Go to Device Console and look at your TS server machine. You should be able to locate this TS redirected device in the "WPD" node on the left hand pane.
g) Select this device, and view the jobs under the "Portable Media Device (TS Redirection)" -> "Cellular Handsets" Category on the right hand pane.
Job names:
WPD Compliance Tests for Cell Phones (WDK)
WPD Compliance Stress Tests for Cell Phones (WDK)
  • Compliance Test: WPD Compliance Test (WDK)
  • Stress Test: WPD Compliance Stress Tests (WDK)
The compliance tests contain verification tests for the device class. The stress tests contain similar verification test, but will run continuously for long haul reliability testing.

Command Syntax

Command option | Description
 | Run From DTM

Cautions

For best results, run the test with one device connected at a time.
The TerminalServer->Client test creates a TS Session, don’t close this session or try killing TS client executable mstsc.exe before starting the TerminalServer->Server test. This session is required for TerminalServer->Server test to run.
Avoid modifying the following files:
- wdk.pro
- wdk_stress.pro
- propdef.xml

Troubleshooting

  • Check the text log file for any error logging.
  • Test supports a verbose logging mode in manual test case selection mode. When the application is running, in Options -> Logging Options, select "Destination: Window", Level: 2."
  • If no test cases are available from the test case selection tree, check that the device is plugged in.
  • If "no test cases selected": Check that device is plugged in before launching the test.

Terminal Server PNP Redirection WDK documentation and Terminal Server PNP Redirection lab setup documentation.

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

GENDev-22 Device and its driver is TS redirectable through a Terminal Server Session
Test Assertion GUID: {a83a3192-5d95-4ad5-9f3a-f65a72897aaa}

Windows Logo Program: DEVFUND-0010 Device and its driver supports redirection through a Terminal Services Session over the PnP Device Redirection Framework operates normally

Additional Information:


Media Transfer Protocol Compliance Test

Type: Automated Test

Overview

This test is for the Media Transfer Protocol (MTP) compliance. This suite of tests ensures that the devices that use the MTP class driver that ships with Microsoft Windows Vista and Microsoft Windows Server codenamed "Longhorn" comply with MTP implementation standards. This tool is directed at portable media devices that use the MTP protocol. This test helps to certify that these devices fulfill the requirements for the "Designed for Microsoft Windows" Logo Program for Hardware and work seamlessly with the Windows Portable Devices (WPD) stack as well as with Xbox 360, which can connect to MTP-enabled devices.
This test does not cover:
- Digital Rights Management
- Devices that do not use MTP, but use their own (third-party) drivers to work with the WPD stack

Details

This test (C# application) will run from the WDK or the command line. It logs to the test application window, a text file, and to an XML log file. It requires that an MTP-compatible device and driver are installed.
There is a test case selection UI and test suites can be defined using test profiles.
The test is fully automated with Pass/Fail on each requirement.
This test can be divided into the following four main functional categories:
Device Capabilities tests
Device Property tests
Object Property tests
Operations tests
This test will be fully automated with pass/fail on each aspect of MTP Protocol requirements that are tested.
Each of the four functional categories mentioned above contain child test cases, testing all the sub components that fall under the corresponding category.
The MTP device should be active and plugged in before commencing the test. The tool Mtpinfup.exe will update the driver for the attached MTP device to a signed test .inf file Mtptest.inf. On completion of the test, Mtpinfup.exe will update the driver back to the original in-box driver Wpdmtp.inf.
Also this test can optionally take an .xml file as a command line argument that lists the device requirements.
(Otherwise, it will default to a generic device requirement as specified in the MTP specification)

Run Time: 1 hour
Log File: MtpTestLog.log, MtpTestLog.xml
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • USB Controller

Running Media Transfer Protocol Compliance Test

Device Test Manager (DTM) test jobs are provided by logo category (either Silver or Gold). Though this test is used for testing the logo requirements compliance of cameras/camcorders, this can be used for any device that uses MTP protocol to communicate with the host PC using the default class installer
Cameras/Camcorders:
  • Cameras/Camcorders implementing PTP protocol (Silver Logo)
  • Cameras/Camcorders implementing MTP protocol (Gold Logo)

Command Syntax

Command option | Description
mtptest.exe | With no options launches the GUI
-a (or /a) | optional: Runs all test cases specified in the profile MTP-defaults.xml
-c (or /c) | optional: Quits after running test cases
-hct (or /hct) | optional: equivalent of /a + /c options
/r:PtpCamera.xml | optional: Ptp Camera: Reads device requirements from the specified PtpCamera.xml file in the current directory
/r:MtpCamera.xml | optional: Mtp Camera: Reads device requirements from the specified MtpCamera.xml file in the current directory
/r:pmp.xml | optional: Portable Media Player: Reads device requirements from the specified pmp.xml file in the current directory
/r:MtpCamera-recommended.xml | optional: Mtp Camera recommended: Reads device requirements from the specified .xml file in the current directory
/p:<testcasesprofile.xml> | optional: specify test cases to be run and the list of log devices

Cautions

Run test with only one device connected at a time.
For "Designed for Microsoft Windows" Logo Program for Hardware requirements, run the test with the provided test case selection profiles.
Do not modify these files:
PtpCamera.xml
MtpCamera.xml
TestGuids-defaults.xml
MtpCamera-recommended.xml
pmp.xml
PropertySpecifications.xm

Troubleshooting

Make sure that the device is plugged in and active before commencing the test.
Make sure the device shows up under Device Manager -> Windows Portable Devices.
Check the test log file for any error logging.
Log in as Administrator as this test will involve updating to a test driver and reverting back to the original driver.
The verbosity of log levels can be manually selected in the GUI (as well as the name of the log file).

Test application window also will log the test progress and failures. The WTT log file and text log file are also available.
Media Transfer Protocol Specification: http://go.microsoft.com/fwlink/?LinkId=48674 (Portable Media Devices Test Lab Setup Documentation, Camera Implementation Guideline in the porting kit)

Click to show or hide information. Test Assertions

Test Assertions

1 GOLD: Device supports the mandatory mtp operations, object properties and object formats
Test Assertion GUID: 19392760-9662-484c-a4b5-01b4cef0ffff

Windows Logo Program:

Additional Information: Portable-0003: Device supports the mandatory mtp commands, object properties and object formats.

1 SILVER: Digital still camera supports PTP (ISO 15740) in its firmware if it does not support MTP
Test Assertion GUID: 19392760-9662-484c-a4b5-01b4cef0ffff

Windows Logo Program:

Additional Information: Portable-0004: Digital still camera supports PTP (ISO 15740) in its firmware if it does not support MTP

2 GOLD and SILVER: All MTP and PTP Digital still camera connect to Windows by using inbox MTP class drivers and can transfer content to the PC
Test Assertion GUID: {7a355c3a-05fb-4ef8-a56e-cbfdd5c8d15e}

Windows Logo Program:

Additional Information: All MTP and PTP Digital still camera must work with inbox MTP drivers.Portable-0005: This test tests the device properties concepts (if supported) of MTP/ PTP Protocol

3 GOLD and SILVER: All MTP and PTP Digital still camera connect to Windows by using inbox MTP class drivers and can transfer content to the PC
Test Assertion GUID: ee6658ab-b567-4563-9dc7-4516db5398e1

Windows Logo Program:

Additional Information: All MTP and PTP Digital still camera must work with inbox MTP drivers.Portable-0005: This test tests the object properties concepts (if supported) of MTP Protocol. In the case of PTP devices all the tests will return ignored as the there is no concept of object properties in PTP protocol.

4 GOLD and SILVER: All MTP and PTP Digital still camera connect to Windows by using inbox MTP class drivers and can transfer content to the PC
Test Assertion GUID: 7e51f7de-7f3a-45fe-8f0e-9cace4b686f3

Windows Logo Program:

Additional Information: All MTP and PTP Digital still camera must work with inbox MTP drivers.Portable-0005: This test tests the operations (supported) of MTP / PTP Protocol.

5 GOLD: Digital still camera can capture the audio content in one of the Inbox Audio codec formats if it supports audio capture
Test Assertion GUID: 53c7c14d-5026-4ece-b6eb-08ce0b84ce85

Windows Logo Program:

Additional Information: Portable-0009: Digital still camera can capture the audio content in one of the Inbox Audio codec formats if it supports audio capture

6 GOLD: Digital still camera can capture the video content in one of the Inbox Video codec formats if it supports video capture
Test Assertion GUID: 70fe034b-20cf-482c-96f5-65f7dfc0ab29


Windows Portable Devices Inf Checker

Overview

You can use Windows Portable Devices (WPD) Inf Checker to verify INF files that are written for WPD devices. This tool verifies that the correct WPD registry entries are specified, values and types are valid, and the Windows Driver Framework (WDF) entries are correctly defined.

Details

The WPD Inf Checker test tool is designed to work with the INFChecker tool that is bundled with the Windows Driver Kit (WDK). The INFChecker tool is a Perl script that analyzes the specified INF file for errors. It is modularized so that class-specific checking can be handled by a class-specific Perl module.
The INFChecker tool selects the appropriate Perl module based on the class name that is present in the INF file. Because the class name for WPD devices is WPD, the WPD Perl module must be named WPD.pm so that the INFChecker main module will call it.
The structure of WPD.pm follows the other modules that are present in the INFChecker distribution.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running Windows Portable Devices Inf Checker

Install Perl from the ActiveState Web site.

Syntax

Chkinf.bat <inf_filename>
Replace <inf_filename> with the name of the WPD INF file to check for correctness. The WPD Perl module will be loaded automatically.

Output

The tool produces the results in HTML under a folder called "Htm". You can view the results by opening the Summary.htm file in the \Tools\Chkinf\Htm\ folder of the WDK.

Command Syntax

Command option | Description
chkinf.bat <path_to_inf> | <path_to_inf> is the complete path to the INF file to check.

Troubleshooting
For more information about using this tool, see the documentation for the ChkINF tool that is included in the WDK documentation.

Code Tour

File Manifest

File | Location
Wpd.pm | Tools/Chkinf

Click to show or hide information. Test Assertions

Test Assertions

E22.1.1010 ClassName is expected to be WPD
Test Assertion GUID:

E22.1.1310 Class WPD (ClassGUID {...GUID...}) is unrecognized
Test Assertion GUID:

DE22.26.2006 Reg-root HKR should be specified for 'EnableDefaultAutoPlaySupport' registry key
Test Assertion GUID:

DE22.26.2006 Reg-root HKR should be specified for 'EnableLegacySupport' registry key
Test Assertion GUID:

DE22.26.2006 Reg-root HKR should be specified for 'UseWiaAutoPlay' registry key
Test Assertion GUID:

DE22.26.2007 Illegal value for 'EnableDefaultAutoPlaySupport' registry key
Test Assertion GUID:

DE22.26.2007 Illegal value for 'EnableLegacySupport' registry key
Test Assertion GUID:

DE22.26.2007 Illegal value for 'UseWiaAutoPlay' registry key
Test Assertion GUID:

DE22.26.2008 Flag 0x10001 must be specified for 'EnableDefaultAutoPlaySupport' registry key
Test Assertion GUID:

DE22.26.2008 Flag 0x10001 must be specified for 'EnableLegacySupport' registry key
Test Assertion GUID:

DE22.26.2008 Flag 0x10001 must be specified for 'UseWiaAutoPlay' registry key
Test Assertion GUID:

DE22.26.2006 Reg-root HKR should be specified for 'CoInstaller32' registry key
Test Assertion GUID:

DE22.26.2008 Flag 0x10000 must be specified for 'CoInstaller32' registry key
Test Assertion GUID:

DE22.26.2016 'WUDFCOINSTALLER.DLL' must be listed as one of the co-installers
Test Assertion GUID:

DE22.26.2002 Section [DDInstall.Wdf] could not be found
Test Assertion GUID:

DE22.26.2010 Required directive 'UMDFSERVICE' could not be found
Test Assertion GUID:

DE22.26.2010 Required directive 'UMDFSERVICEORDER' could not be found
Test Assertion GUID:

DE22.26.2011 Illegal value for directive 'UmdfImpersonationLevel'
Test Assertion GUID:

DE22.26.2012 UmdfService should be in the form 'ServiceName, ServiceInstallSection'
Test Assertion GUID:

DE22.26.2013 Service name '...' has not been defined using the UmdfService directive
Test Assertion GUID:

DE22.26.2014 Service '...' has not been specified in the UmdfServiceOrder directive
Test Assertion GUID:

DE22.26.2017 Duplicate instance found for the 'UmdfServiceOrder' directive
Test Assertion GUID:

DE22.26.2012 UmdfLibraryVersion should be in the form '1.0.0'
Test Assertion GUID:

DE22.26.2015 Malformed GUID specified in DriverCLSID value
Test Assertion GUID:


Windows Portable Devices Driver Compliance Test

Type: Automated Test

Overview

Windows Portable Devices (WPD) Driver Verification Test/Stress tool is a suite of tests that exercises the driver using the WPD API and validates that it is compliant with the Windows Logo requirements.
The target audience for this tool is a third-party driver writer or device vendor who wants to verify that their driver or device fulfils the Windows Logo requirements to work seamlessly with the WPD stack in a protocol-independent way.
This test does not cover:
- Legacy driver testing. Only WPD class drivers will be tested.
- Device-protocol-specific requirements. This will be covered in separate certification tests.
- Digital Rights Management Testing

Details

The test runs as a C++ application and supports WTT Logging. There is a test case selection UI and test suites can be defined using test profiles.
The test is fully automated with Pass/Fail on each requirement.
Device classes covered by the test:
- Cellular phone devices
Drivers covered by the test include:
- Vendor (third-party) WPD drivers
The test validates the following for a WPD driver and the device connected to it:
- Device/driver passes these common scenarios for content types and formats that it supports:
  • Object hierarchy enumeration
  • Object property retrieval
  • Object resource reads from device
  • Object resource writes to device
  • Object deletion
  • Power management
  • Device/driver generated events
- Device/driver supports known function categories
- Device/driver supports required object properties and attributes
- Device/driver supports resources and attributes
Function Category Requirements
Cellular Handset:
    • Recommended:
      • WPD_FUNCTIONAL_CATEGORY_STORAGE,
      • WPD_FUNCTIONAL_CATEGORY_DEVICE,
      • WPD_FUNCTIONAL_CATEGORY_SMS
    • Optional:
      • WPD_FUNCTIONAL_CATEGORY_STILL_IMAGE_CAPTURE,
      • WPD_FUNCTIONAL_CATEGORY_AUDIO_CAPTURE
Content Type and Format Requirements
If a content type is not supported, the format support will not be verified. These are provided as a guideline, and there are not strict requirements on the format or content type, since this is typically a device firmware implementation detail.
The driver can report support for any format or content type, as long as it passes the functional scenario tests that use objects of formats that it supports, such as transfer, deletion and enumeration.
Cellular Handset
  • Recommended Content Type:WPD_CONTENT_TYPE_AUDIO
    • Recommended Formats:
      • WPD_OBJECT_FORMAT_WMA,
      • WPD_OBJECT_FORMAT_MP3
  • Optional Content Type: WPD_CONTENT_TYPE_VIDEO
    • Recommended Format: WPD_OBJECT_FORMAT_WMV
  • Optional Content Type: WPD_CONTENT_TYPE_IMAGE
    • Recommended Formats:
      • WPD_OBJECT_FORMAT_BMP,
      • WPD_OBJECT_FORMAT_EXIF,
      • WPD_OBJECT_FORMAT_GIF,
      • WPD_OBJECT_FORMAT_ICON,
      • WPD_OBJECT_FORMAT_JFIF,
      • WPD_OBJECT_FORMAT_JP2,
      • WPD_OBJECT_FORMAT_JPX,
      • WPD_OBJECT_FORMAT_PNG,
      • WPD_OBJECT_FORMAT_TIFF,
  • Optional Content Type: WPD_CONTENT_TYPE_DOCUMENT
    • Optional Formats:
      • WPD_OBJECT_FORMAT_HTML,
      • WPD_OBJECT_FORMAT_TEXT

Run Time: 60 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows XP
  • Software components included with the device that is being tested.
    • Unsupported Software:
  • Windows Server 2003

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • USB Controller

Running Windows Portable Devices Driver Compliance Test

More details are available in the "Portable Media Device" Test Lab Setup Documentation.
Setup:
  1. Connect a WPD Cellular Phone Device to the DTM Test Client Machine
  2. Install the WPD Cellular Phone Driver for this device
  3. From Device Console, locate this device in the "WPD" node on the left hand pane
  4. Select this device, and view the jobs under the "Portable Media Device" -> "Cellular Handsets" Category on the right hand pane.
Job names:
WPD Compliance Tests for Cell Phones (WDK)
WPD Compliance Stress Tests for Cell Phones (WDK)

Command Syntax

Command option | Description
None | Run from DTM

Cautions

For best results, run the test with one device connected at a time.
For Logo requirements, run the test with the provided test case selection profiles.
Avoid modifying the following files:
- wdk.pro
- wdk_stress.pro
- propdef.xml

Troubleshooting

  • Check the text log file for any error logging.
  • Test supports a verbose logging mode in manual test case selection mode. When the application is running, in Options -> Logging Options, select "Destination: Window", Level: 2."
  • If no test cases are available from the test case selection tree, check that the device is plugged in.
  • If "no test cases selected": Check that device is plugged in before launching the test.

Windows Portable Devices WDK Documentation, Portable Media Devices Test Lab Setup Documentation

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

D.1.P.1 Get Required Properties for Object: Device/driver should support reading of required property values for the device object.
Test Assertion GUID: {83F17050-228C-42E2-B698-9113CF8BECAF}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must return required property values with valid datatype for the device object when queried by the test application. For example, the device object must return a valid VT_LPWSTR value for the WPD_DEVICE_SERIAL_NUMBER property, unless WPD_RESOURCE_ATTRIBUTE_CAN_READ is VARIANT_FALSE for that property.

F.1.P.1 Get Required Properties for Object: Device/driver should support reading of required property values for function objects.
Test Assertion GUID: {83F17050-228C-42E2-B698-9113CF8BECAF}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must return required property values with valid datatype for the functional object when queried by the test application. For example, a storage function object of category WPD_FUNCTIONAL_CATEGORY_STORAGE must return a valid VT_UI8 value for the WPD_STORAGE_CAPACITY property, unless WPD_RESOURCE_ATTRIBUTE_CAN_READ is VARIANT_FALSE for that property.

C.1.P.1 Get Required Properties for Object: Device/driver should support reading of required property values for content objects.
Test Assertion GUID: {83F17050-228C-42E2-B698-9113CF8BECAF}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must return required property values with valid datatype for content objects when queried by the test application. For example, an object must return a valid VT_LPWSTR value for the WPD_OBJECT_NAME property, unless WPD_RESOURCE_ATTRIBUTE_CAN_READ is VARIANT_FALSE for that property.

D.4.P.4 Set Properties for Object: Device/driver should support updating of writable property values for the device object (if any)
Test Assertion GUID: {514FB00E-BCE0-4E40-B2AF-6A218B0DA608}

Windows Logo Program: ERROR ERROR

Additional Information: If the device object returns the attribute WPD_RESOURCE_ATTRIBUTE_CAN_WRITE = VARIANT_TRUE for a property, the test application must be able to write a new value to the property, or update an existing value if the property already exists for the device object. If no writable properties are supported the test case is skipped.

F.4.P.4 Set Properties for Object: Device/driver should support updating of writable property values for function objects (if any)
Test Assertion GUID: {514FB00E-BCE0-4E40-B2AF-6A218B0DA608}

Windows Logo Program: ERROR ERROR

Additional Information: If a function object returns the attribute WPD_RESOURCE_ATTRIBUTE_CAN_WRITE = VARIANT_TRUE for a property, the test application must be able to write a new value to the property, or update an existing value if the property already exists for the function object. If no writable properties are supported the test case is skipped.

C.4.P.4 Set Properties for Object: Device/driver should support updating of writable property values for content objects (if any)
Test Assertion GUID: {514FB00E-BCE0-4E40-B2AF-6A218B0DA608}

Windows Logo Program: ERROR ERROR

Additional Information: If a content object returns the attribute WPD_RESOURCE_ATTRIBUTE_CAN_WRITE = VARIANT_TRUE for a property, the test application must be able to write a new value to the property, or update an existing value if the property already exists for the content object. If no writable properties are supported the test case is skipped.

D.2.P.2 Get Recommended Properties for Object: Device/driver should support reading of recommended property values for the device object.
Test Assertion GUID: {6959C15F-6E17-4526-BD18-CB7488D1DF57}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must return recommended property values with valid datatype for the device object when queried by the test application. The test is skipped if the device object does not support any recommended properties.

F.2.P.2 Get Recommended Properties for Object: Device/driver should support reading of recommended property values for functional objects.
Test Assertion GUID: {6959C15F-6E17-4526-BD18-CB7488D1DF57}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must return recommended property values with valid datatype for function objects when queried by the test application. The test is skipped if the function objects do not support any recommended properties.

C.2.P.2 Get Recommended Properties for Object: Device/driver should support reading of required property values for content objects.
Test Assertion GUID: {6959C15F-6E17-4526-BD18-CB7488D1DF57}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must return recommended property values with valid datatype for content objects when queried by the test application. The test is skipped if content objects do not support any recommended properties.

C.1.T.1 Transfer N Files to device (Storage): Device/driver should support creation and writing of data to the required default resource for content objects
Test Assertion GUID: {86E987A3-461F-459D-BB50-0205439C30CB}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must be able to create multiple content objects containing WPD_RESOURCE_DEFAULT for required formats and content types. For example, a Portable Media Player device must support WPD_CONTENT_TYPE_AUDIO. It must be able to create content objects of WPD_OBJECT_FORMAT_WMA in a test parent folder, and write data to the WPD_RESOURCE_DEFAULT for each object. The lists of content types and formats for each device type are provided in "Content Type and Format Requirements" section of this document.

C.1.T.2 Transfer N Files from device (Storage): Device/driver should support reading of data from the required default resource for content objects
Test Assertion GUID: {8905E20D-8FA5-4CA3-8E3A-E0DCC7C44EFE}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must be able to transfer multiple content objects containing WPD_RESOURCE_DEFAULT to the test application on the PC. For example, a Portable Media Player device must support WPD_CONTENT_TYPE_AUDIO. It must be able to transfer the WPD_RESOURCE_DEFAULT resource data of WPD_OBJECT_FORMAT_WMA content objects to the PC. The lists of content types and formats for each device type are provided in "Content Type and Format Requirements" section of this document.

C.1.T.1 Transfer N Files to device (Storage): Device/driver should support creation and writing of data to the required default resource for content objects
Test Assertion GUID: {86E987A3-461F-459d-BB50-0205439C30CB}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must be able to create multiple content objects containing WPD_RESOURCE_DEFAULT for required formats and content types. For example, a Portable Media Player device must support WPD_CONTENT_TYPE_AUDIO. It must be able to create multiple content objects of WPD_OBJECT_FORMAT_WMA in a test parent folder, and write data to the WPD_RESOURCE_DEFAULT for each object. The lists of content types and formats for each device type are provided in "Content Type and Format Requirements" section of this document.

C.1.T.2 Transfer N Files from device (Storage): Device/driver should support reading of data from the required default resource for content objects
Test Assertion GUID: {8905E20D-8FA5-4CA3-8E3A-E0DCC7C44EFE}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must be able to create multiple content objects containing WPD_RESOURCE_DEFAULT for required formats and content types. For example, a Portable Media Player device must support WPD_CONTENT_TYPE_AUDIO. It must be able to create multiple content objects of WPD_OBJECT_FORMAT_WMA in a test parent folder, and write data to the WPD_RESOURCE_DEFAULT for each object. The lists of content types and formats for each device type are provided in "Content Type and Format Requirements" section of this document.

C.1.T.1 Transfer N Files to device (Storage): Device/driver should support creation and writing of data to the required default resource for content objects
Test Assertion GUID: {86E987A3-461F-459d-BB50-0205439C30CB}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must be able to create multiple content objects containing WPD_RESOURCE_DEFAULT for required formats and content types. For example, a Portable Media Player device must support WPD_CONTENT_TYPE_AUDIO. It must be able to create multiple content objects of WPD_OBJECT_FORMAT_WMA in a test parent folder, and write data to the WPD_RESOURCE_DEFAULT for each object. The lists of content types and formats for each device type are provided in "Content Type and Format Requirements" section of this document.

C.1.T.2 Transfer N Files from device (Storage): Device/driver should support reading of data from the required default resource for content objects
Test Assertion GUID: {8905E20D-8FA5-4CA3-8E3A-E0DCC7C44EFE}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must be able to create multiple content objects containing WPD_RESOURCE_DEFAULT for required formats and content types. For example, a Portable Media Player device must support WPD_CONTENT_TYPE_AUDIO. It must be able to create multiple content objects of WPD_OBJECT_FORMAT_WMA in a test parent folder, and write data to the WPD_RESOURCE_DEFAULT for each object. The lists of content types and formats for each device type are provided in "Content Type and Format Requirements" section of this document.

C.1.T.2 Transfer N Files from device (Storage): Device/driver should support reading of data from the required default resource for content objects
Test Assertion GUID: {8905E20D-8FA5-4CA3-8E3A-E0DCC7C44EFE}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must be able to create multiple content objects containing WPD_RESOURCE_DEFAULT for required formats and content types. For example, a Portable Media Player device must support WPD_CONTENT_TYPE_AUDIO. It must be able to create multiple content objects of WPD_OBJECT_FORMAT_WMA in a test parent folder, and write data to the WPD_RESOURCE_DEFAULT for each object. The lists of content types and formats for each device type are provided in "Content Type and Format Requirements" section of this document.

C.1.T.1 Transfer N Files to device (Storage): Device/driver should support creation and writing of data to the required default resource for content objects
Test Assertion GUID: {86E987A3-461F-459d-BB50-0205439C30CB}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must be able to create multiple content objects containing WPD_RESOURCE_DEFAULT for required formats and content types. For example, a Portable Media Player device must support WPD_CONTENT_TYPE_AUDIO. It must be able to create multiple content objects of WPD_OBJECT_FORMAT_WMA in a test parent folder, and write data to the WPD_RESOURCE_DEFAULT for each object. The lists of content types and formats for each device type are provided in "Content Type and Format Requirements" section of this document.

C.1.E.1 Enumerate N Existing Objects: Device/driver should support object enumeration
Test Assertion GUID: {9D82C27D-92E2-4476-8F1E-D719237F9C60}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must be able to return the list of LPWSTR object identifiers (ObjectIDs) of objects of a given content type and format in a parent folder.

C.1.P.1 Get Required Properties for Object: Device/driver should support reading of required property values for content objects.
Test Assertion GUID: {83F17050-228C-42E2-B698-9113CF8BECAF}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must return required property values with valid datatype for content objects when queried by the test application. For example, an object must return a valid VT_LPWSTR value for the WPD_OBJECT_NAME property, unless WPD_RESOURCE_ATTRIBUTE_CAN_READ is VARIANT_FALSE for that property.

C.1.D.1 Delete N Existing Files (Storage): Device/driver should support deletion of existing objects
Test Assertion GUID: {8CC68708-0BA8-48B9-A4CB-16E14F54BACE}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must be able to delete existing objects of a given content type and format from a folder, except when the object has the property WPD_OBJECT_CAN_DELETE = VARIANT_FALSE.

C.1.D.1 Delete N Existing Files (Storage): Device/driver should support deletion of existing objects
Test Assertion GUID: {8CC68708-0BA8-48B9-A4CB-16E14F54BACE}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must be able to delete existing objects of a given content type and format from a folder, except when the object has the property WPD_OBJECT_CAN_DELETE = VARIANT_FALSE.

C.1.T.2 Transfer N Files from device (Storage): Device/driver should support reading of data from the required default resource for content objects
Test Assertion GUID: {8905E20D-8FA5-4CA3-8E3A-E0DCC7C44EFE}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must be able to create multiple content objects containing WPD_RESOURCE_DEFAULT for required formats and content types. For example, a Portable Media Player device must support WPD_CONTENT_TYPE_AUDIO. It must be able to create multiple content objects of WPD_OBJECT_FORMAT_WMA in a test parent folder, and write data to the WPD_RESOURCE_DEFAULT for each object. The lists of content types and formats for each device type are provided in "Content Type and Format Requirements" section of this document.

C.1.T.1 Transfer N Files to device (Storage): Device/driver should support creation and writing of data to the required default resource for content objects
Test Assertion GUID: {86E987A3-461F-459D-BB50-0205439C30CB}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must be able to create multiple content objects containing WPD_RESOURCE_DEFAULT for required formats and content types. For example, a Portable Media Player device must support WPD_CONTENT_TYPE_AUDIO. It must be able to create multiple content objects of WPD_OBJECT_FORMAT_WMA in a test parent folder, and write data to the WPD_RESOURCE_DEFAULT for each object. The lists of content types and formats for each device type are provided in "Content Type and Format Requirements" section of this document.

C.1.E.1 Enumerate N Existing Objects: Device/driver should support object enumeration
Test Assertion GUID: {9D82C27D-92E2-4476-8F1E-D719237F9C60}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must be able to return the list of LPWSTR object identifiers (ObjectIDs) of objects of a given content type and format in a parent folder.

C.1.T.1 Transfer N Files to device (Storage): Device/driver should support creation and writing of data to the required default resource for content objects
Test Assertion GUID: {86E987A3-461F-459D-BB50-0205439C30CB}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must be able to create multiple content objects containing WPD_RESOURCE_DEFAULT for required formats and content types. For example, a Portable Media Player device must support WPD_CONTENT_TYPE_AUDIO. It must be able to create multiple content objects of WPD_OBJECT_FORMAT_WMA in a test parent folder, and write data to the WPD_RESOURCE_DEFAULT for each object. The lists of content types and formats for each device type are provided in "Content Type and Format Requirements" section of this document.

C.1.T.2 Transfer N Files from device (Storage): Device/driver should support reading of data from the required default resource for content objects
Test Assertion GUID: {8905E20D-8FA5-4CA3-8E3A-E0DCC7C44EFE}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must be able to create multiple content objects containing WPD_RESOURCE_DEFAULT for required formats and content types. For example, a Portable Media Player device must support WPD_CONTENT_TYPE_AUDIO. It must be able to create multiple content objects of WPD_OBJECT_FORMAT_WMA in a test parent folder, and write data to the WPD_RESOURCE_DEFAULT for each object. The lists of content types and formats for each device type are provided in "Content Type and Format Requirements" section of this document.

C.1.P.1 Get Required Properties for Object: Device/driver should support reading of required property values for content objects.
Test Assertion GUID: {83F17050-228C-42E2-B698-9113CF8BECAF}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must return required property values with valid datatype for content objects when queried by the test application. For example, an object must return a valid VT_LPWSTR value for the WPD_OBJECT_NAME property, unless WPD_RESOURCE_ATTRIBUTE_CAN_READ is VARIANT_FALSE for that property.

C.1.P.1 Get Required Properties for Object: Device/driver should support reading of required property values for content objects.
Test Assertion GUID: {83F17050-228C-42E2-B698-9113CF8BECAF}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must return required property values with valid datatype for content objects when queried by the test application. For example, an object must return a valid VT_LPWSTR value for the WPD_OBJECT_NAME property, unless WPD_RESOURCE_ATTRIBUTE_CAN_READ is VARIANT_FALSE for that property.

C.1.E.1 Enumerate N Existing Objects: Device/driver should support object enumeration
Test Assertion GUID: {9D82C27D-92E2-4476-8F1E-D719237F9C60}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must be able to return the list of LPWSTR object identifiers (ObjectIDs) of objects of a given content type and format in a parent folder.

C.1.E.1 Enumerate N Existing Objects: Device/driver should support object enumeration
Test Assertion GUID: {9D82C27D-92E2-4476-8F1E-D719237F9C60}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must be able to return the list of LPWSTR object identifiers (ObjectIDs) of objects of a given content type and format in a parent folder.

D.1.NS.1 No devices found: Device should be accessible from the WPD API
Test Assertion GUID: {5C39B51F-ED43-4351-A16D-EC5DAB5BA18A}

F.1.NS.1 Function Category Not Supported: Required functional categories should be supported
Test Assertion GUID: {35A06211-EC2C-491b-9535-F04A1D949671}

F.1.NS.1 Function Category Not Supported: Required functional categories should be supported
Test Assertion GUID: {35A06211-EC2C-491b-9535-F04A1D949671}

C.1.D.1 Delete N Existing Files (Storage): Device/driver should support deletion of existing objects
Test Assertion GUID: {8CC68708-0BA8-48b9-A4CB-16E14F54BACE}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must be able to delete existing objects of a given content type and format from a folder, except when the object has the property WPD_OBJECT_CAN_DELETE = VARIANT_FALSE.

C.1.T.2 Transfer N Files from device (Storage): Device/driver should support reading of data from the required default resource for content objects
Test Assertion GUID: {8905E20D-8FA5-4ca3-8E3A-E0DCC7C44EFE}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must be able to create multiple content objects containing WPD_RESOURCE_DEFAULT for required formats and content types. For example, a Portable Media Player device must support WPD_CONTENT_TYPE_AUDIO. It must be able to create multiple content objects of WPD_OBJECT_FORMAT_WMA in a test parent folder, and write data to the WPD_RESOURCE_DEFAULT for each object. The lists of content types and formats for each device type are provided in "Content Type and Format Requirements" section of this document.

C.1.T.1 Transfer N Files to device (Storage): Device/driver should support creation and writing of data to the required default resource for content objects
Test Assertion GUID: {86E987A3-461F-459d-BB50-0205439C30CB}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must be able to create multiple content objects containing WPD_RESOURCE_DEFAULT for required formats and content types. For example, a Portable Media Player device must support WPD_CONTENT_TYPE_AUDIO. It must be able to create multiple content objects of WPD_OBJECT_FORMAT_WMA in a test parent folder, and write data to the WPD_RESOURCE_DEFAULT for each object. The lists of content types and formats for each device type are provided in "Content Type and Format Requirements" section of this document.

C.1.D.1 Delete N Existing Files (Storage): Device/driver should support deletion of existing objects
Test Assertion GUID: {8CC68708-0BA8-48b9-A4CB-16E14F54BACE}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must be able to delete existing objects of a given content type and format from a folder, except when the object has the property WPD_OBJECT_CAN_DELETE = VARIANT_FALSE.

C.1.T.2 Transfer N Files from device (Storage): Device/driver should support reading of data from the required default resource for content objects
Test Assertion GUID: {8905E20D-8FA5-4ca3-8E3A-E0DCC7C44EFE}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must be able to create multiple content objects containing WPD_RESOURCE_DEFAULT for required formats and content types. For example, a Portable Media Player device must support WPD_CONTENT_TYPE_AUDIO. It must be able to create multiple content objects of WPD_OBJECT_FORMAT_WMA in a test parent folder, and write data to the WPD_RESOURCE_DEFAULT for each object. The lists of content types and formats for each device type are provided in "Content Type and Format Requirements" section of this document.

C.1.T.1 Transfer N Files to device (Storage): Device/driver should support creation and writing of data to the required default resource for content objects
Test Assertion GUID: {86E987A3-461F-459d-BB50-0205439C30CB}

Windows Logo Program: ERROR ERROR

Additional Information: Device/driver must be able to create multiple content objects containing WPD_RESOURCE_DEFAULT for required formats and content types. For example, a Portable Media Player device must support WPD_CONTENT_TYPE_AUDIO. It must be able to create multiple content objects of WPD_OBJECT_FORMAT_WMA in a test parent folder, and write data to the WPD_RESOURCE_DEFAULT for each object. The lists of content types and formats for each device type are provided in "Content Type and Format Requirements" section of this document.

F.1.E.1 Enumerate Function Objects using IPortableDeviceCapabilities
Test Assertion GUID: {514FB00E-BCE0-4E40-B2AF-6A218B0DA608}

Content Type Not Supported: Required content types should be supported
Test Assertion GUID: {2FF08A84-5032-4af4-8667-C689DF0D7F2B}


WMDM Content Transfer Test

Overview

This test verifies that WMA content can be transferred to the device you are testing by using WMDM API.

Details

The test runs as a C++ application. There is a test case selection user interface, and test suites can be defined using test profiles.
The test is fully automated with pass/fail on each requirement.
Device classes covered by the test:
- Media Transfer Protocol class devices
- Mass storage class devices
Drivers covered by the test include:
- Microsoft class drivers
- Vendor (third-party) 'Windows Portable Devices' drivers that can be discovered through the WMDM layer
The test requirements are the following:
- WMA Content Transfer
- WMA Content Transfer along with metadata
- Device storage format and transfer
- Stress test

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86

Running WMDM Content Transfer Test

Two test jobs are available from the Device Test Manager (DTM):
- Functional test
- Stress test: Device is filled up with content, and all content is then removed. This cycle is repeated.
The test application can also be launched manually with these command options:
Nonstress mode:
  • wmdmcopy.exe -a -r profile_name
where profile_name may be wmdmcopy_xferwma.pro, wmdmcopy_xfermetawma.pro, wmdmcopy_format.pro
Stress mode (continuous):
  • TestApp.exe -a -r wmdmcopy_stress.pro

Command Syntax

Command option | Description
wmdmcopy.exe -a -r wmdmcopy_xferwma.pro | Runs the WMA transfer test cases.
wmdmcopy.exe -a -r wmdmcopy_xfermetawma.pro | Runs the WMA with metadata transfer test cases.
wmdmcopy.exe -a -r wmdmcopy_format.pro | Runs the device storage format and transfer test cases.
wmdmcopy.exe -a -r wmdmcopy_stress.pro | Runs the stress test cases against the device.

Click to show or hide information. Test Assertions

Test Assertions

35.6.4 The device responds correctly to a format request.
Test Assertion GUID:

35.3.1 Content can be transferred to the device.
Test Assertion GUID:

35.3.2 Content can be transferred to the device along with metadata.
Test Assertion GUID:

35.1.4 Device handles stress well.
Test Assertion GUID:


Printer Testing Overview

The procedures presented in this section outline the process for testing your printer for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as required for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

Printer Tests

The list of tests you need to run depend upon the capabilities of the device being tested. To see the complete list of tests that could be required for your device, see the Printer Tests

Run time: approximately <TBD> hours

Hardware requirements

The following hardware is required for Printer testing. Additional hardware may be required if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • Basic WDK Test Setup (Controller, Studio, and Client systems)
  • At least one printer installed on a Client system (locally or over the network)

Other hardware may be required to enable certain scenarios, but it is not required to test a device and create a submission package.

  • Kernel Debugger system attached to the WDK Client
  • Print Server to test print server configurations

Software requirements

It is good practice to clean install the OS on Client systems before final test passes to ensure the system is in a known clean state.

The following software is required to run the Printer tests:

  • Install correct OS build on the WDK Client for intended Logo program
  • AppVerifier – see below for details
  • The driver package being tested installed on a Client System

For Beta 2 of the OS you will need to manually install AppVerifier on client systems in order for the tests to work properly and pass. AppVerifier can be downloaded from the link below. Install AppVerifier on all client systems. The WDK tests will launch AppVerifier as needed. Uninstalling the kit will not uninstall [image] AppVerifier.

Tester knowledge requirements

To run the Printer tests, testers must know how to accomplish the following tasks:

  • Install a printer on a Client system
  • Use WDK Studio to create new submissions and package results


Preparing for Printer Testing

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see the Printer Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, see Running with autologon enabled.

Test system configuration

The Printing test kit uses a basic WDK lab setup. Once the controller has been setup, and a machine pool has been created you need to apply the Printing config dimension to the pool before adding any client systems to the pool.

  1. Right click the pool and choose properties
  2. Choose the “MCU Policy” tab from the pool properties menu
  3. Choose the “Wdk\ConfigurePrinting” dimension and add it to the pool
  4. Click “Apply” and then “OK”


Running the Printer Tests

Follow the general directions for creating a new logo submission and scheduling jobs found in the WDK documentation.


Troubleshooting Printer Testing

Refer to the specific test documentation for troubleshooting help.


Print Tests

Test name | Target operating system | Test description
Validate Color Profiles | Windows Vista | This test validates that color profiles can be used by Windows and that the color profile meets basic profile file format requirements.
TCPMon Bidi Extension File Validation Test | Windows Vista | This tool validates a printer driver's Standard Port Monitor Bi-Di extension file to ensure that the file is well formed and syntactically correct.
INFGate | Windows Vista | INFGate is the tool of syntax checking for INF file of printing and imaging device drivers.
WSDMon Bidi Extension File Validation Test | Windows Vista | This tool validates a printer driver's Web Services for Devices Port Monitor Bi-Di extension file to ensure that the file is well formed and syntactically correct.
Windows Color Management Plugin Roboustness Test | Windows Vista | This tool tests the robustness of WCS color plugins to ensure the plugins are well behaved, do not crash in edge cases, and are not vulnerable to fuzzing.
TCP Printer SNMP MIBs Test | Windows Vista | This test tool verifies that a TCP/IP printer supports the Printer Port Monitor MIB v1.0. The test tool also verifies that the printer supports the minimum components of the Host Resources MIB and Printer MIB required by the Standard TCP/IP Port Monitor.
Print WinColor Test | Windows Vista | This test validates that a color printers conforms to the Windows Color Compliancy requirements for printers. For more information about the Windows Color Compliancy requirements, please refer to http://www.microsoft.com/whdc/device/display/color/ColorTest.mspx.
GDLCheck | Windows Vista | This tool is a GDL syntax checker that allows you to parse and load GDL files, specify configurations, and obtain XML snapshots. All parsing errors and debug output are sent to gdlcheck.xml. The command-line arguments are processed in order from left to right. Each argument is separated from the next with a space character. All options need to be specified before specifying the GDL root file name.


Validate Color Profiles

Type: Automated Test

Overview

This test validates that color profiles can be used by Windows and that the color profile meets basic profile file format requirements.

Details

The test verifies that the color profile associated with a device can be opened using OpenColorProfile() and WcsOpenColorProfile(), that a color transform can be created using the color profiles, and that color profile meets basic file format requirements. The test does NOT perform any color quality or fidelity testing.
Run Time: 30 seconds
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running Validate Color Profiles

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


TCPMon Bidi Extension File Validation Test

Type: Automated Test

Overview

This tool validates a printer driver's Standard Port Monitor Bi-Di extension file to ensure that the file is well formed and syntactically correct.

Details

The tool will validate the custom extension file and it will dump any xml contents that are deemed invalid. The tool can be run against an installed printer or a static file. If the tool is run against an installed printer, it will check if the printer driver has a Bi-Di extension file defined for WSDMon. If the file is defined, it will be loaded and verified. If the tool is run against a static file, the file specified will be loaded and verified.
Run Time: 10 seconds
Log File: TcpBidiXsdVerifyLog.xml
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements

    • Processor

  • x86
  • x64
  • Itanium

Running TCPMon Bidi Extension File Validation Test

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

DEV-PRNT-62 Printer drivers must be correctly implemented according to the rules of the Windows Driver Development kit (TCPBIDI.XSD Validation Utility). DEV-PRNT-62 Custom extension file complies with TCPBIDI.XSD.
Test Assertion GUID: 8e7e476c-b025-4062-9642-a4cbe272dea1

Windows Logo Program: IMAGING-0030 Printer drivers must be correctly implemented based on the content of the WDK

Additional Information:


INFGate

Overview

INFGate is the tool of syntax checking for INF file of printing and imaging device drivers.

Details

INFGate is the tool of syntax checking for INF file of printing and imaging device drivers. This tool is successor of part of the current CHKINF which is used for the driver development and testing now a day.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Windows keyboard

    • Processor

  • x86
  • x64
  • Itanium

Running INFGate

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WSDMon Bidi Extension File Validation Test

Type: Automated Test

Overview

This tool validates a printer driver's Web Services for Devices Port Monitor Bi-Di extension file to ensure that the file is well formed and syntactically correct.

Details

The tool will validate the custom extension file and it will dump any xml contents that are deemed invalid. The tool can be run against an installed printer or a static file. If the tool is run against an installed printer, it will check if the printer driver has a Bi-Di extension file defined for WSDMon. If the file is defined, it will be loaded and verified. If the tool is run against a static file, the file specified will be loaded and verified.
Run Time: 10 seconds
Log File: WSDBidiXsdVerifyLog.xml
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements

    • Processor

  • x86
  • x64
  • Itanium

Running WSDMon Bidi Extension File Validation Test

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

DEV-PRNT-62 Printer drivers must be correctly implemented according to the rules of the Windows Driver Development kit (WSDBIDI.XSD Validation Utility). DEV-PRNT-62 Custom extension file complies with WSDBIDI.XSD.
Test Assertion GUID: f1a7ade4-4b84-426c-b63c-579d191d11bb

Windows Logo Program: IMAGING-0030 Printer drivers must be correctly implemented based on the content of the WDK

Additional Information:


Windows Color Management Plugin Roboustness Test

Type: Automated Test

Overview

This tool tests the robustness of WCS color plugins to ensure the plugins are well behaved, do not crash in edge cases, and are not vulnerable to fuzzing.

Details

The test enumerates all installed color profiles and tests all installed plugins that are referenced by any installed Device Model profile or Gamut Map Model profile. Profiles must be installed and plugins must be registered through standard COM procedures before the test is run. Because all installed profiles are tested, some may need to be removed before running the test in order to avoid failures from different parties plugins. The test may issue helpful warning messages about suspect plugin behavior during the test, but by not crashing, a plugin passes the robustness test.

Run Time:
Log File: Logfile.xml
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements

    • Processor

  • x86
  • Itanium

Running Windows Color Management Plugin Roboustness Test

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

Device that uses an ICC or WCS XML profile properly installs the profile and is compliant with the appropriate profile specification
Test Assertion GUID:

Windows Logo Program: DEVFUND-0018 Device that uses an ICC or WCS XML profile properly installs the profile and is compliant with the appropriate profile specification

Additional Information:


TCP Printer SNMP MIBs Test

Type: Automated Test

Overview

This test tool verifies that a TCP/IP printer supports the Printer Port Monitor MIB v1.0. The test tool also verifies that the printer supports the minimum components of the Host Resources MIB and Printer MIB required by the Standard TCP/IP Port Monitor.

Details

This test will perform SNMP queries on the device under test. It will verify that the device supports the minimum components of the Host Resources MIB and Printer MIB used by the Standard TCP/IP Port Monitor to query device status. It will also verify that the device supports the Printer Port Monitor MIB that is required for port installation and configuration by the Standard TCP/IP Port Monitor.
Run Time: 10 seconds
Log File: PPMMibVerifyLog.xml
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements

    • Processor

  • x86
  • x64
  • Itanium

Running TCP Printer SNMP MIBs Test

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

DEV-PRNT-62 Printer drivers must be correctly implemented according to the rules of the Windows Driver Development kit (Printer Port Monitor MIB v1.0 Verification Utility) DEV-PRNT-62 TCP/IP Printer Supports the required SNMP MIBs required by the Standard TCP/IP Port Monitor. This includes the Printer Port Monitor MIB and some components defined in the Host Resources MIB and Printer MIB.
Test Assertion GUID: 23c7658f-0f28-4a0a-bc2d-b89b8a24f34d

Windows Logo Program: IMAGING-0030 Premium system includes necessary devices and functionalityPrinter drivers must be correctly implemented based on the content of the WDK

Additional Information:


Print WinColor Test

Type: Automated Test

Overview

This test validates that a color printers conforms to the Windows Color Compliancy requirements for printers. For more information about the Windows Color Compliancy requirements, please refer to http://www.microsoft.com/whdc/device/display/color/ColorTest.mspx.

Details

The test prints a series of color patches. Each color patch must be measured using a colorimeter. The measurement is then entered for that color patch. After all color patches have been measured, the test does a difference calculation between the expected measured values for a standard and the actual measured values. The difference is then averaged and square root summed. If the average or square root sum is greater than the Windows Color Compliancy requirements allow, a failure is reported. For more information of the methods used and the calculations, please refer to http://www.microsoft.com/whdc/device/display/color/ColorTest.mspx .
Run Time: 10 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running Print WinColor Test

Command Syntax

Command option | Description

Troubleshooting
http://www.microsoft.com/whdc/device/display/color/ColorTest.mspx

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


GDLCheck

Overview

This tool is a GDL syntax checker that allows you to parse and load GDL files, specify configurations, and obtain XML snapshots. All parsing errors and debug output are sent to gdlcheck.xml. The command-line arguments are processed in order from left to right. Each argument is separated from the next with a space character. All options need to be specified before specifying the GDL root file name.

Details

This test tool runs either from the LDK or standalone from the command prompt. It logs results to a WTT log file and can be configured to log at different verbosity levels. The tool requires the root GPD/GDL file being validated along with any additional GPD/GDL files that the root file references.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Computer that meets the minimum software requirements

    • Processor

  • x86
  • x64
  • Itanium

Running GDLCheck

All debug output resulting from executing GDLCheck is written to GDLCheck.xml.
1. "GDLCheck.exe -b -C -c basic.gdl"
The above usage will produce an XML snapshot using the default device and doc configurations. The snapshot can be found in GDLsnapshot.xml. The basic.gdl implements the basic features necessary to satisfy the root construct productions defined in stdschem.gdl. The debug output from specifying the -b option is shown below.
==== Validated Configuration ====

PaperSize:LETTER

Resolution:Option1

RESDLL:UniresDLL

InputBin:UPPER
If you execute the same usage with hplj5si.gdl, you will see the debug output shown below.
==== Validated Configuration ====

Memory:4096KB

PrinterHardDisk:FALSE

DuplexUnit:Installed

PageProtect:OFF
==== Validated Configuration ====

Memory:4096KB

PrinterHardDisk:FALSE

DuplexUnit:Installed

PageProtect:OFF

PaperSize:LETTER

Orientation:PORTRAIT

Duplex:NONE

Resolution:Option1

Halftone:HT_PATSIZE_AUTO

RESDLL:UniresDLL

OutputBin:Option1

Collate:OFF

Stapling:Option1

InputBin:Option1
2. "GDLCheck.exe -s -x basic.gdl"
The above usage will produce the schema for the XML snapshot but not the snapshot itself. The schema can be found in GDLschema.xsd. This usage depicts the usage of the -s option as well as the -x option which turns off snapshot creation. The default behavior of gdlcheck when the -x option is omitted is to produce the XML snapshot.
3. "GDLCheck.exe -ppreface.gdl -b -C -c basic.gdl"
The above usage depicts how you can use the -p option in gdlcheck to specify a preface file. In order to perform the above test, you should comment out or remove the line "*Include: "stdschmx.gdl" from basic.gdl since preface.gdl already includes this line. The result of executing the above command is expected to be identical to that seen in example scenario 1.
4. "GDLCheck.exe -f -x synfea.gdl"
The above usage depicts how you can use the -f option to verify the creation of synthesized features. The debug output from executing the above command is shown below. Since the -x option is used above, the XML snapshot will not be created.
Output for "GDLCheck.exe -f -x synfea.gdl":
=== Begin Contents of Synthesized Features Buffer ===
*Feature: SynFea_InputBinENVFEED

{

*FeatureType: SYNTHESIZED_PROPERTY

*Name: "Optional Envelope Feeder"

*Option: NotInstalled

{

*Name: "Not installed"

*Constraints: InputBin.ENVFEED

}

*Option: Installed

{

*Name: "Installed"

}

}
=== End Contents of Synthesized Features Buffer ===

Note that the -x option not a requirement to use the -f option. You could also have a usage like "GDLCheck.exe -f -b -C -c synfea.gdl". The debug output from executing this command is shown below.
Output for "GDLCheck.exe -f -b -C -c synfea.gdl":
=== Begin Contents of Synthesized Features Buffer ===
*Feature: SynFea_InputBinENVFEED

{

*FeatureType: SYNTHESIZED_PROPERTY

*Name: "Optional Envelope Feeder"

*Option: NotInstalled

{

*Name: "Not installed"

*Constraints: InputBin.ENVFEED

}

*Option: Installed

{

*Name: "Installed"

}

}
=== End Contents of Synthesized Features Buffer ===
==== Validated Configuration ====

SynFea_InputBinENVFEED:NotInstalled
==== Validated Configuration ====

SynFea_InputBinENVFEED:NotInstalled

PaperSize:LETTER

Resolution:Option1

RESDLL:UniresDLL

InputBin:UPPER
5. "GDLCheck.exe -b -CMemory.8192KB:PrinterHardDisk.TRUE -cOrientation.LANDSCAPE_CC90:Resolution.Option2:PaperSize.LEGAL hplj5si.gdl"
The above usage depicts how you can use the -C and -c options to define the device and document configurations. The usage of these options in example scenario 1 will result in the default configurations being used. But the usage shown here illustrates how you can define your own configurations. The debug output from executing the above command is shown below.
==== Validated Configuration ====

Memory:8192KB

PrinterHardDisk:TRUE

DuplexUnit:Installed

PageProtect:OFF
==== Validated Configuration ====

Memory:8192KB

PrinterHardDisk:TRUE

DuplexUnit:Installed

PageProtect:OFF

PaperSize:LEGAL

Orientation:LANDSCAPE_CC90

Duplex:NONE

Resolution:Option2

Halftone:HT_PATSIZE_AUTO

RESDLL:UniresDLL

OutputBin:Option1

Collate:OFF

Stapling:Option1

InputBin:Option1
6. The -n argument in GDLCheck can be used to validate more than one root GDL file within a single execution of GDLCheck. The syntax for this will be as shown below. This example also illustrates the use of the -y option that is used to specify a personality for the generation of the personality aware XML snapshot.
"GDLCheck.exe -pc:\test\preface.gdl -b -C -c c:\test\basic.gdl -1 -pc:\test\preface.gdl -b -v1 -yPersona1 -s -C -c c:\test\personatest.gdl"

Command Syntax

Command option | Description
GDLCheck.exe |
[-pPrefaceFile] | Optional; Name of the file (with full path) that holds the preface.
[-vn] | Optional; Specifies the verbosity level of the GDL parser where n is a number from 0 to 4. -v4 is the most verbose and -v0 is the least verbose. If this flag is not specified, the default is -v2.
[-yPersonality] | Optional; Specifies a personality and generates a personality aware XML snapshot. -y enables all personalities.
[-f] | Optional; Display synthesized features
[-s] | Optional; Generate schema (GDLSchema.xsd) for XML snapshot
[-x] | Optional; Do not generate XML snapshot. The XML snapshot is generated by default and saved to GDLSnapshot.xml.
[-w] | Optional; Generate UTF-16 XML snapshot. Default is UTF-8
[-d] | Optional; Display only doc sticky features in XML snapshot. Default is all features.
[-b] | Optional; Display validated configuration for debug purposes.
[-n] | Optional; Changes the parser context where n is a number from 0 to 9. Initial context is 0.
[-C[Feature1.Option1:Feature2.Option2:Feature3.Option3]] | Optional; Define device configuration.
[-c[Feature1.Option1:Feature2.Option2:Feature3.Option3]] | Optional; Define doc configuration.
<GDL root file name> | Required; Name of the root GDL file (with full path) being validated.

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Storage Testing

This section describes how to test storage devices and controllers in order to qualify them for the "Designed for Windows" logo.

Storage > Controller or Adapter Testing

Storage > CD or DVD Drive Testing

Storage > Hard Drive Testing

Storage > Media Changer Device Testing

Storage > RAID Testing

Storage > Removable Media Testing

Storage > Tape Drive Testing


Storage > Controller or Adapter Testing

This section describes how to test storage controllers in order to qualify them for the "Designed for Windows" logo. To complete logo testing, you must install and run the Device Test Manager and setup your testing environment. For information on installing and configuring the Device Test Manager, see Installing Driver Test Manager.

For information on setting up the test environment for your storage controller and running the storage controller tests, select one of the following storage controller categories:

ATA Controller Testing Overview

ATA-RAID Controller Testing Overview

Fibre Channel Controller Testing Overview

iSCSI Boot Component Testing Overview

iSCSI HBA Controller Testing Overview

SAS Controller Testing Overview

SAS-RAID Controller Testing Overview

SCSI Controller Testing Overview

SCSI-RAID Controller Testing Overview

Serial ATA Controller Testing Overview

Serial ATA-RAID Controller Testing Overview


ATA/ATAPI Controller Testing Overview

These procedures test your ATA/ATAPI controller for proper functionality by using the Microsoft Windows Driver Kit (WDK) and the Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as required for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

The test procedures are divided into the following types of topics:

  • Overview: The overview topics describe the hardware, software, and tester knowledge requirements.
  • Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.
  • Running: The running topics describe how to run the tests for your device or system.

ATA/ATAPI Controller Tests

The tests that you need to run depend on the capabilities of the device or system that is being tested. The following list contains all of the tests that you might need for your test device:

  • Crashdump Support Test
  • Storage Data Verification Filter Test
  • DMA Test
  • Int 13h Extensions test
  • Storage Device Stress test (SDStress)
  • Tape I/O Test
  • Driver Verifier
  • Device Path Exerciser
  • System - Sleep Stress with IO
  • System - Disable Enable with IO
  • Plug and Play Driver Test
  • Prefast for Drivers
  • Static Driver Verifier
  • Stress Test
  • Core Stress Test

Run time: approximately 2 hours

Note The test descriptions are included in a separate section.

Hardware Requirements

The following hardware is required for ATA/ATAPI Controller testing. You might need additional hardware if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One computer with the following:
    • Dual-core or equivalent processor (Windows Vista or Windows XP)
    • Quad-core or equivalent processor (Windows Longhorn Server or Windows Server 2003)
    • 2 GB memory (Windows Vista or Windows XP)
    • 6 GB memory (Windows Longhorn Server or Windows Server 2003)
    • Logo-compliant ACPI BIOS, with ACPI enabled by default

  • ATA/ATAPI controller (the test device).
  • One UDMA ATA/ATAPI hard disk drives with at least a 10 GB capacity.
  • One DMA-capable ATA/ATAPI CD-ROM drive, with a minimum speed of 8x.
  • One DMA-capable ATA/ATAPI DVD-ROM drive.
  • One ATA/ATAPI CD-RW drive.
  • One blank CD-RW.
  • One ATA/ATAPI removable media drive.
  • One blank piece of media.
  • One ATA/ATAPI tape drive.
  • One blank tape cartridge that is prepared for use.
  • One blank floppy disk.
  • Two standard ATA/ATAPI cables.

    Note ATA-66 and ATA-100 controllers require 80-conductor cables.

Software Requirements

The following software is required to run the ATA/ATAPI Controller tests:

  • Microsoft Windows Vista
  • Microsoft Windows XP Professional with Service Pack 2 (SP2)
  • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
  • Microsoft Windows Server 2003, Datacenter Edition, with SP1
  • Microsoft Windows XP Professional x64 Edition
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows Server 2003, Datacenter x64 Edition
  • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
  • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems
  • Any drivers that are not shipped with the operating system
  • The current release of the Microsoft Windows Driver Kit (WDK)

Tester Knowledge Requirements

To run the ATA/ATAPI Controller tests, testers must know how to accomplish the following tasks:

  • Install a boot-capable, add-in controller adapter.
  • Install a hard disk drive as a boot drive.
  • Format and partition a hard disk.
  • Install a CD-ROM drive as Device 1.
  • Install a CD-RW drive as Device 1.
  • Install an ATA/ATAPI tape drive as Device 0.
  • Prepare a blank tape cartridge for use.
  • Install a removable media drive as Device 1.
  • Format and partition a removable media drive.
  • Install a DVD-ROM drive as Device 1.
  • Access and change the system BIOS settings.
  • Install and use Microsoft Debugging Tools for Windows.
  • Install and use Microsoft Windows Symbols files.
  • Install the operating system from the product CD.

After you have reviewed the necessary requirements, you can prepare to test your ATA/ATAPI controller device.

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Preparing to Test ATA/ATAPI Controllers

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see ATA/ATAPI Controller Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, For more information about autologon, see [image] How to turn on automatic logon in Windows XP.

The following topics describe the two configurations for testing ATA/ATAPI Controllers:

Preparing to Test ATA/ATAPI Controllers in Configuration 1

Preparing to Test ATA/ATAPI Controllers in Configuration 2


Preparing to Test ATA/ATAPI Controllers in Configuration 1

The following configuration describes configuration 1 for testing ATA/ATAPI Controllers:

  • A UDMA-capable hard disk drive is installed as Device 0 on the primary ATA/ATAPI channel.
  • A DMA-capable CD-ROM drive is installed as Device 1 on the primary ATA/ATAPI channel.
  • A DMA-capable CD-RW drive is installed as Device 1 on the secondary ATA/ATAPI channel.

Before you run the ATA/ATAPI controller logo tests in configuration 1, you must assemble and configure the test system according to the following procedures.

To assemble the test system for ATA/ATAPI controller configuration 1 testing
  1. Install one boot-capable, add-in controller adapter (not the test device) that has signed drivers or in-box support.
  2. Attach a hard disk drive to the add-in controller adapter that is installed in step 1.
  3. Attach one CD-ROM drive (CD-ROM Drive 1) to the add-in controller adapter that is installed in step 1.
  4. If your device is an add-in ATA/ATAPI controller, physically install the test device.
  5. Install the DMA-capable ATA/ATAPI CD-ROM drive (CD-ROM Drive 2) as Device 1 on the primary ATA/ATAPI channel of the test device, by using a standard ATA/ATAPI cable.
  6. Install one ATA/ATAPI CD-RW drive as Device 1 on the secondary ATA/ATAPI channel of the test device, by using a standard ATA/ATAPI cable.
To configure the test system for ATA/ATAPI controller configuration 1 testing
  1. Turn on the test system and set the system BIOS to boot from the CD-ROM drive.
  2. Set the system BIOS to support the S3 state.
  3. Insert the appropriate Microsoft Windows operating system CD into CD-ROM Drive 1, and then restart the test system.
  4. Install the appropriate Windows operating system on the hard disk drive.
  5. If necessary, install any drivers that the manufacturer supplies.
  6. If necessary, install the appropriate driver for the controller under test.
  7. Install the Debugging Tools for Windows to C:\Debuggers.
  8. Copy the Microsoft Windows Symbols files to C:\Symbols.
  9. Insert a blank CD-RW into the CD-RW drive.
  10. If appropriate, enable the autologon functionality. For more information about autologon, see [image] How to turn on automatic logon in Windows XP.
  11. Install DTM Client.
  12. Configure the machine for testing in DTM Studio:
    1. Add the machine to a machine pool.
    2. Deploy the WDK\ConfigureAtaAtapiStorageController” dimension.


Preparing to Test ATA/ATAPI Controllers in Configuration 2

The following configuration describes configuration 2 for testing ATA/ATAPI Controllers:

  • A UDMA-capable hard disk drive is installed as Device 0 on the primary ATA/ATAPI channel.
  • A DVD-ROM drive is installed as Device 1 on the primary ATA/ATAPI channel.
  • A ATA/ATAPI tape drive is installed on the secondary ATA/ATAPI channel.
  • A ATA/ATAPI removable media drive is installed on the secondary ATA/ATAPI channel.

Before you run the ATA/ATAPI controller logo tests in configuration 2, you must assemble and configure the test system according to the following procedures.

To assemble the test systems for ATA/ATAPI controller configuration 2 testing
  1. Install the UDMA hard disk drive as Device 0 on the primary ATA/ATAPI channel, by using a standard ATA/ATAPI cable.
  2. Install the ATA/ATAPI DVD-ROM drive as Device 1 on the primary ATA/ATAPI channel, by using a standard ATA/ATAPI cable.
  3. Install the ATA/ATAPI tape drive as Device 0 on the secondary ATA/ATAPI channel, by using a standard ATA/ATAPI cable.
  4. Install the ATA/ATAPI removable media drive as Device 1 on the secondary ATA/ATAPI channel, by using a standard ATA/ATAPI cable.
To configure the test systems for ATA/ATAPI controller configuration 2 testing
  1. Turn on the test system and set the system BIOS to boot from the DVD-ROM drive.
  2. Set the system BIOS to support the S3 state.
  3. Insert the appropriate Microsoft Windows operating system CD into the DVD-ROM drive and restart the test system.
  4. Install the appropriate Windows operating system on the hard disk.
  5. If necessary, install any drivers that the manufacturer supplies.
  6. If necessary, install the appropriate driver for the controller under test.
  7. Use the following procedure to make the system page file larger than the size of RAM:
    1. Click Start, right-click My Computer, and select Properties.
    2. On Windows Vista or Windows Longhorn Server, click Advanced System Settings. If you are prompted to enter Administrative credentials or allow the action, enter the credentials or allow the action.
    3. In the General tab of the System Properties dialog box, note the amount of RAM that the computer has.
    4. In the Advanced tab of the System Properties dialog box, click Settings in the Performance section.
    5. In the Advanced tab of the Performance Options dialog box, click Change in the Virtual Memory section.
    6. Click Custom Size, and then enter a number that is larger than the size of RAM for the Initial Size.

      Note You specify the size of the page file in megabytes (MB). If the amount of RAM on your computer was specified by using gigabytes (GB) or some other measure, convert the amount of RAM to MB before choosing and entering a value for the page file size.

    7. Enter a Maximum Size value that is larger than the initial size. (It is common for the maximum size to be 1.5 to 2 times the initial size.)
    8. Click Set.
    9. Click OK twice.
    10. In the Advanced tab of the System Properties dialog box, under Startup and Recovery, click Settings.
    11. Under Write debugging information, select Small memory dump (64 KB).
    12. In the Small dump directory box, type X:\minidump, where X is the drive letter of the NTFS partition on Disk 2.
    13. Click OK twice.
    14. Restart the computer to update the page file size.
  8. Install the Debugging Tools for Windows to C:\Debuggers.
  9. Copy the Microsoft Windows Symbols files to C:\Symbols.
  10. Insert a prepared blank tape cartridge into the tape drive and verify that the operating system detects that the tape is free.
  11. Insert media into the removable media drive. Delete any existing partitions on the removable media drive and create one partition using all available disk space. Format the partition with the FAT file system.
  12. If appropriate, enable the autologon functionality. For more information about autologon, see [image] How to turn on automatic logon in Windows XP.
  13. Install DTM Client.
  14. Configure the machine for testing in DTM Studio:
    1. Add the machine to a machine pool.
    2. Deploy the WDK\ConfigureAtaAtapiStorageController” dimension.


Running the ATA/ATAPI Controller Tests

To test ATA/ATAPI Controllers, do the following:

  1. Open Device Console in DTM Studio.
  2. Create a new submission for “Storage > Adapter or Controller > ATA”.
    • If the device has a driver, select the driver INF when prompted.
    • Make sure to select the ATA/ATAPI Controller test from the device list.
  3. Select the tests that you want to start, choose Add Selected, and then click Schedule.

Crashdump Support Test

Setup: This test requires that the machine has Operating System Symbols installed in C:\symbols. This test will automatically install the Debugging Tools for Windows as a setup task.

Troubleshooting: If you encounter a test failure at any point before the final Logging phase of the test, ensure that you have the correct symbols.

Note This test will intentionally cause the system to stop responding. A bugcheck during the test is normal if caused by Bugcheck.sys.

Note This test restarts the system.

More Info:

Data Verification Test

Input: This test accepts a single drive letter and a PNP ID as input. These are both provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any file system.

Note This test restarts the system.

DMA Test

Input: This test accepts a single drive letter. This letter is provided automatically by DTM.

More Info:

Ext Int13h Test

More Info:

Storage Device Stress

Input: This test accepts a string of drive letters as input. This string is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any file system.

More Info:

TAPE IO Test

More Info:

Driver Verifier

More Info:

Device Path Exerciser

More Info:

Sleep Stress with IO

More Info:

Disable Enable with IO

More Info:

Plug and Play Driver Test

More Info:

Prefast for Drivers Test

More Info:

Static Driver Verifier Test

More Info:

Stress Test

More Info:

Stress Test with low resource simulation

More Info:

Sleep Stress Disable Enable with IO

More Info:


Troubleshooting ATA/ATAPI Controller Testing

For more information about troubleshooting ATA/ATAPI Controller testing, see Troubleshooting Storage Tests.


ATA RAID Controller Testing Overview

These procedures test your ATA RAID controller for proper functionality by using the Microsoft Windows Driver Kit (WDK) and the Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as required for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

The test procedures are divided into the following types of topics:

  • Overview: The overview topics describe the hardware, software, and tester knowledge requirements.
  • Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.
  • Running: The running topics describe how to run the tests for your device or system.

ATA-RAID Controller Tests

The tests that you need to run depend on the capabilities of the device or system that is being tested. The following list contains all of the tests that you might need for your test device:

  • Crashdump Support Test
  • Storage Data Verification Filter Test
  • DMA Test
  • Int 13h Extensions test
  • Storage Device Stress test (SDStress)
  • Driver Verifier
  • Device Path Exerciser
  • System - Sleep Stress with IO
  • Disable Enable with IO
  • Plug and Play Driver Test
  • Prefast for Drivers
  • Static Driver Verifier
  • Stress Test
  • Core Stress Test

Run time: approximately 2 hours

Note The test descriptions are included in a separate section.

Hardware Requirements

The following hardware is required for ATA RAID Controller testing. You might need additional hardware if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One computer with the following:
    • Dual-core or equivalent processor (Windows Vista or Windows XP)
    • Quad-core or equivalent processor (Windows Longhorn Server or Windows Server 2003)
    • 2 GB memory (Windows Vista or Windows XP)
    • 6 GB memory (Windows Longhorn Server or Windows Server 2003)
    • Logo-compliant ACPI BIOS, with ACPI enabled by default
    • A PCI-based bus

    Note For Windows Vista and Windows XP Professional, the test system must support S3 and S4 states. For Windows XP Professional on mobile systems, the test system must support the S4 state and the S1 or S3 state. For Windows Server 2003, the test system must support only the S4 state.

    Note Remove any USB floppy disk drives or LS-120 drives from the test system and replace them with standard ATA floppy drives if possible.

  • Four ATA hard disk drives (if dual adapters are supported), or eight ATA hard disk drives (if dual adapters are not supported). All hard disk drives must be a minimum of 40 GB.
  • One ATA or SCSI CD-ROM drive.
  • One ATA or SCSI controller (if the ATA RAID controller is non-bootable).
  • One ATA or SCSI hard disk drive (if the ATA RAID controller is non-bootable).
  • Two identical PCI-based ATA RAID controllers (the devices under test).
  • One PCI-to-PCI bridge adapter.

    Note A PCI-to-PCI bridge adapter is not required if any of the following apply:

    • The ATA RAID controller cannot fit into PCI bridge adapters. This situation may be the case with integrated controllers or controllers that can fit only into specially designed slots.
    • The ATA RAID controller is designed and sold only for systems that cannot accept full-height PCI-to-PCI bridge adapters. This situation may be the case with blade servers.
    • One of the ATA RAID controllers can be placed into a PCI bus slot that is already behind a PCI bridge.

Important The test system must have received the "Designed for Windows" logo. All hardware (except for the device under test, monitor, keyboard, mouse and the floppy disk drive) must be included in the Windows Catalog.

Software Requirements

The following software is required to run the ATA RAID Controller tests:

  • Microsoft Windows Vista
  • Microsoft Windows XP Professional with Service Pack 2 (SP2)
  • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
  • Microsoft Windows Server 2003, Datacenter Edition, with SP1
  • Microsoft Windows XP Professional x64 Edition
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows Server 2003, Datacenter x64 Edition
  • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
  • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems
  • Any drivers that are not shipped with the operating system
  • The current release of the Microsoft Windows Driver Kit (WDK)

Tester Knowledge Requirements

To run the ATA RAID Controller tests, testers must know how to accomplish the following tasks:

  • Access and change the system BIOS settings.
  • Install a hard disk drive.
  • Format and partition a hard disk drive.
  • Install an ATA RAID controller.
  • Configure a RAID array.
  • Create and format a logical drive.
  • Install a PCI-to-PCI bridge.
  • Install and configure Microsoft Debugging Tools for Windows.
  • Install Microsoft Windows Symbols files.
  • Read and interpret test logs.
  • Report bugs in a standard bug format.
  • Install the operating system from the product CD.

After you have reviewed the necessary requirements, you can prepare to test your ATA RAID controller device.

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Preparing to Test ATA RAID Controllers

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see the ATA RAID Controller Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, For more information about autologon, see [image] How to turn on automatic logon in Windows XP.

Test system configuration

There are two different procedures for configuring an ATA RAID controller for basic functionality testing. Use the default configuration in most situations. However, if one of the following exceptions applies, use the secondary configuration procedure:

  • The ATA RAID controller test device is an integrated controller.

    Note Use the default procedure for integrated controllers if a system that meets the hardware requirements with two of the integrated controllers is available or if a duplicate PCI adapter version of this ATA RAID controller is available.

  • The ATA RAID controller is designed for and sold only in a host test system that will accept only a single version of the controller.

For more information about configuring an ATA RAID controller for basic functionality testing, see the following topics:

Preparing for ATA RAID Controller Testing with the Default Configuration

Preparing for ATA RAID Controller Testing with the Secondary Configuration


Preparing for ATA RAID Controller Testing with the Default Configuration

Use the following procedure to configure the test system and install the software to test an ATA RAID controller, unless one of the following conditions applies:

  • The ATA RAID controller test device is an integrated controller.

    Note Use the default procedure for integrated controllers if a system that meets the hardware requirements with two of the integrated controllers is available or if a duplicate PCI adapter version of the ATA RAID controller is available.

  • The ATA RAID controller is designed for, and sold only in, a host test system that will accept only a single version of the controller.

If one of the preceding conditions applies, use the secondary configuration instead.

Before you run the ATA RAID controller logo tests, you must configure the test system, configure the ATA RAID controller, install the operating system, and then install the DTM Client according to the following procedures.

To configure the test system for ATA RAID controller testing

    Note All adapters should be operated with BIOS enabled and write caching enabled.

  1. Turn off the test system.
  2. If the test device is not bootable, install one boot-capable, add-in controller (not the test device) that has signed drivers or in-box support.
  3. Attach a CD-ROM drive to the system if one is not already attached.
  4. Install one ATA RAID controller (controller 1).
  5. Connect and install four hard disk drives to the first ATA RAID controller. If fewer than four hard disk drives are supported, install the maximum number of hard disk drives that are supported.
  6. Install a PCI-to-PCI bridge in a PCI slot on the host test system, unless any of the following conditions apply:
    • The ATA RAID controller cannot fit into a PCI bridge adapter, which might occur with integrated controllers or controllers that can fit only into specially designed slots.
    • The ATA RAID controller is designed and sold only for systems that cannot accept full-height PCI-to-PCI bridge adapters, which might occur with blade servers.
    • One of the ATA RAID controllers can be placed into a PCI bus slot that is already behind a PCI bridge.
  7. Install a secondary, duplicate ATA RAID controller (controller 2) into the PCI-to-PCI bridge card.

    Note Install the secondary ATA RAID controller directly into a PCI slot if a PCI bridge card is not required.

  8. If possible, set the first and second ATA RAID controllers to use the same IRQ.
  9. Connect and install four ATA hard disk drives (or the maximum number of hard disk drives that are supported) to the second ATA RAID controller.
To configure the ATA RAID controller for basic functionality testing
  1. Create one 40-GB RAID array on controller 1, and two 40-GB RAID arrays on controller 2. The RAID array on controller 1 is referred to as RAID Array 1, and the RAID arrays on controller 2 are referred to as RAID Array 2 and RAID Array 3.

    Note If the test device does not support enough hard disk drives to configure the required RAID arrays, install an additional hard disk drive on an add-in controller, and create RAID Array 3 on this hard disk drive.

  2. Configure the RAID arrays according to the following table.
    If the test device supports these RAID levels | RAID level for RAID Array 1 | RAID level for RAID Array 2 | RAID level for RAID Array 3
    0 only | 0 | 0 | 0
    1 only | 1 | 1 | 1
    5 only | 5 | 5 | 5
    0 and 1 only | 1 | 0 | 1
    0 and 5 only | 5 | 0 | 5
    1 and 5 only | 5 | 1 | 5
    0, 1, and 5 | 5 | 0 | 1

To install the operating system with the default configuration

    Use the following procedure to install the operating system. When you are finished, the RAID array will be configured as shown in Figure 1 for Windows Vista or Windows XP and as shown in Figure 2 for Windows Server 2003, Enterprise Edition.

    Figure 1: RAID array default configuration for Windows Vista or Windows XP

    Figure 2: RAID array default configuration for Windows Server 2003, Enterprise Edition

  1. Install the operating system on a partition, as follows:
    • If the test ATA RAID controller is bootable, install the operating system on a 14-GB NTFS partition on RAID Array 1.
    • If the ATA RAID controller is not bootable, install the operating system on a 14-GB NTFS partition on a hard disk drive that is connected to an alternate, non-test boot controller in the host test system.
  2. Install any software or drivers that are necessary to connect to and manage the peripheral devices.

    Note All drivers, except the drivers for the test device, must be signed and must be listed in Windows Catalog.

  3. Click Start, right click My Computer, and then click Properties.
  4. If the test operating system is Windows Vista or Windows Longhorn Server, click Advanced System Settings. If you are prompted to enter Administrative credentials or allow the action, enter the credentials or allow the action.
  5. In the General tab, note the amount of RAM that the computer has.
  6. Click the Advanced tab, and then under Performance, click Settings. The Performance Options dialog box appears.
  7. Click the Advanced tab, and then under Virtual Memory, click Change. The Virtual Memory dialog box appears.
  8. Click Custom Size, and then type a number that is larger than the size of RAM in the Initial Size text box.

    Note You specify the size of the page file in megabytes (MB). If the amount of RAM on your computer was specified by using gigabytes (GB) or some other measure, convert the amount of RAM to MB before choosing and entering a value for the page file size.

  9. In the Maximum Size text box, type a maximum size value that is larger than the initial size. (It is common for the maximum size to be one and a half to two times the initial size.)
  10. Click Set, and then click OK twice.
  11. In the Advanced tab of the System Properties dialog box, under Startup and Recovery, click Settings.
  12. Under Write debugging information, click the down arrow, and then select Small memory dump (64 KB).
  13. In the Small dump directory box, type X:\Minidump, where X is the drive letter of one of the RAID partitions.
  14. Click OK twice, and then restart the computer to update the page file size.
  15. Install the Debugging Tools for Windows to the C:\Debuggers directory.
  16. Copy the Microsoft Windows Symbols files to the C:\Symbols directory.
  17. Use Windows Disk Management to make all of the disks dynamic.

    Important If the test device is not bootable at this point, you are booting from an alternate boot controller. Do not add any partitions to the hard disks on the alternate boot controller.

  18. Use the Windows Disk Management utility to set up three 4-GB partitions on RAID Array 2, and do one of the following:
    • If you are testing with a 32-bit edition of the Windows operating system, format two of the partitions with the NTFS file system, and format the third partition with the FAT32 file system.
    • If you are testing with a 64-bit edition of Windows, format all three partitions with NTFS.
  19. If you are testing with Windows Server 2003, use Windows Disk Management to create a software RAID 1 mirror from one of the NTFS partitions on RAID Array 2 to the unallocated space on RAID Array 1.
  20. If you are testing with Windows Server 2003, use Windows Disk Management to create a 4-GB NTFS software RAID 5 array that uses unallocated space on RAID Array 1, RAID Array 2, and RAID Array 3.
  21. If you are testing with Windows Vista or Windows XP, use Windows Disk Management to create a 4-GB NTFS spanned volume that uses RAID Array 1, RAID Array 2, and RAID Array 3.
  22. Install DTM Client.
  23. Configure the machine for testing in DTM Studio.
    1. Add the machine to a machine pool.
    2. Deploy the WDK\ConfigureAtaRaidStorageController” dimension.


Preparing for ATA RAID Controller Testing with the Secondary Configuration

Use the following procedure to configure the test system for ATA RAID controller testing only if the ATA RAID controller test device is an integrated controller.

Important This procedure cannot be used for integrated controllers if a system that meets hardware requirements with two of the integrated controllers is available or if there is a duplicate PCI adapter version of this ATA RAID controller available.

If the preceding situations do not apply, use the default configuration.

Before you run the ATA RAID controller logo tests, you must configure the test system, configure the ATA RAID controller, install the operating system, and then install the DTM Client according to the following procedures.

To configure the test system for ATA RAID controller testing

    Note All adapters should be operated with BIOS enabled and write caching enabled.

  1. Turn off the test system.
  2. Install an add-in controller (not the test device) that has signed drivers or in-box support. If the test device is not bootable, the add-in controller must be boot-capable.
  3. Attach a CD-ROM drive to the add-in controller.
  4. Install one ATA RAID controller (the test device).
  5. Connect and install four hard disk drives to the test controller. If fewer than four hard disk drives are supported, install the maximum number of hard disk drives that are supported.
  6. Attach two hard disk drives to the add-in controller (Disk 1 and Disk 2).
To configure the ATA RAID controller for basic functionality testing
  1. Create RAID arrays in one of the following ways:
    • If the test device supports enough hard disk drives to create two RAID arrays, create two 40-GB RAID arrays on the test device. These RAID arrays are referred to as RAID Array 1 and RAID Array 2.
    • If the test device does not support enough hard disk drives to create two RAID arrays, create one 40-GB RAID array on the test device. This RAID array is referred to as RAID Array 1. In the steps that follow, use Disk 2—one of the hard disk drives that you attached to the add-in controller—instead of RAID Array 2 wherever RAID Array 2 is mentioned.
  2. Configure the RAID arrays according to the following table:
    If the test device supports these RAID levels | RAID level for RAID Array 1 | RAID level for RAID Array 2
    0 only | 0 | 0
    1 only | 1 | 1
    5 only | 5 | 5
    0 and 1 only | 1 | 0
    0 and 5 only | 5 | 0
    1 and 5 only | 5 | 1
    0, 1, and 5 | 5 | 1

To install the operating system in the secondary configuration

    Use the following procedure to install the operating system. When you are finished, the RAID array will be configured as shown in Figure 3 for a test device that supports enough hard disk drives to create two RAID arrays, and as shown in Figure 4 for a test device that does not support enough hard disk drives to create two RAID arrays.

    Figure 3: RAID array secondary configuration for a device that supports enough hard disk drives to create two RAID arrays

    Figure 4: RAID array secondary configuration for a device that does not support enough hard disk drives to create two RAID arrays

  1. Install the operating system on a partition of RAID Array 1 or Disk 1, as follows:
    • If the test ATA RAID controller is bootable, install the operating system onto a 14-GB NTFS partition on RAID Array 1.
    • If the test ATA RAID controller is not bootable, install the operating system onto a 14-GB NTFS partition on Disk 1.
  2. Install any software or drivers that are necessary to connect to and manage the peripheral devices.
  3. Click Start, right-click My Computer, and then click Properties.
  4. On Windows Vista or Windows Longhorn Server, click Advanced System Settings. If you are prompted to enter Administrative credentials or allow the action, enter the credentials or allow the action.
  5. On the General tab, note the amount of RAM that the computer has.
  6. Click the Advanced tab, and then under Performance, click Settings. The Performance Options dialog box appears.
  7. Click the Advanced tab, and then under Virtual Memory, click Change. The Virtual Memory dialog box appears.
  8. Click Custom Size, and then type a number that is larger than the size of RAM in the Initial Size text box.

    Note You specify the size of the page file in megabytes (MB). If the amount of RAM on your computer was specified by using gigabytes (GB) or some other measure, convert the amount of RAM to MB before choosing and entering a value for the page file size.

  9. In the Maximum Size text box, type a maximum size value that is larger than the initial size. (It is common for the maximum size to be one and a half to two times the initial size.)
  10. Click Set, and then click OK twice.
  11. In the Advanced tab of the System Properties dialog box, under Startup and Recovery, click Settings.
  12. Under Write debugging information, click the down arrow, and then click Small memory dump (64 KB).
  13. In the Small dump directory box, type X:\Minidump, where X is the drive letter of one of the RAID partitions.
  14. Click OK twice, and then restart the computer to update the page file size.
  15. Install the Debugging Tools for Windows to the C:\Debuggers directory.
  16. Copy the Microsoft Windows Symbols files to the C:\Symbols directory.
  17. Use Windows Disk Management to make all of the disks dynamic.

    Important If the test device is not bootable at this point, you are booting from an alternate boot controller.

  18. Use the Windows Disk Management utility to set up three 4-GB partitions on RAID Array 1, and then do one of the following:
    1. If you are testing with a 32-bit edition of the Windows operating system, format two of the partitions with the NTFS file system, and format the third partition with FAT32.
    2. If you are testing with a 64-bit edition of Windows, format all three partitions with NTFS.
  19. If you are testing with Microsoft Windows Server 2003, use Windows Disk Management to create a software RAID 1 mirror from one of the NTFS partitions on RAID Array 1 to the unallocated space on RAID Array 2.
  20. If you are testing with Windows Server 2003, use Windows Disk Management to create a 4-GB NTFS software RAID 5 array by using unallocated space on RAID Array 1 and RAID Array 2.
  21. If you are testing with Windows Vista or Windows XP, use Windows Disk Management to create a spanned volume by using the unallocated space on RAID Array 1 and RAID Array 2.
  22. Install DTM Client.
  23. Configure the machine for testing in DTM Studio:
    1. Add the machine to a machine pool.
    2. Deploy the WDK\ConfigureAtaRaidStorageController” dimension.


Running the ATA RAID Controller Tests

To test ATA RAID Controllers, do the following:

  1. Open Device Console in DTM Studio.
  2. Create a new submission for “Storage > Adapter or Controller > ATA RAID”.
    • If the device has a driver, select the driver INF when prompted.
    • Make sure to select the test ATA RAID Controller from the device list.
  3. Select the tests that you want to start, choose Add Selected, and then click Schedule.

Crashdump Support Test

Setup: This test requires that the machine has Operating System Symbols installed in C:\symbols. This test will automatically install the Debugging Tools for Windows as a setup task.

Troubleshooting: If you encounter a test failure at any point before the final Logging phase of the test, ensure that you have the correct symbols.

Note This test will intentionally cause the system to stop responding. A bugcheck during the test is normal if caused by Bugcheck.sys.

Note This test restarts the system.

More Info:

Data Verification Test

Input: This test accepts a single drive letter and a PNP ID as input. These are both provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any file system.

Note This test restarts the system.

DMA Test

Input: This test accepts a single drive letter. This letter is provided automatically by DTM.

More Info:

Ext Int13h Test

More Info:

Storage Device Stress

Input: This test accepts a string of drive letters as input. This string is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any file system.

More Info:

Driver Verifier

More Info:

Device Path Exerciser

More Info:

Sleep Stress with IO

More Info:

Disable Enable with IO

More Info:

Plug and Play Driver Test

More Info:

Prefast for Drivers Test

More Info:

Static Driver Verifier Test

More Info:

Stress Test

More Info:

Stress Test with low resource simulation

More Info:

Sleep Stress Disable Enable with IO

More Info:


Troubleshooting ATA RAID Controller Testing

For more information about troubleshooting ATA RAID Controller testing, see Troubleshooting Storage Tests.


Fibre Channel Adapter Testing Overview

These procedures test your Fibre Channel Adapter for proper functionality with the Microsoft Windows operating system by using the Microsoft Windows Driver Kit (WDK) and the Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as required for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

The test procedures are divided into the following types of topics:

  • Overview: The overview topics describe the hardware, software, and tester knowledge requirements.
  • Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.
  • Running: The running topics describe how to run the tests for your device or system.

Fibre Channel Adapter Tests

The tests that you need to run depend on the capabilities of the device or system that is being tested. The following list contains all of the tests that you might need for your test device:

  • Crashdump Support Test
  • Storage Data Verification Filter Test
  • Int 13h Extensions test
  • Storage Device Stress test (SDStress)
  • Tape I/O Test
  • Driver Verifier
  • Device Path Exerciser
  • System - Sleep Stress with IO
  • Disable Enable with IO
  • Plug and Play Driver Test
  • Prefast for Drivers
  • Static Driver Verifier
  • Stress Test
  • Core Stress Test

Run time: approximately 2 hours

Note The test descriptions are included in a separate section.

Hardware Requirements

The following hardware is required for Fibre Channel Adapter testing. You might need additional hardware if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One computer with the following:
    • Dual-core or equivalent processor (Windows Vista or Windows XP)
    • Quad-core or equivalent processor (Windows Longhorn Server or Windows Server 2003)
    • 2 GB memory (Windows Vista or Windows XP)
    • 6 GB memory (Windows Longhorn Server or Windows Server 2003)

      Important The Windows operating system must report that a minimum of 5500 MB of RAM is free and available.

    • Logo-compliant ACPI BIOS, with ACPI enabled by default
    • A PCI-based bus

  • One Fibre Channel RAID storage subsystem.
  • One ATA or SCSI controller if the Fibre Channel adapter is not bootable.
  • One ATA or SCSI disk drive if the Fibre Channel adapter is not bootable. The disk must have a minimum capacity of 18 GB.
  • Three SCSI hard disk drives for the default procedure for Fibre Channel adapter testing.
  • One SCSI or ATA CD-ROM drive.
  • Two identical PCI-based Fibre Channel adapters (the test devices).
  • One Fibre Channel hard disk or Fibre Channel JBOD.
  • One PCI-to-PCI bridge adapter.

    Note A PCI-to-PCI bridge adapter is not required if any of the following apply:

    • The Fibre Channel adapters cannot fit into PCI bridge adapters. This situation may be the case with integrated controllers or controllers that can fit only into specially designed slots.
    • The Fibre Channel adapter is designed and sold only for systems that cannot accept full-height PCI-to-PCI bridge adapters. This situation may be the case with blade servers.

  • One monitor, one keyboard, and one mouse (or any pointing or drawing device).

Note Any USB floppy disk drives or LS-120 drives should be removed from the system and replaced with standard ATA floppy disk drives if possible.

Important The test system must have received the "Designed for Windows" logo. All hardware (except for the device under test, monitor, keyboard, mouse and the floppy disk drive) must be included in the Windows Catalog.

Software Requirements

The following software is required to run the Fibre Channel Adapter tests:

  • Microsoft Windows Vista
  • Microsoft Windows XP Professional with Service Pack 2 (SP2)
  • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
  • Microsoft Windows Server 2003, Datacenter Edition, with SP1
  • Microsoft Windows XP Professional x64 Edition
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows Server 2003, Datacenter x64 Edition
  • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
  • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems
  • Any drivers that are not shipped with the operating system
  • The current release of the Microsoft Windows Driver Kit (WDK)

Tester Knowledge Requirements

To run the Fibre Channel Adapter tests, testers must know how to accomplish the following tasks:

  • Access and change the system BIOS settings.
  • Install SCSI and ATA hard disk drives.
  • Install a Fibre Channel adapter.
  • Configure a RAID array.
  • Install a PCI-to-PCI bridge.
  • Install and configure Microsoft Debugging Tools for Windows.
  • Install Microsoft Windows Symbols files.
  • Read and interpret test logs.
  • Report bugs in a standard bug format.

After you have reviewed the necessary requirements, you can prepare to test your Fibre Channel Adapters.

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Preparing to Test Fibre Channel Adapters

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see Fibre Channel Controller Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, For more information about autologon, see [image] How to turn on automatic logon in Windows XP.

Test system configuration

There are two different procedures for configuring an Fibre Channel adapter for basic functionality testing. Use the default configuration in most situations. However, if one of the following exceptions applies, use the secondary configuration procedure:

  • The Fibre Channel adapter test device is an integrated controller.

    Note The secondary procedure cannot be used for integrated controllers if a system that meets hardware requirements with two of these integrated controllers is available, or if there is a duplicate PCI adapter version of this Fibre Channel adapter available.

  • The Fibre Channel adapter is designed for and sold only in a host test system that will accept only a single version of the controller.

For more information about configuring an Fibre Channel adapter for basic functionality testing, see the following topics:

Preparing for Fibre Channel Adapter Testing with the Default Configuration

Preparing for Fibre Channel Adapter Testing with the Secondary Configuration


Preparing for Fibre Channel Adapter Testing with the Default Configuration

Use the following procedure to prepare to test a Fibre Channel adapter, unless one of the following conditions applies:

  • The Fibre Channel adapter test device is an integrated controller.

    Note Use the default procedure for integrated controllers if a system that meets hardware requirements with two of these integrated controllers is available, or if there is a duplicate PCI adapter version of this Fibre Channel adapter available.

  • The Fibre Channel adapter is designed for and sold only in a host test system that will accept only a single version of the controller.

If one of the preceding conditions applies, use the secondary configuration for testing Fibre Channel adapters.

Before you run the Fibre Channel adapter logo tests, you must configure the test system, install the operating system, and then install the DTM Client according to the following procedures.

To configure the test system for Fibre Channel adapter testing
  1. Turn off the test system.
  2. Install one CD-ROM drive in the test system, if the system does not already contain one.
  3. Install one Fibre Channel adapter (test device 1).
  4. Connect the Fibre Channel adapter to the RAID system.
  5. Install a PCI-to-PCI bridge in a PCI slot in the test system.

    Note Do not install a PCI-to-PCI bridge adapter if the Fibre Channel adapter cannot be installed into a PCI-to-PCI bridge because of its design (for example, a controller that fits into specially designed slots or blade servers). A PCI-to-PCI bridge adapter is also not required if the Fibre Channel adapter is designed and sold only for systems, such as blade servers, that cannot accept full-height PCI-to-PCI bridge adapters.

  6. Install a secondary, identical Fibre Channel adapter (test device 2) into the PCI-to-PCI bridge card.
  7. Connect one Fibre Channel hard disk drive or Fibre Channel JBOD to test device 2.
  8. If the test system contains any USB floppy disk drives or LS-120 drives, remove them and replace them with standard ATA floppy disk drives.
  9. Turn on the test system.

    Note Fibre Channel adapters are required to support only one RAID level. Use the following list to determine which RAID level to configure the JBOD to for testing:

    • If the device supports only RAID 5, configure it for testing with RAID 5, and then run all of the basic functionality tests. If the device supports only RAID 1, configure it for testing with RAID 1, and then run all of the basic functionality tests. If the device does not support RAID 5 and RAID 1, configure it for testing test with RAID 0, and then run all of the basic functionality tests.
    • If more than one RAID level is supported on the test device and one of the RAID levels supported is not redundant, configure the device for testing with the redundant RAID level. For example, if the test device supports RAID 0 and RAID 5, configure it for testing with RAID 5, and then run all of the basic functionality tests.
    • If more than one RAID level is supported on the test device and if more than one of the RAID levels supported is redundant, configure the device for testing with a redundant RAID level of your choice, and then run all of the basic functionality tests. For example, if the test device supports RAID 0, RAID 1, and RAID 5, configure it for testing with RAID 5 or RAID 1, and then run all of the basic functionality tests.

  10. Configure the RAID system for testing with one of the following RAID sets:
    • To configure the system with a RAID 0 set, use the hardware RAID configuration utility for the RAID system, and create one RAID 0 array. The array must be minimum of 18 GB, up to the largest array size that the RAID system supports.
    • To configure the RAID system for testing with a RAID 1 set, use the hardware RAID configuration utility for the RAID system, and create one RAID 1 array. The array must be minimum of 18 GB, up to the largest array size that the RAID system supports.
    • To configure the RAID system for testing with a RAID 5 set, use the hardware RAID configuration utility for the RAID system, and create one RAID 5 array. The array must be minimum of 18 GB, up to the largest array size that the RAID system supports.
To install the operating system
  1. Do one of the following:
    • If the test Fibre Channel adapter is bootable, install the operating system onto a NTFS, 14-GB partition on the RAID system. Install any HBA or RAID system drivers (including multipath) that are necessary to connect to, or manage the peripheral devices.
    • If the test Fibre Channel adapter is not bootable, turn off the test system and install an ATA or SCSI hard disk drive and an alternate ATA or SCSI boot controller if they are not present.

      Next, turn on the test system, and then install the operating system onto a NTFS-formatted, 14-GB partition on the ATA or SCSI hard disk drive that is connected to the alternate ATA or SCSI boot controller in the test system. Install any HBA or RAID system drivers (including multipath) that are necessary to connect to or manage the peripheral devices.

  2. From the Start menu, right-click My Computer, and click Properties.
  3. On Windows Vista or Windows Longhorn Server, click Advanced System Settings. If you are prompted to enter Administrative credentials or allow the action, enter the credentials or allow the action.
  4. In the General tab, note the amount of RAM that the computer has.
  5. Click the Advanced tab, and then under Performance, click Settings. The Performance Options dialog box appears.
  6. Click the Advanced tab, and then under Virtual Memory, click Change. The Virtual Memory dialog box appears.
  7. Click Custom Size, and then type a number that is larger than the size of RAM in the Initial Size text box.

    Note You specify the size of the page file in megabytes (MB). If the amount of RAM on your computer was specified by using gigabytes (GB) or some other measure, convert the amount of RAM to MB before choosing and entering a value for the page file size.

  8. In the Maximum Size text box, type a maximum size value that is larger than the initial size. (It is common for the maximum size to be one and a half to two times the initial size.)
  9. Click Set, and then click OK twice.
  10. In the Advanced tab of the System Properties dialog box, under Startup and Recovery, click Settings.
  11. Under Write debugging information, click the down arrow, and then select Small memory dump (64 KB).
  12. In the Small dump directory box, type X:\Minidump, where X is the drive letter of one of the RAID partitions.
  13. Click OK twice, and then restart the operating system to update the page file size.
  14. Install the Debugging Tools for Windows to the C:\Debuggers directory.
  15. Copy the Microsoft Windows Symbols files to the C:\Symbols directory.
  16. Use the Windows Disk Management utility to set up three 4-GB partitions on the RAID array that was previously created on the RAID system, and do one of the following:
    • If you are testing with a 32-bit edition of the Windows operating system, format two of the partitions with the NTFS file system, and format the third partition with the FAT32 file system.
    • If you are testing with a 64-bit edition of Windows, format all three partitions with NTFS.

  17. Use Windows Disk Management to mirror one of the 4-GB NTFS partitions on the RAID system to the non-partitioned disk space on the on the second array on the RAID system.
  18. Install DTM Client.
  19. Configure the machine for testing in DTM Studio.
    1. Add the machine to a machine pool.
    2. Deploy the WDK\ConfigureFibreChannelStorageController” dimension.


Preparing for Fibre Channel Adapter Testing with the Secondary Configuration

Use the following procedure to prepare to test a Fibre Channel adapter if one of the following conditions applies:

  • The Fibre Channel adapter test device is an integrated controller.

    Note Use the default procedure for integrated controllers if a system that meets hardware requirements with two of these integrated controllers is available, or if there is a duplicate PCI adapter version of this Fibre Channel adapter available.

  • The Fibre Channel adapter is designed for and sold only in a host test system that will accept only a single version of the controller.

If one of the following conditions does not apply, use the default procedure for testing Fibre Channel adapters.

Before you run the Fibre Channel adapter logo tests, you must configure the test system, install the operating system, and then install the DTM Client according to the following procedures.

To configure the test system for Fibre Channel adapter testing
  1. Turn off the test system.
  2. Install one CD-ROM drive in the test system, if the system does not already contain one.
  3. Install one Fibre Channel adapter (test device 1).
  4. Connect the Fibre Channel adapter to the RAID system.
  5. If the test system contains any USB floppy disk drives or LS-120 drives, remove them and replace them with standard ATA floppy disk drives.
  6. Turn on the test system.

    Note Fibre Channel adapters are required only to support one RAID level. Use the following list to determine which RAID level to configure the JBOD to for testing:

    • If the device supports only RAID 5, configure it for testing with RAID 5, and then run all of the basic functionality tests. If the device supports only RAID 1, configure it for testing with RAID 1, and then run all of the basic functionality tests. If the device does not support RAID 5 and RAID 1, configure it for testing test with RAID 0, and then run all of the basic functionality tests.
    • If more than one RAID level is supported on the test device and one of the RAID levels supported is not redundant, configure the device for testing with the redundant RAID level. For example, if the test device supports RAID 0 and RAID 5, configure it for testing with RAID 5, and then run all of the basic functionality tests.
    • If more than one RAID level is supported on the test device and if more than one of the RAID levels supported is redundant, configure the device for testing with a redundant RAID level of your choice, and then run all of the basic functionality tests. For example, if the test device supports RAID 0, RAID 1, and RAID 5, configure it for testing with RAID 5 or RAID 1, and then run all of the basic functionality tests.

  7. Configure the RAID system for testing with one of the following RAID sets:
      To configure the system with a RAID 0 set, use the hardware RAID configuration utility for the RAID system, and create one RAID 0 array. The array must be minimum of 18 GB, up to the largest array size that the RAID system supports.
    • To configure the RAID system for testing with a RAID 1 set, use the hardware RAID configuration utility for the RAID system, and create one RAID 1 array. The array must be minimum of 18 GB, up to the largest array size that the RAID system supports.
    • To configure the RAID system for testing with a RAID 5 set, use the hardware RAID configuration utility for the RAID system, and create one RAID 5 array. The array must be minimum of 18 GB, up to the largest array size that the RAID system supports.

To install the operating system
  1. Do one of the following:
    • If the test Fibre Channel adapter is bootable, install the operating system on a NTFS, 14-GB partition on the RAID system. Install any HBA or RAID system drivers (including multipath) that are necessary to connect to, or manage the peripheral devices.
    • If the test Fibre Channel adapter is not bootable, turn off the test system and install an ATA or SCSI hard disk drive and an alternate ATA or SCSI boot controller if they are not present.

      Next, turn on the test system, and then install the operating system on a NTFS-formatted, 14-GB partition on the ATA or SCSI hard disk drive that is connected to the alternate ATA or SCSI boot controller in the test system. Install any HBA or RAID system drivers (including multipath) that are necessary to connect to or manage the peripheral devices.

  2. From the Start menu, right-click My Computer, and click Properties.
  3. If the test operating system is Windows Vista or Windows Longhorn Server, click Advanced System Settings. If you are prompted to enter Administrative credentials or allow the action, enter the credentials or allow the action.
  4. In the General tab of the System Properties dialog box, note the amount of RAM that the computer has.
  5. Click the Advanced tab of the System Properties dialog box, and then under Performance, click Settings. The Performance Options dialog box appears.
  6. In the Advanced tab, and under Virtual Memory, click Change. The Virtual Memory dialog box appears.
  7. Click Custom Size, and then type a number that is larger than the size of RAM in the Initial Size text box.

    Note You specify the size of the page file in megabytes (MB). If the amount of RAM on your computer was specified by using gigabytes (GB) or some other measure, convert the amount of RAM to MB before choosing and entering a value for the page file size.

  8. In the Maximum Size text box, type a maximum size value that is larger than the initial size. (It is common for the maximum size to be one and a half to two times the initial size.)
  9. Click Set, and then click OK twice.
  10. In the Advanced tab of the System Properties dialog box, under Startup and Recovery, click Settings.
  11. Under Write debugging information, click the down arrow, and then select Small memory dump (64 KB).
  12. In the Small dump directory box, type X:\Minidump, where X is the drive letter of one of the RAID partitions.
  13. Click OK twice, and then restart the operating system to update the page file size.
  14. Install the Debugging Tools for Windows to the C:\Debuggers directory.
  15. Copy the Microsoft Windows Symbols files to the C:\Symbols directory.
  16. Use the Windows Disk Management utility to set up three 4-GB partitions on the RAID array that was previously created on the RAID system, and do one of the following:
    • If you are testing with a 32-bit edition of the Windows operating system, format two of the partitions with the NTFS file system, and format the third partition with the FAT32 file system.
    • If you are testing with a 64-bit edition of Windows, format all three partitions with NTFS.

  17. Use Windows Disk Management to mirror one of the 4-GB NTFS partitions on the RAID system to the non-partitioned disk space on the on the second array on the RAID system.
  18. Install DTM Client.
  19. Configure the machine for testing in DTM Studio.
    1. Add the machine to a machine pool.
    2. Deploy the WDK\ConfigureFibreChannelStorageController” dimension.


Running the Fibre Channel Adapter Tests

To test Fibre Channel adapters, do the following:

  1. Open Device Console in DTM Studio.
  2. Create a new submission for “Storage > Adapter or Controller > Fibre Channel”.
    • If the device has a driver, select the driver INF when prompted.
    • Make sure to select the Fibre Channel Adapter test from the device list.
  3. Select the tests that you want to start, choose Add Selected, and then click Schedule.

Crashdump Support Test

Setup: This test requires that the machine has Operating System Symbols installed in C:\symbols. This test will automatically install the Debugging Tools for Windows as a setup task.

Troubleshooting: If you encounter a test failure at any point before the final Logging phase of the test, ensure that you have the correct symbols.

Note This test will intentionally cause the system to stop responding. A bugcheck during the test is normal if caused by Bugcheck.sys.

Note This test restarts the system.

More Info:

Data Verification Test

Input: This test accepts a single drive letter and a PNP ID as input. These are both provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any file system.

Note This test restarts the system.

Ext Int13h Test

More Info:

HBA API Test

More Info:

Storage Device Stress

Input: This test accepts a string of drive letters as input. This string is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any file system.

More Info:

Tape IO Test

More Info:

Driver Verifier

More Info:

Device Path Exerciser

More Info:

Sleep Stress with IO

More Info:

Disable Enable with IO

More Info:

Plug and Play Driver Test

More Info:

Prefast for Drivers Test

More Info:

Static Driver Verifier Test

More Info:

Stress Test

More Info:

Stress Test with low resource simulation

More Info:

Sleep Stress Disable Enable with IO

More Info:


Troubleshooting Fibre Channel Testing

For more information about troubleshooting Fibre Channel testing, see Troubleshooting Storage Tests.


iSCSI Boot Component Testing Overview

These procedures test your iSCSI Boot Component for proper functionality by using the Microsoft Windows Driver Kit (WDK) and the Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as required for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

The test procedures are divided into the following types of topics:

  • Overview: The overview topics describe the hardware, software, and tester knowledge requirements.
  • Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.
  • Running: The running topics describe how to run the tests for your device or system.

Note: The test descriptions are included in a separate section.

iSCSI Boot Component Overview

The iSCSI Boot Component logo program verifies if the component or the system supports iSCSI boot. The iSCSI boot component can be part of the system BIOS or the iSCSI HBA, or the Network card that has Extended BIOS or the network card that uses PXE with an iSCSI boot loader program to boot. The iSCSI boot BIOS or loader program will hook int 13 to allow the operating system to boot as if there were a locally attached disk; disk reads and writes through int 13 will be redirected through iSCSI to the remote disk. The iSCSI boot BIOS or loader program will create the iBF table that contains the information that is needed for the Microsoft Windows operating system to continue booting after the operating system loader has completed and the Windows kernel has started.

The iSCSI boot component includes:

  • Pre-boot init code
  • Implementation of iBFT in firmware/BIOS
  • Crashdump support in new or existing drivers

Microsoft provides the following iSCSI Boot Components:

  • Microsoft iSCSI Software Initiator 2.02Boot +
  • Implementation of kernel-mode driver to read iBFT in firmware/BIOS

iSCSI Boot Component Tests

The tests that you need to run depend on the capabilities of the device or system that is being tested. The following list contains all of the tests that you might need for your test device:

  • Int 13h Extensions test
  • iSCSI Boot Firmware Table Test

Run time: approximately 2 hours

Hardware Requirements

The following hardware is required for iSCSI Boot Component testing. You might need additional hardware if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One computer with the following:
    • Quad-core or equivalent processor (Windows Server 2003)
    • 6 GB memory (Windows Server 2003)
    • Logo-compliant ACPI BIOS, with ACPI enabled by default
    • One dual channel ATA/ATAPI controller implemented on the motherboard

  • Hardware and software that contain the iSCSI boot component in the server option ROM, NIC option ROM/firmware, or PXE implementation.
  • A monitor, a keyboard, and a mouse.
  • A boot-capable floppy disk drive.
  • Two 1-GB network adapters.

Software Requirements

The following software is required to run the iSCSI Boot Component tests:

  • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
  • Microsoft Windows Server 2003, Datacenter Edition, with SP1
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows Server 2003, Datacenter x64 Edition
  • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
  • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems
  • Any drivers that are not shipped with the operating system
  • The current release of the Microsoft Windows Driver Kit (WDK)

Tester Knowledge Requirements

To run the iSCSI Boot Component tests, testers must know how to accomplish the following tasks:

  • Set up an iSCSI environment and record the Internet Protocol (IP) addresses and target names of the devices.
  • Set up a NIC.
  • Format and partition a hard disk.
  • Install the operating system from the product CD.

After you have reviewed the necessary requirements, you can prepare to test your iSCSI Boot Component device.

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Preparing to Test iSCSI Boot Components

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see iSCSI Boot Component Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, For more information about autologon, see [image] How to turn on automatic logon in Windows XP.

To configure the test system for iSCSI Boot Components testing

  1. Install the test device that supports iSCSI boot
  2. Install the DTM client.
  3. Configure the machine for testing in DTM Studio.
    1. Add the machine to a machine pool.
    2. Deploy the “WDK\ConfigureiScsiBootComponentStorageController” dimension.


Running the iSCSI Boot Component Tests

To test iSCSI Boot Components, do the following:

  1. Open Device Console in DTM Studio.
  2. Create a new submission for “Storage > iSCSI Boot Component”.
    • If the device has a driver, select the driver INF when prompted.
    • Make sure to select the iSCSI Boot Component test from the device list.
  3. Select the tests that you want to start, choose Add Selected, and then click Schedule.

Ext Int13h Test

More Info:

iSCSI Boot Firmware Table Test

More Info:


Troubleshooting iSCSI Boot Component Controller Testing

For more information about troubleshooting iSCSI Boot Component Controller testing, see Troubleshooting Storage Tests.


iSCSI HBA Controller Testing Overview

The procedures presented in this section outline the process for testing your iSCSI HBA for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as required for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard iSCSI HBA Controller Testing Overview.

iSCSI HBA Tests

The following lists describe the all the tests that may be required to obtain a logo for your test device, depending upon the capabilities of the device or system being tested.

The following tests require user intervention and must be run individually:

  • Int 13h Extensions (if the test device supports boot)
  • Medium Changer Test
  • iSCSI Ping Test (HBA)

The following tests are automated and can be run together in a group:

  • Crashdump Support Test
  • Disk Stress
  • iSCSI Boot (if the device supports boot)
  • iSCSI Digest - Disk (HBA)
  • iSCSI Digest - Tape (HBA)
  • iSCSI Mutual CHAP (Target)
  • iSCSI Oneway CHAP (Target)
  • iSCSI Persistent Login Test
  • iSCSI Redirection Test
  • iSCSI WMI Verification
  • Medium changer stress
  • Storage Data Verification Filter Test
  • Storage Device Stress test (SDStress)
  • Syscache Test

Run time: 3 hours

Hardware requirements

The iSCSI controller tests can be run in a single configuration. However, you may implement this configuration in one of two ways:

  1. An iSCSI controller, iSCSI disk storage system, and iSCSI tape/media changer
  2. An iSCSI controller, a bridge to another bus, and a disk storage system and tape/media changer

The following hardware is required. Additional hardware may be required if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • To obtain a Windows Server OS logo, the tests require a computer with four microprocessors and at least 6 GB of RAM.
  • To obtain a Windows Client OS logo, the tests require a computer with an Intel Pentium III (or faster) processor and at least 256 MB of RAM.
  • An iSCSI controller (the test device). One combination tape and media changer device. This must be an iSCSI device if you are testing without a bridge, or a device that connects through another bus if you are testing with a bridge.
  • Two disk storage systems. These must be iSCSI disk storage systems if you are testing without a bridge or disk storage systems that connect through another bus if you are testing with a bridge.

    Note If the test device supports boot, then two disk targets are needed. These targets may exist on the same disk storage device, as long as they have different target names.

  • An iSCSI bridge, if you are testing in a configuration with a bridge.
  • Three blank media cartridges for each drive on the tape and media changer device.
  • A monitor, a keyboard, and a mouse.
  • A boot-capable floppy disk drive, if your device supports boot.
  • Two 1-GB (gigabit) network adapters.

Important All hardware (except the test device) must be included in the Windows Catalog.

Software requirements

The following software is required to run the iSCSI HBA tests:

  • One of the following operating systems:
    • Microsoft Windows Vista
    • Microsoft Windows XP Professional with Service Pack 2 (SP2)
    • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
    • Microsoft Windows Server 2003, Datacenter Edition, with SP1
    • Microsoft Windows Server XP Professional x64 Edition
    • Microsoft Windows Server 2003, Enterprise x64 Edition
    • Microsoft Windows Server 2003, Datacenter x64 Edition
    • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
    • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems

  • Any drivers that are not shipped with the operating system
  • The current release of Microsoft WDK
  • The latest version of the Microsoft iSCSI software initiator (if the operating system is not Windows Vista).

    Note To download the iSCSI software initiator, search for iSCSI software initiator at the [image] Microsoft Download Center.

  • The Microsoft .NET Framework Version 1.1. You can get .NET 1.1 from the [image] Microsoft Download Center.

Tester knowledge requirements

To run the iSCSI HBA tests, testers must know how to accomplish the following tasks:

  • Set up an iSCSI environment and record the Internet Protocol (IP) addresses and target names of the devices
  • Set the secret for oneway and mutual CHAP (if supported)
  • Log on to iSCSI target devices
  • Format and partition a hard disk
  • Install the operating system from the product CD

After you have reviewed the necessary requirements, you can prepare to test your iSCSI HBA device.

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Preparing to test iSCSI HBA Controllers

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see iSCSI HBA Controller Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, see [image] How to turn on automatic logon in Windows XP.

Test system configuration

The iSCSI controller logo pass requires an iSCSI controller and two target devices connected to a network. Figure 1 and Figure 2, below, illustrate the two possible ways of implementing this configuration.

Figure 1: iSCSI controller configuration without a bridge

Figure 2: iSCSI controller configuration with a bridge

To assemble the test system for iSCSI controller testing

  1. Install the iSCSI controller in the test system.
  2. Connect both 1-GB network cards to the network.
  3. Connect the iSCSI controller to the network.
  4. If you are using an iSCSI bridge, connect the bridge to the network.
  5. If you are using an iSCSI bridge, connect the disk storage system and the combination tape and removable media drive to the bridge.
    – or –
    If you are not using an iSCSI bridge, connect the disk storage system and the combination tape and removable media drive to the network.

To configure the test system for iSCSI controller testing

  1. Turn on the test system.
  2. Install the Microsoft Windows operating system on one hard disk. If the iSCSI controller supports boot, then install the operating system on an iSCSI disk target that is different from the one that will be used for testing.
  3. If necessary, install any manufacturer-supplied drivers required by devices in the test system.
  4. Use the following procedure to make the system page file larger than the size of RAM:
    1. Click Start, right-click on My Computer and select Properties.
    2. On the General tab of the System Properties dialog box, find the amount of RAM that the computer has, and make a note of this value.
    3. On the Advanced tab of the System Properties dialog box, click Settings in the Performance section.
    4. On the Advanced tab of the Performance Options dialog box, click Change in the Virtual Memory section.
    5. Click Custom Size, and then enter a number that is larger than the size of RAM for the Initial Size.

      Note You specify the size of the page file in megabytes (MB). If the amount of RAM on your computer was specified using gigabytes (GB) or some other measure, convert the amount of RAM to MB before choosing and entering a value for the page file size.

    6. Enter a Maximum Size value that is larger than the initial size. (It is common for the maximum size to be 1.5 to 2 times the initial size.)
    7. Click Set.
    8. Click OK to close the Virtual Memory dialog box.
    9. Click OK to close the Performance Options dialog box.
    10. On the Advanced tab of the System Properties dialog box, under Startup and Recovery, click Settings.
    11. Under Write debugging information, select Small memory dump (64 KB) , and then type X:\minidump in the Small dump directory box, where X is the drive letter of the NTFS partition on Disk 2.
    12. Click OK to close the Startup and Recovery dialog box.
    13. Click OK to close the System Properties dialog box.
    14. Restart the computer to update the page file size.

  5. Log on to all target devices.

    Important You must be logged on to all iSCSI target devices that are used for testing, and you must not be logged on to any other iSCSI target devices, or the WDK tests will not work properly.

  6. Use Configuration Manager to create two NTFS volumes and one FAT 32 volume on the disk storage system that does not contain the operating system. The NTFS volumes must be larger than 2 GB and smaller than 4 GB. The FAT 32 volume must be smaller than 4 GB.
  7. If appropriate, enable [image] autologon functionality.

After you have prepared the test environment, you can test your iSCSI HBA device.


Testing iSCSI HBA Controllers

All the iSCSI tests require a configuration file to setup the communication between the HBA (Initiator) and the iSCSI targets. The configuration file includes the CHAP Username, target secret to Logon on to the target, the target name, target IP address, HBA PnP-ID, etc. To get all this information, any iSCSI job scheduled will display a dialog for you to enter all the information required to perform that test. The dialog will generate the configuration file, which is copied to the client machine by the WDK test harness. The following image illustrates the dialog:

The iSCSI HBA Boot Test (LOGO) dialog in DTM

Hardware Requirements

  • Two Network Cards
  • One iSCSI HBA
  • iSCSI Target (Disk, Tape, Media Changer)
  • Bootable iSCSI Disk Target (if supported)

iSCSI Boot Test

Hardware required: iSCSI HBA, Bootable iSCSI Target (Disk)

Test steps:

  1. Setup the iSCSI HBA and the iSCSI Target (Disk)
  2. Install OS on the iSCSI target
  3. Select the iSCSI HBA in the Device tree
  4. Select the iSCSI boot test Job
  5. Fill the required information in the dialog
  6. Schedule the iSCSI Boot test Job

Note: iSCSI Initiator doesn’t support the boot, so the test should fail on iSCSI Initiator

iSCSI Oneway/Mutual CHAP (HBA) Test

Hardware required: iSCSI HBA, Network Card

Test steps:

  1. Setup the iSCSI HBA
  2. Select the iSCSI HBA in the Device tree
  3. Select the iSCSI Oneway/Mutual CHAP (HBA) test Job
  4. Fill the required information in the dialog
  5. Schedule the iSCSI Oneway/Mutual CHAP (HBA) test

iSCSI Persistent Login Test

Hardware required: iSCSI HBA, iSCSI Target (Disk, Tape)

Test steps:

  1. Setup the iSCSI HBA and the iSCSI Target (Disk, Tape)
  2. Select the iSCSI HBA in the Device tree
  3. Select the iSCSI Persistent Login test Job
  4. Fill the required information in the dialog
  5. Schedule the iSCSI Persistent Login test

iSCSI Redirection Test

Hardware required: iSCSI HBA, Two Network cards

Test steps:

  1. Setup the iSCSI HBA and two network cards
  2. Make sure iSCSI HBA and the two network cards are connected to the same network
  3. Select the iSCSI HBA in the Device tree
  4. Select the iSCSI Redirection test Job
  5. Fill the required information in the dialog
  6. Schedule the iSCSI Redirection Job

iSCSI WMI Verification Test

Hardware required: iSCSI HBA, iSCSI Target (Disk, Tape)

Test steps:

  1. Setup the iSCSI HBA and the iSCSI Target (Disk, Tape)
  2. Make sure you logged on to the target
  3. Select the iSCSI HBA in the Device tree
  4. Select the iSCSI WMI Verification test Job
  5. Fill the required information in the dialog
  6. Schedule the iSCSI WMI Verification test

iSCSI Digest - Disk/Tape Test

Hardware required: iSCSI HBA, iSCSI Target (Disk, Tape)

Test steps:

  1. Setup the iSCSI HBA and the iSCSI Target (Disk, Tape)
  2. Select the iSCSI HBA in the Device tree
  3. Select the iSCSI Digest test Job
  4. Fill the required information in the dialog
  5. Schedule the iSCSI Digest test

iSCSI HBA Ping Test

Hardware required: iSCSI HBA, iSCSI Target (Disk, Tape)

Test steps:

  1. Setup the iSCSI HBA
  2. Select the iSCSI HBA in the Device tree
  3. Select the iSCSI HBA Ping test Job
  4. Fill the required information in the dialog
  5. Schedule the iSCSI Digest test
  6. Send a Ping request to the HBA


SAS Controller Testing Overview

These procedures test your SAS controller for proper functionality by using the Microsoft Windows Driver Kit (WDK) and the Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as required for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

The test procedures are divided into the following types of topics:

  • Overview: The overview topics describe the hardware, software, and tester knowledge requirements.
  • Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.
  • Running: The running topics describe how to run the tests for your device or system.

SAS Controller Tests

The tests that you need to run depend on the capabilities of the device or system that is being tested. The following list contains all of the tests that you might need for your test device:

  • Crashdump Support Test
  • Storage Data Verification Filter Test
  • Int 13h Extensions test
  • Storage Device Stress test (SDStress)
  • Tape I/O Test
  • Driver Verifier
  • Device Path Exerciser
  • System - Sleep Stress with IO
  • Disable Enable with IO
  • Plug and Play Driver Test
  • Prefast for Drivers
  • Static Driver Verifier
  • Stress Test
  • Core Stress Test

Run time: approximately 2 hours

Note The test descriptions are included in a separate section.

Hardware Requirements

The following hardware is required for SAS Controller testing testing. You might need additional hardware if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One computer with the following:
    • Dual-core or equivalent processor (Windows Vista or Windows XP)
    • Quad-core or equivalent processor (Windows Longhorn Server or Windows Server 2003)
    • 2 GB memory (Windows Vista or Windows XP)
    • 6 GB memory (Windows Longhorn Server or Windows Server 2003)
    • Logo-compliant ACPI BIOS, with ACPI enabled by default
    • A PCI-based bus
    • One monitor, one keyboard, and one mouse (or any pointing or drawing device)

  • One CD drive.
  • SAS controllers, as follows:
    • If the SAS controller is an add-on controller, two identical SAS controllers are required.
    • If the SAS controller is an embedded controller, only one SAS controller is required.
  • One SAS hard disk drive drives with the largest capacity that is available (at least 18 GB).
  • One Serial ATA hard disk drive.
  • One ATA or SCSI hard disk drive (if the test device is not bootable).
  • Two SAS edge expanders.
  • One SAS fanout expander.

Software Requirements

The following software is required to run the SAS Controller tests:

  • Microsoft Windows Vista
  • Microsoft Windows XP Professional with Service Pack 2 (SP2)
  • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
  • Microsoft Windows Server 2003, Datacenter Edition, with SP1
  • Microsoft Windows XP Professional x64 Edition
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows Server 2003, Datacenter x64 Edition
  • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
  • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems
  • Any drivers that are not shipped with the operating system
  • The current release of the Microsoft Windows Driver Kit (WDK)

Tester Knowledge Requirements

To run the SAS Controller tests, testers must know how to accomplish the following tasks:

  • Install a hard disk drive.
  • Format and partition a hard disk drive, including low-level formatting.
  • Install a CD drive.
  • Install an SAS controller.
  • Access and change the system BIOS settings.
  • Install and use Microsoft Debugging Tools for Windows.
  • Install and use Microsoft Windows Symbols files.
  • Install the operating system from the product CD.

After you have reviewed the necessary requirements, you can prepare to test your SAS Controller device.

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Preparing to Test SAS Controllers

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see the SAS Controller Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, For more information about autologon, see [image] How to turn on automatic logon in Windows XP.

Test system configuration

There are two different procedures for configuring your SAS controller for testing:

  • Run the tests in configuration 1 only if your device is an add-on SAS controller.
  • Run the tests in configuration 2 only if your device is an embedded SAS controller.

For more information about configuring an SAS controller for basic functionality testing, see the following topics:

Preparing for SAS Controller Testing with Configuration 1

Preparing for SAS Controller Testing with Configuration 2


Preparing for SAS Controller Testing with Configuration 1

Note Run the tests in configuration 1 only if your device is an add-on SAS controller.

Figure 1 displays the configuration of an add-on SAS controller test system.

Figure 1: Configuration of an add-on SAS controller test system

Before running the tests, you must assemble the system and install the operating system. This section summarizes the related procedures.

To assemble the test system for SAS controller configuration 1 testing

    Note All adapters are operated with BIOS enabled and external termination, unless otherwise noted.

  1. Turn off the test system and disconnect it from the electrical socket.
  2. Install the two SAS controllers. These controllers are referred to as Controller 1 and Controller 2.
  3. Install the SAS hard disk drive on Controller 1. This hard disk drive is referred as Disk 1.
  4. Connect the Serial ATA hard disk drive to Controller 2 by using the following cable configuration:
    • Controller 2 is connected to an edge expander.
    • The edge expander is connected to a fanout expander.
    • The fanout expander is connected to an edge expander.
    • The edge expander is connected to the Serial ATA hard disk drive. This hard disk drive is referred to as Disk 2.
  5. Install the CD drive.
  6. If the test device is not bootable, install an ATA or SCSI hard disk drive.
To configure the test system for SAS controller configuration 1 testing
  1. Set the system BIOS to support the S3 state.

    Note For Microsoft Windows Server 2003, only support for the S4 sleep state is required.

  2. Install the appropriate Microsoft Windows operating system, as follows:
    • If the test device is bootable, install the operating system on Disk 1.
    • If the test device is not bootable, install the operating system on the ATA or SCSI hard disk drive.

    During installation, delete any existing partitions and create one partition that uses a minimum of 8.5 GB of disk space, leaving a minimum of 2 GB of free space. Format the partition with the NTFS file system.

  3. If necessary, install any drivers that a manufacturer supplies that the devices in the test system require.
  4. Create one 100-GB partition on Disk 2.
  5. Do the following to make the system page file larger than the size of RAM:
    1. Click Start, right-click My Computer, and click Properties.
    2. If the test operating system is Windows Vista or Windows Longhorn Server, click Advanced System Settings. If you are prompted to enter Administrative credentials or allow the action, enter the credentials or allow the action.
    3. In the General tab, note the amount of RAM that the computer has.
    4. Click the Advanced tab, and then under Performance, click Settings. The Performance Options dialog box appears.
    5. Click the Advanced tab, and under Virtual Memory, click Change. The Virtual Memory dialog box appears.
    6. Click Custom Size, and then type a number that is larger than the size of RAM in the Initial Size text box.

      Note You specify the size of the page file in megabytes (MB). If the amount of RAM on your computer was specified by using gigabytes (GB) or some other measure, convert the amount of RAM to MB before choosing and entering a value for the page file size.

    7. In the Maximum Size text box, type a maximum size value that is larger than the initial size. (It is common for the maximum size to be one and a half to two times the initial size.)
    8. Click Set, and then click OK twice.
    9. Click the Advanced tab of the System Properties dialog box, under Startup and Recovery, click Settings.
    10. Under Write debugging information, click the down arrow, and then select Small memory dump (64 KB).
    11. In the Small dump directory box, type X:\Minidump, where X is the drive letter of the NTFS partition on Disk 2.
    12. Click OK twice, and then restart the computer to update the page file size.
  6. Install the Debugging Tools for Windows to C:\Debuggers.
  7. Copy the Microsoft Windows Symbol files to C:\Symbols.
  8. If appropriate, enable the autologon functionality. For more information about autologon, see [image] How to turn on automatic logon in Windows XP.
  9. Install the DTM Client.


Preparing for SAS Controller Testing with Configuration 2

Note Run the tests in this configuration only if your device is an embedded SAS controller.

Before running the tests, you must assemble the system and install the operating system. This section summarizes the related procedures.

To assemble the test system for SAS controller configuration 2 testing

    Note All adapters are operated with BIOS enabled and external termination, unless otherwise noted.

  1. Turn off the test system and disconnect it from the electrical socket.
  2. Install the SAS hard disk drive on the test device. This hard disk drive is referred to as Disk 1.
  3. Connect the Serial ATA hard disk drive to the test device.
  4. Connect the Serial ATA hard disk drive to the test controller by using the following cable configuration:
    • The test controller is connected to an edge expander.
    • The edge expander is connected to a fanout expander.
    • The fanout expander is connected to an edge expander.
    • The edge expander is connected to the Serial ATA hard disk drive. This hard disk drive is referred to as Disk 2.
  5. Install the CD drive.

To configure the test system for SAS controller configuration 2 testing
  1. Turn on the test system and set the system BIOS to boot from the CD.
  2. Set the system BIOS to support the S3 state.

    Note For Microsoft Windows Server 2003, only support for the S4 sleep state is required.

  3. Install the appropriate Microsoft Windows operating system on Disk 1. During installation, delete any existing partitions and create one partition that uses a minimum of 8.5 GB of disk space, leaving a minimum of 2 GB of free space. Format the partition with the NTFS file system.
  4. If necessary, install any drivers that a manufacturer supplies that the devices in the test system require.
  5. Create one 100-GB partition on Disk 2.
  6. Do the following to make the system page file larger than the size of RAM:
    1. Click Start, right-click My Computer, and click Properties.
    2. If the test operating system is Windows Vista or Windows Longhorn Server, click Advanced System Settings. If you are prompted to enter Administrative credentials or allow the action, enter the credentials or allow the action.
    3. In the General tab, note the amount of RAM that the computer has.
    4. Click the Advanced tab, and then under Performance, click Settings. The Performance Options dialog box appears.
    5. Click the Advanced tab, and under Virtual Memory, click Change. The Virtual Memory dialog box appears.
    6. Click Custom Size, and then type a number that is larger than the size of RAM in the Initial Size text box.

      Note You specify the size of the page file in megabytes (MB). If the amount of RAM on your computer was specified by using gigabytes (GB) or some other measure, convert the amount of RAM to MB before choosing and entering a value for the page file size.

    7. In the Maximum Size text box, type a maximum size value that is larger than the initial size. (It is common for the maximum size to be one and a half to two times the initial size.)
    8. Click Set, and then click OK twice.
    9. Click the Advanced tab of the System Properties dialog box, under Startup and Recovery, and click Settings.
    10. Under Write debugging information, click the down arrow, and then select Small memory dump (64 KB).
    11. In the Small dump directory box, type X:\Minidump, where X is the drive letter of the NTFS partition on Disk 2.
    12. Click OK twice, and then restart the computer to update the page file size.
  7. Install the Debugging Tools for Windows to C:\Debuggers.
  8. Copy the Microsoft Windows Symbol files to C:\Symbols.
  9. If appropriate, enable the autologon functionality. For more information about autologon, see [image] How to turn on automatic logon in Windows XP.
  10. Install the DTM Client.
  11. Configure the machine for testing in DTM Studio:
    1. Add the machine to a machine pool.
    2. Deploy the WDK\ConfigureSasStorageController” dimension.


Running the SAS Controller Tests

To test SAS controllers, do the following:

  1. Open Device Console in DTM Studio.
  2. Create a new submission for “Storage > Adapter or Controller > SAS”.
    • If the device has a driver, select the driver INF when prompted.
    • Make sure to select the SAS Controller test from the device list.
  3. Select the tests that you want to start, choose Add Selected, and then click Schedule.

Crashdump Support Test

Setup: This test requires that the machine has Operating System Symbols installed in C:\symbols. This test will automatically install the Debugging Tools for Windows as a setup task.

Troubleshooting: If you encounter a test failure at any point before the final Logging phase of the test, ensure that you have the correct symbols.

Note This test will intentionally cause the system to stop responding. A bugcheck during the test is normal if caused by Bugcheck.sys.

Note This test restarts the system.

More Info:

Data Verification Test

Input: This test accepts a single drive letter and a PNP ID as input. These are both provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any file system.

Note This test restarts the system.

Ext Int13h Test

More Info:

Storage Device Stress

Input: This test accepts a string of drive letters as input. This string is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any file system.

More Info:

Tape IO Test

More Info:

Driver Verifier

More Info:

Device Path Exerciser

More Info:

Sleep Stress with IO

More Info:

Disable Enable with IO

More Info:

Plug and Play Driver Test

More Info:

Prefast for Drivers Test

More Info:

Static Driver Verifier Test

More Info:

Stress Test

More Info:

Stress Test with low resource simulation

More Info:

Sleep Stress Disable Enable with IO

More Info:


Troubleshooting SAS Controller Testing

For more information about troubleshooting SAS Controller testing, see Troubleshooting Storage Tests.


SAS RAID Controller Testing Overview

These procedures test your SAS RAID controller for proper functionality by using the Microsoft Windows Driver Kit (WDK) and the Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as required for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

The test procedures are divided into the following types of topics:

  • Overview: The overview topics describe the hardware, software, and tester knowledge requirements.
  • Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.
  • Running: The running topics describe how to run the tests for your device or system.

SAS RAID Controller Tests

The tests that you need to run depend on the capabilities of the device or system that is being tested. The following list contains all of the tests that you might need for your test device:

  • Crashdump Support Test
  • Storage Data Verification Filter Test
  • Int 13h Extensions test
  • Storage Device Stress test (SDStress)
  • Tape I/O Test
  • Driver Verifier
  • Device Path Exerciser
  • System - Sleep Stress with IO
  • Disable Enable with IO
  • Plug and Play Driver Test
  • Prefast for Drivers
  • Static Driver Verifier
  • Stress Test
  • Core Stress Test

Run time: approximately 2 hours

Note The test descriptions are included in a separate section.

Hardware Requirements

The following hardware is required for SAS RAID Controller testing. You might need additional hardware if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One computer with the following:
    • Dual-core or equivalent processor (Windows Vista or Windows XP)
    • Quad-core or equivalent processor (Windows Longhorn Server or Windows Server 2003)

      Note A system that contains two microprocessors that support hyper-threading can be used if hyper-threading is enabled.

    • 2 GB memory (Windows Vista or Windows XP)
    • 6 GB memory (Windows Longhorn Server or Windows Server 2003)

      Important The operating system must report that a minimum of 5500 MB of RAM is free and available. If you are testing the SAS RAID controller on Windows XP Professional, or if the SAS RAID controller will be sold only in systems that do not support four processors or 6 GB of RAM, the test system must have at least one microprocessor and 256 MB of RAM.

    • A PCI-based bus
    • Logo-compliant ACPI BIOS, with ACPI enabled by default

    Note For Windows Vista and Windows XP Professional, the test system must support S3 and S4 states.

    For Windows XP Professional on mobile systems, the test system must support the S4 state and the S1 or S3 state.

    For Windows Server 2003, the test system is required only to support the S4 state.

  • If the SAS RAID controller is not bootable, one bootable ATA or SCSI controller and one ATA or SCSI hard disk drive are required.
  • One ATA or SCSI CD-ROM drive.
  • If the test device is an add-on SAS RAID controller, you must have:
    • Two identical test devices.
    • One of the following:
      • Two SAS JBODs. One SAS JBOD must support a minimum of three hard disk drives, and the other SAS JBOD must support a minimum of six hard disk drives.
      • One SAS JBOD and three SAS hard disk drives. The SAS JBOD must support a minimum of six hard disk drives.
      • One SAS JBOD and six Serial ATA hard disk drives. The SAS JBOD must support a minimum of three hard disk drives.
      • Three SAS hard disk drives and six Serial ATA hard disk drives.
  • If the test device is an integrated SAS RAID controller, you must have:
    • Only one test device.
    • One of the following:
      • One SAS JBOD that supports a minimum of six hard disk drives.
      • Six SAS hard disk drives.

  • One PCI-to-PCI bridge adapter.

    Note A PCI-to-PCI bridge adapter is not required if any of the following apply:

    • The SAS RAID controllers cannot fit into PCI bridge adapters. This situation might occur with integrated controllers or controllers that can fit only into specially designed slots.
    • The SAS RAID controller is designed and sold only for systems that cannot accept full height PCI-to-PCI bridge adapters. This situation might occur with a blade server.
    • One of the SAS RAID controllers can be placed into a PCI bus slot that is already behind a PCI bridge.

  • If you are using six Serial ATA hard disk drives instead of a SAS JBOD, twelve SAS edge expanders and six SAS fanout expanders are required.

Important The test system must have received the "Designed for Windows" logo. All hardware (except for the device under test, monitor, keyboard, mouse and the floppy disk drive) must be included in the Windows Catalog.

Software Requirements

The following software is required to run the SAS RAID Controller tests:

  • Microsoft Windows Vista
  • Microsoft Windows XP Professional with Service Pack 2 (SP2)
  • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
  • Microsoft Windows Server 2003, Datacenter Edition, with SP1
  • Microsoft Windows XP Professional x64 Edition
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows Server 2003, Datacenter x64 Edition
  • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
  • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems
  • Any drivers that are not shipped with the operating system
  • The current release of the Microsoft Windows Driver Kit (WDK)

Tester Knowledge Requirements

To run the SAS RAID Controller tests, testers must know how to accomplish the following tasks:

  • Access and change the system BIOS settings.
  • Install SAS and ATA hard disk drives.
  • Install a SAS RAID controller.
  • Configure a RAID array.
  • Install a PCI-to-PCI bridge.
  • Install and configure Microsoft Debugging Tools for Windows.
  • Install Microsoft Windows Symbols files.
  • Install the appropriate operating system.
  • Download and install an operating system service pack.
  • Read and interpret test logs.
  • Report bugs in a standard bug format.

After you have reviewed the necessary requirements, you can prepare to test your SAS RAID controller device.

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Preparing to Test SAS RAID Controllers

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see SAS RAID Controller Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, For more information about autologon, see [image] How to turn on automatic logon in Windows XP.

Test system configuration

There are two different procedures for configuring an SAS RAID controller for basic functionality testing. Use the default configuration in most situations. However, if one of the following exceptions applies, use the secondary configuration:

  • The SAS RAID controller test device is an integrated controller.

    Note Use the default procedure for integrated controllers if a system that meets the hardware requirements with two of the integrated controllers is available or if a duplicate PCI adapter version of this SAS RAID controller is available.

  • The SAS RAID controller is designed for and sold only in a host test system that will accept only a single version of the controller.

For more information about configuring an SAS RAID controller for basic functionality testing, see the following topics:

Preparing for SAS RAID Controller Testing with the Default Configuration

Preparing for SAS RAID Controller Testing with the Secondary Configuration


Preparing for SAS RAID Controller Testing with the Default Configuration

Use the following procedure to configure the test system and test an SAS RAID controller, unless one or both of the following conditions applies:

  • The SAS RAID controller test device is an integrated controller.

    Note Use the default procedure for integrated controllers if a system that meets the hardware requirements with two of the integrated controllers is available or if a duplicate PCI adapter version of the SAS RAID controller is available.

  • The SAS RAID controller is designed for, and sold only in, a host test system that will accept only a single version of the controller.

If one of the preceding conditions applies, use the secondary configuration for SAS RAID Controller testing.

Before you run the SAS RAID controller logo tests, you must assemble the test system, configure the test system, install the operating system, and then install the DTM Client according to the following procedures.

To assemble the test system

    Note All adapters should be operated with BIOS enabled and write caching enabled.

  1. Turn off the test system.
  2. If the test device is not bootable, install one boot-capable, add-in controller (not the test device) that has signed drivers or in-box support.
  3. Attach a CD-ROM drive to the system if one is not already attached.
  4. Install one SAS RAID controller (controller 1).
  5. Connect one SAS JBOD or three SAS hard disk drives to controller 1.
  6. Install a PCI-to-PCI bridge in a PCI slot on the host test system, unless any of the following conditions apply:
    • The SAS RAID controller cannot fit into a PCI bridge adapter, which might occur with integrated controllers or controllers that can fit only into specially designed slots.
    • The SAS RAID controller is designed and sold only for systems that cannot accept full-height PCI-to-PCI bridge adapters, which might occur with blade servers.
    • One of the SAS RAID controllers can be placed into a PCI bus slot that is already behind a PCI bridge.
  7. Install a secondary, duplicate SAS RAID controller (controller 2) into the PCI-to-PCI bridge card.

    Note Install the secondary SAS RAID controller directly into a PCI slot if a PCI bridge card is not required.

  8. If possible, set the first and second SAS RAID controllers to use the same IRQ.
  9. Connect one SAS JBOD or six Serial ATA hard disk drives to controller 2, and, if you are using Serial ATA hard disk drives instead of a SAS JBOD, use the following cable configuration for each Serial ATA hard disk drive
    • The SAS controller is connected to an edge expander.
    • The edge expander is connected to a fanout expander.
    • The fanout expander is connected to an edge expander.
    • The edge expander is connected to the Serial ATA hard disk drive.
  10. If the test system contains any USB floppy disk drives or LS-120 drives, remove them and replace them with standard ATA floppy disk drives.
  11. Turn on the test system.
To configure the test system
  1. Create one 40-GB RAID array on controller 1 and two 40-GB RAID arrays on controller 2. The RAID array on controller 1 is referred to as RAID Array 1, and the RAID arrays on controller 2 are referred to as RAID Array 2 and RAID Array 3.

    Note If the test device does not support enough hard disk drives to configure the required RAID arrays, install an additional hard disk drive on an add-in controller, and create RAID Array 3 on this hard disk drive.

  2. Configure the RAID arrays according to the following table.
    If the test device supports these RAID levels | RAID level for RAID Array 1 | RAID level for RAID Array 2 | RAID level for RAID Array 3
    0 only | 0 | 0 | 0
    1 only | 1 | 1 | 1
    5 only | 5 | 5 | 5
    0 and 1 only | 1 | 0 | 1
    0 and 5 only | 5 | 0 | 5
    1 and 5 only | 5 | 1 | 5
    0, 1, and 5 | 5 | 0 | 1

To install the operating system with the default configuration

    Use the following procedure to install the operating system. When you are finished, the RAID array will be configured as shown in Figure 1 for Microsoft Windows XP and as shown in Figure 2 for Windows Server 2003, Enterprise Edition.

    Figure 1: RAID array default configuration for Windows XP

    Figure 2: RAID array default configuration for Windows Server 2003, Enterprise Edition

  1. Install the operating system on a partition, as follows:
    • If the test ATA RAID controller is bootable, install the operating system on a 14-GB NTFS partition on RAID Array 1.
    • If the ATA RAID controller is not bootable, install the operating system on a 14-GB NTFS partition on a hard disk drive that is connected to an alternate, non-test boot controller in the host test system.
  2. Install any software or drivers that are necessary to connect to and manage the peripheral devices.

    Note All drivers, except the drivers for the test device, must be signed and must be listed in Windows Catalog.

  3. Click Start, right-click My Computer, and then click Properties.
  4. Click the General tab, and then note the amount of RAM that the computer has.
  5. Click the Advanced tab, and then under Performance, click Settings. The Performance Options dialog box appears.
  6. Click the Advanced tab, and then under Virtual Memory, click Change. The Virtual Memory dialog box appears.
  7. Click Custom Size, and then type a number that is larger than the size of RAM in the Initial Size text box.

    Note You specify the size of the page file in megabytes (MB). If the amount of RAM on your computer was specified by using gigabytes (GB) or some other measure, convert the amount of RAM to MB before choosing and entering a value for the page file size.

  8. In the Maximum Size text box, type a maximum size value that is larger than the initial size. (It is common for the maximum size to be one and a half to two times the initial size.)
  9. Click Set, and then click OK twice.
  10. In the Advanced tab of the System Properties dialog box, under Startup and Recovery, click Settings.
  11. Under Write debugging information, click the down arrow, and then select Small memory dump (64 KB).
  12. In the Small dump directory box, type X:\Minidump, where X is the drive letter of one of the RAID partitions.
  13. Click OK twice, and then restart the computer to update the page file size.
  14. Install the Debugging Tools for Windows to the C:\Debuggers directory.
  15. Copy the Microsoft Windows Symbols files to the C:\Symbols directory.
  16. Use Windows Disk Management to make all of the disks dynamic.

    Important If the test device is not bootable at this point, you are booting from an alternate boot controller. Do not add any partitions to the hard disks on the alternate boot controller.

  17. Use the Windows Disk Management utility to set up three 4-GB partitions on RAID Array 2, and do one of the following:
    • If you are testing with a 32-bit edition of the Windows operating system, format two of the partitions with the NTFS file system, and format the third partition with the FAT32 file system.
    • If you are testing with a 64-bit edition of Windows, format all three partitions with NTFS.
  18. If you are testing with Windows Server 2003, use Windows Disk Management to create a software RAID 1 mirror from one of the NTFS partitions on RAID Array 2 to the unallocated space on RAID Array 1.
  19. If you are testing with Windows Server 2003, use Windows Disk Management to create a 4-GB NTFS software RAID 5 array that uses unallocated space on RAID Array 1, RAID Array 2, and RAID Array 3.
  20. If you are testing with Windows Vista or Windows XP, use Windows Disk Management to create a 4-GB NTFS spanned volume that uses RAID Array 1, RAID Array 2, and RAID Array 3.
  21. Install DTM Client.
  22. Configure the machine for testing in DTM Studio.
    1. Add the machine to a machine pool.
    2. Deploy the WDK\ConfigureSasRaidStorageController” dimension.


Preparing for SAS RAID Controller Testing with the Secondary Configuration

Use the following procedure to configure the test system and test a SAS RAID controller only if the ATA RAID controller test device is an integrated controller.

Important This procedure cannot be used for integrated controllers if a system that meets hardware requirements with two of the integrated controllers is available or if there is a duplicate PCI adapter version of this SAS RAID controller available.

If the preceding situations do not apply, use the default configuration for SAS RAID Controller testing.

Before you run the SAS RAID controller logo tests, you must configure the test system, configure the SAS RAID controller, install the operating system, and then install the DTM Client according to the following procedures.

To configure the test system for SAS RAID controller testing

    Note All adapters should be operated with BIOS enabled and write caching enabled.

  1. Turn off the test system.
  2. Install an add-in controller (not the test device) that has signed drivers or in-box support. If the test device is not bootable, the add-in controller must be boot-capable.
  3. If the test device is not bootable, attach a hard disk drive to the add-in controller. This disk is referred to as Disk 1.
  4. Attach a CD-ROM drive to the add-in controller.
  5. Install one SAS RAID controller (the test device).
  6. Connect one SAS JBOD or six SAS hard disk drives to the SAS RAID controller.
  7. If the test system contains any USB floppy disk drives or LS-120 drives, remove them and replace them with standard ATA floppy disk drives.
To configure the SAS RAID controller for basic functionality testing
  1. Create RAID arrays in one of the following ways:
    • If the test device supports enough hard disk drives to create two RAID arrays, create two 40-GB RAID arrays on the test device. These RAID arrays are referred to as RAID Array 1 and RAID Array 2.
    • If the test device does not support enough hard disk drives to create two RAID arrays, create one 40-GB RAID array on the test device. This RAID array is referred to as RAID Array 1. Attach a hard disk drive to the add-in controller, and use this hard disk drive instead of RAID Array 2 wherever RAID Array 2 is mentioned in the following steps.
  2. Configure the RAID arrays according to the following table:
    If the test device supports these RAID levels | RAID level for RAID Array 1 | RAID level for RAID Array 2
    0 only | 0 | 0
    1 only | 1 | 1
    5 only | 5 | 5
    0 and 1 only | 1 | 0
    0 and 5 only | 5 | 0
    1 and 5 only | 5 | 1
    0, 1, and 5 | 5 | 1

To install the operating system in the secondary configuration

    Use the following procedure to install the operating system. When you are finished, the RAID array will be configured as shown in Figure 3 for a test device that supports enough hard disk drives to create two RAID arrays, and as shown in Figure 4 for a test device that does not support enough hard disk drives to create two RAID arrays.

    Figure 3: RAID array secondary configuration for a device that supports enough hard disk drives to create two RAID arrays

    Figure 4: RAID array secondary configuration for a device that does not support enough hard disk drives to create two RAID arrays

  1. Install the operating system on a partition of RAID Array 1 or Disk 1, as follows:
    • If the test ATA RAID controller is bootable, install the operating system onto a 14-GB NTFS partition on RAID Array 1.
    • If the test ATA RAID controller is not bootable, install the operating system onto a 14-GB NTFS partition on Disk 1.
  2. Install any software or drivers that are necessary to connect to and manage the peripheral devices.
  3. Click Start, right-click My Computer, and then click Properties.
  4. On Windows Vista or Windows Longhorn Server, click Advanced System Settings. If you are prompted to enter Administrative credentials or allow the action, enter the credentials or allow the action.
  5. Click the General tab, and note the amount of RAM that the computer has.
  6. Click the Advanced tab, and then under Performance, click Settings. The Performance Options dialog box appears.
  7. Click the Advanced tab, and then under Virtual Memory, click Change. The Virtual Memory dialog box appears.
  8. Click Custom Size, and then type a number that is larger than the size of RAM in the Initial Size text box.

    Note You specify the size of the page file in megabytes (MB). If the amount of RAM on your computer was specified by using gigabytes (GB) or some other measure, convert the amount of RAM to MB before choosing and entering a value for the page file size.

  9. In the Maximum Size text box, type a maximum size value that is larger than the initial size. (It is common for the maximum size to be one and a half to two times the initial size.)
  10. Click Set, and then click OK twice.
  11. In the Advanced tab of the System Properties dialog box, under Startup and Recovery, click Settings.
  12. Under Write debugging information, click the down arrow, and then click Small memory dump (64 KB).
  13. In the Small dump directory box, type X:\Minidump, where X is the drive letter of one of the RAID partitions.
  14. Click OK twice, and then restart the computer to update the page file size.
  15. Install the Debugging Tools for Windows to the C:\Debuggers directory.
  16. Copy the Microsoft Windows Symbols files to the C:\Symbols directory.
  17. Use Windows Disk Management to make all of the disks dynamic.

    Important If the test device is not bootable at this point, you are booting from an alternate boot controller.

  18. Use the Windows Disk Management utility to set up three 4-GB partitions on RAID Array 1, and then do one of the following:
    1. If you are testing with a 32-bit edition of the Windows operating system, format two of the partitions with the NTFS file system, and format the third partition with FAT32.
    2. If you are testing with a 64-bit edition of Windows, format all three partitions with NTFS.
  19. If you are testing with Microsoft Windows Server 2003, Enterprise Edition, use Windows Disk Management to create a software RAID 1 mirror from one of the NTFS partitions on RAID Array 1 to the unallocated space on RAID Array 2.
  20. If you are testing with Windows Server 2003, Enterprise Edition, use Windows Disk Management to create a 4-GB NTFS software RAID 5 array that uses unallocated space on RAID Array 1 and RAID Array 2.
  21. If you are testing with Windows Vista or Windows XP, use Windows Disk Management to create a spanned volume that uses the unallocated space on RAID Array 1 and RAID Array 2.
  22. Install DTM Client.
  23. Configure the machine for testing in DTM Studio:
    1. Add the machine to a machine pool.
    2. Deploy the WDK\ConfigureSasRaidStorageController” dimension.


Running the SAS RAID Controller Tests

To test SAS RAID Controllers, do the following:

  1. Open Device Console in DTM Studio.
  2. Create a new submission for “Storage > Adapter or Controller > SAS-RAID”.
    • If the device has a driver, select the driver INF when prompted.
    • Make sure to select the test SAS RAID Controller from the device list.
  3. Select the tests that you want to start, choose Add Selected, and then click Schedule.

Crashdump Support Test

Setup: This test requires that the machine has Operating System Symbols installed in C:\symbols. This test will automatically install the Debugging Tools for Windows as a setup task.

Troubleshooting: If you encounter a test failure at any point before the final Logging phase of the test, ensure that you have the correct symbols.

Note This test will intentionally cause the system to stop responding. A bugcheck during the test is normal if caused by Bugcheck.sys.

Note This test restarts the system.

More Info:

Data Verification Test

Input: This test accepts a single drive letter and a PNP ID as input. These are both provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any file system.

Note This test restarts the system.

Ext Int13h Test

More Info:

Storage Device Stress

Input: This test accepts a string of drive letters as input. This string is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any file system.

More Info:

Tape IO Test

More Info:

Driver Verifier

More Info:

Device Path Exerciser

More Info:

Sleep Stress with IO

More Info:

Disable Enable with IO

More Info:

Plug and Play Driver Test

More Info:

Prefast for Drivers Test

More Info:

Static Driver Verifier Test

More Info:

Stress Test

More Info:

Stress Test with low resource simulation

More Info:

Sleep Stress Disable Enable with IO

More Info:


Troubleshooting SAS-RAID Controller Testing

For more information about troubleshooting SAS-RAID Controller testing, see Troubleshooting Storage Tests.


SCSI Controller Testing Overview

These procedures test your SCSI controller for proper functionality by using the Microsoft Windows Driver Kit (WDK) and the Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as required for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

The test procedures are divided into the following types of topics:

  • Overview: The overview topics describe the hardware, software, and tester knowledge requirements.
  • Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.
  • Running: The running topics describe how to run the tests for your device or system.

SCSI Controller Tests

The tests that you need to run depend on the capabilities of the device or system that is being tested. The following list contains all of the tests that you might need for your test device:

  • Crashdump Support Test
  • Storage Data Verification Filter Test
  • Int 13h Extensions test
  • NTBackup test
  • Storage Device Stress test (SDStress)
  • Tape I/O Test
  • Driver Verifier
  • Device Path Exerciser
  • System - Sleep Stress with IO
  • Disable Enable with IO
  • Plug and Play Driver Test
  • Prefast for Drivers
  • Static Driver Verifier
  • Stress Test
  • Core Stress Test

Run time: approximately 2 hours

Note The test descriptions are included in a separate section.

Hardware Requirements

The following hardware is required for SCSI controller testing. You might need additional hardware if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One computer with the following:
    • Dual-core or equivalent processor (Windows Vista or Windows XP)
    • Quad-core or equivalent processor (Windows Longhorn Server or Windows Server 2003)
    • 2 GB memory (Windows Vista or Windows XP)
    • 6 GB memory (Windows Longhorn Server or Windows Server 2003)
    • Logo-compliant ACPI BIOS, with ACPI enabled by default
    • A PCI-based bus
    • One boot-capable floppy disk drive
    • One monitor, one keyboard, and one mouse (or any pointing or drawing device)

  • Two identical SCSI controllers (the test devices).
  • One PCI-to-PCI bridge.
  • Three identical SCSI hard disk drives with the largest capacity available (and at least a 18 GB capacity). If the test device supports Wide SCSI, all hard disk drives that are used for testing must be Wide SCSI.
  • Two SCSI CD-ROM drives (with at least an 8X speed).
  • One SCSI removable media drive.
  • One SCSI tape drive. If the test device supports Wide SCSI, the tape drive must be Wide SCSI.
  • One blank tape cartridge that is prepared for use.

Software Requirements

The following software is required to run the SCSI controller tests:

  • Microsoft Windows Vista
  • Microsoft Windows XP Professional with Service Pack 2 (SP2)
  • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
  • Microsoft Windows Server 2003, Datacenter Edition, with SP1
  • Microsoft Windows XP Professional x64 Edition
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows Server 2003, Datacenter x64 Edition
  • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
  • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems
  • Any drivers that are not shipped with the operating system
  • The current release of the Microsoft Windows Driver Kit (WDK)

Tester Knowledge Requirements

To run the SCSI controller tests, testers must know how to accomplish the following tasks:

  • Install a hard disk drive.
  • Format and partition a hard disk drive, including low-level formatting.
  • Physically set the SCSI ID on a hard disk drive.
  • Install a CD-ROM drive.
  • Install a tape drive.
  • Prepare a blank tape cartridge for use.
  • Install a removable media drive.
  • Format and partition a removable media drive.
  • Install a SCSI controller.
  • Install a PCI-to-PCI bridge.
  • Set asynchronous negotiation on a SCSI controller.
  • Access and change the system BIOS settings.
  • Install and use Microsoft Debugging Tools for Windows.
  • Install and use Microsoft Windows Symbols files.
  • Install the operating system from the product CD.

After you have reviewed the necessary requirements, you can prepare to test your SCSI controller device.

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Preparing to Test SCSI Controllers

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see SCSI Controller Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, For more information about autologon, see [image] How to turn on automatic logon in Windows XP.

There are two different procedures for configuring your SCSI controller for testing:

  • Run the tests in configuration 1 only if your device is an add-on SCSI controller.
  • Run the tests in configuration 2 only if your device is an embedded SCSI controller.

For more information about configuring an SCSI controller for basic functionality testing, see the following topics:

Preparing for SCSI Controller Testing with Configuration 1

Preparing for SCSI Controller Testing with Configuration 2


Preparing for SCSI Controller Testing with Configuration 1

Note Run the tests in configuration 1 only if your device is an add-on SCSI controller.

Figure 1 displays configuration 1 for an add-on SCSI controller test system.

Figure 1: Configuration 1 for an add-on SCSI controller test system

Before you run the SCSI controller logo program tests for configuration 1, you must assemble the test system, configure the test system, and install the operating system. This topic describes the related procedures for these tasks.

To assemble the test system for SCSI controller configuration 1 testing

    Note All adapters are operated with BIOS enabled and external termination, unless otherwise noted.

  1. Turn off the test system and disconnect it from the electrical socket.
  2. Install the SCSI controller (the test device). This controller is referred to as SCSI Controller 1.
  3. Install the SCSI hard disk drive on the test device. This hard disk drive is referred as Drive 1.
  4. Install one SCSI CD-ROM drive on SCSI Controller 1. This CD-ROM drive is referred to as CD 1.
  5. Install one SCSI tape drive on SCSI Controller 1.
  6. Install one SCSI removable media drive on SCSI Controller 1.
  7. Install a PCI-to-PCI bridge in the test system.
  8. Install a duplicate SCSI controller on the PCI-to-PCI bridge. This controller is referred to as SCSI Controller 2.
  9. Install a SCSI hard disk drive on SCSI Controller 2. This hard disk drive is referred to as Drive 2.
  10. Install a SCSI CD-ROM drive on SCSI Controller 2. This CD-ROM drive is referred to as CD 2.
To configure the test system for SCSI controller configuration 1 testing
  1. Turn on the test system and set the system BIOS to boot from CD 1.
  2. Set the system BIOS to support the S3 state.

    Note For Windows Server 2003, only support for the S4 sleep state is required.

  3. By using the test device's format function, add low-level formatting to all hard disks.
  4. Install the appropriate Microsoft Windows operating system on Drive 1.

    Note If you are testing a non-bootable SCSI controller, install the appropriate Microsoft Windows operating system on the hard disk drive that is attached to the alternate boot controller (Drive 1).

    During installation, delete any existing partitions and create one partition that uses a minimum of 8.5 GB of disk space, leaving a minimum of 2 GB of free space. Format the partition with the NTFS file system.

  5. If necessary, install any drivers that a manufacturer supplies that the devices in the test system require.
  6. Verify that SCSI Controller 2 is supported in its position on the PCI-to-PCI adapter.
  7. On Drive 2, delete any existing partitions and create one new partition of a minimum of 2 GB, and then format this partition with the FAT 32 file system.
  8. If you are testing with Microsoft Windows Server 2003, use Windows Disk Management to mirror the NTFS partition on Drive 2 to the free disk space on Drive 1.
  9. Do the following to make the system page file larger than the size of RAM:
    1. Click Start, right-click My Computer, and click Properties.
    2. If the test operating system is Windows Vista or Windows Longhorn Server, click Advanced System Settings. If you are prompted to enter Administrative credentials or allow the action, enter the credentials or allow the action.
    3. In the General tab, note the amount of RAM that the computer has.
    4. Click the Advanced tab, and then under Performance, click Settings. The Performance Options dialog box appears.
    5. Click the Advanced tab, and under Virtual Memory, click Change. The Virtual Memory dialog box appears.
    6. Click Custom Size, and then type a number that is larger than the size of RAM in the Initial Size text box.

      Note You specify the size of the page file in megabytes (MB). If the amount of RAM on your computer was specified by using gigabytes (GB) or some other measure, convert the amount of RAM to MB before choosing and entering a value for the page file size.

    7. In the Maximum Size text box, type a maximum size value that is larger than the initial size. (It is common for the maximum size to be one and a half to two times the initial size.)
    8. Click Set, and then click OK twice.
    9. Click the Advanced tab of the System Properties dialog box, under Startup and Recovery, click Settings.
    10. Under Write debugging information, click the down arrow, and then select Small memory dump (64 KB).
    11. In the Small dump directory box, type X:\Minidump, where X is the drive letter of the NTFS partition on Disk 2.
    12. Click OK twice, and then restart the computer to update the page file size.
  10. Install the Debugging Tools for Windows to C:\Debuggers.
  11. Copy the Microsoft Windows Symbol files to C:\Symbols.
  12. Insert a prepared blank tape cartridge into the SCSI tape drive and verify that the operating system detects that the tape is free.
  13. If appropriate, enable the autologon functionality. For more information about autologon, see [image] How to turn on automatic logon in Windows XP.
  14. Install the DTM Client.
  15. Configure the machine for testing in DTM Studio.
    1. Add the machine to a machine pool.
    2. Deploy the WDK\ConfigureScsiStorageController” dimension.


Preparing for SCSI Controller Testing with Configuration 2

Note Run the tests in configuration 2 only if your device is an embedded SCSI controller.

Before you run the SCSI controller logo program tests for configuration 2, you must assemble the test system, configure the test system, and install the operating system. This topic describes the related procedures for these tasks.

To assemble the test system for SCSI controller configuration 2 testing

    Note All adapters are operated with BIOS enabled and external termination, unless otherwise noted.

  1. Turn off the test system and disconnect it from the electrical socket.
  2. Install the SCSI hard disk drive on the test device. This hard disk drive is referred to as Drive 1.
  3. Install one SCSI CD-ROM drive on the test device.
  4. Install one SCSI tape drive on the test device.
  5. Install one SCSI removable media drive on the test device.

To configure the test system for SCSI controller configuration 2 testing
  1. Turn on the test system and set the system BIOS to boot from the CD-ROM or the alternate boot controller.
  2. Set the system BIOS to support the S3 state.

    Note For Microsoft Windows Server 2003, only support for the S4 sleep state is required.

  3. Install the appropriate Microsoft Windows operating system on Drive 1.
  4. If necessary, install any drivers that a manufacturer supplies that the devices in the test system require.
  5. Insert a prepared blank tape cartridge into the SCSI tape drive and verify that the operating system detects the tape as free.
  6. If appropriate, enable the autologon functionality. For more information about autologon, see [image] How to turn on automatic logon in Windows XP.
  7. Install the DTM Client.
  8. Configure the machine for testing in DTM Studio:
    1. Add the machine to a machine pool.
    2. Deploy the WDK\ConfigureScsiStorageController” dimension.


Running the SCSI Controller Tests

To test SCSI controllers, do the following:

  1. Open Device Console in DTM Studio.
  2. Create a new submission for “Storage > Adapter or Controller > SCSI”.
    • If the device has a driver, select the driver INF when prompted.
    • Make sure to select the SCSI Controller test from the device list.
  3. Select the tests that you want to start, choose Add Selected, and then click Schedule.

Crashdump Support Test

Setup: This test requires that the machine has Operating System Symbols installed in C:\symbols. This test will automatically install the Debugging Tools for Windows as a setup task.

Troubleshooting: If you encounter a test failure at any point before the final Logging phase of the test, ensure that you have the correct symbols.

Note This test will intentionally cause the system to stop responding. A bugcheck during the test is normal if caused by Bugcheck.sys.

Note This test restarts the system.

More Info:

Data Verification Test

Input: This test accepts a single drive letter and a PNP ID as input. These are both provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any file system.

Note This test restarts the system.

Ext Int13h Test

More Info:

NTBackup Test

More Info:

Storage Device Stress

Input: This test accepts a string of drive letters as input. This string is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any file system.

More Info:

Tape IO Test

More Info:

Driver Verifier

More Info:

Device Path Exerciser

More Info:

Sleep Stress with IO

More Info:

Disable Enable with IO

More Info:

Plug and Play Driver Test

More Info:

Prefast for Drivers Test

More Info:

Static Driver Verifier Test

More Info:

Stress Test

More Info:

Stress Test with low resource simulation

More Info:

Sleep Stress Disable Enable with IO

More Info:


Troubleshooting SCSI Controller Testing

For more information about troubleshooting SCSI Controller testing, see Troubleshooting Storage Tests.


SCSI RAID Controller Testing Overview

These procedures test your SCSI RAID controller for proper functionality by using the Microsoft Windows Driver Kit (WDK) and the Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as required for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

The test procedures are divided into the following types of topics:

  • Overview: The overview topics describe the hardware, software, and tester knowledge requirements.
  • Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.
  • Running: The running topics describe how to run the tests for your device or system.

SCSI RAID Controller Tests

The tests that you need to run depend on the capabilities of the device or system that is being tested. The following list contains all of the tests that you might need for your test device:

  • Crashdump Support Test
  • Storage Data Verification Filter Test
  • Int 13h Extensions test
  • Storage Device Stress test (SDStress)
  • Driver Verifier
  • Device Path Exerciser
  • System - Sleep Stress with IO
  • Disable Enable with IO
  • Plug and Play Driver Test
  • Prefast for Drivers
  • Static Driver Verifier
  • Stress Test
  • Core Stress Test

Run time: approximately 2 hours

Note The test descriptions are included in a separate section.

Hardware Requirements

The following hardware is required for SCSI RAID Controller testing. You might need additional hardware if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One computer with the following:
    • Dual-core or equivalent processor (Windows Vista or Windows XP)
    • Quad-core or equivalent processor (Windows Longhorn Server or Windows Server 2003)

      Note A system that contains two microprocessors that support hyper-threading can be used if hyper-threading is enabled.

    • 2 GB memory (Windows Vista or Windows XP)
    • 6 GB memory (Windows Longhorn Server or Windows Server 2003)
    • Logo-compliant ACPI BIOS, with ACPI enabled by default
    • A PCI-based bus

    Note For Windows Vista and Windows XP Professional, the test system must support S3 and S4 states.

    For Windows XP Professional on mobile systems, the test system must support the S4 state and the S1 or S3 state.

    For Windows Server 2003, Enterprise Edition, the test system is required only to support the S4 state.

  • If the RAID Controller is not bootable, one ATA or SCSI Controller is required to boot the operating system.
  • If the RAID Controller is not bootable, one ATA or SCSI hard disk drive is required to boot the operating system.
  • One SCSI or ATA CD-ROM drive.
  • Two identical PCI-based RAID controllers that support the SCSI or Fibre Channel protocols only (the test devices).
  • Two Fibre Channel or SCSI JBODs are required, depending on the protocol that is supported on the RAID controller. You can replace one of the JBODs with three hard disk drives. The disk drives must use the same protocol as the RAID controller.

    Note Only one Fibre Channel or SCSI JBOD is required if the test device is integrated.

  • One PCI-to-PCI bridge adapter.

    Note A PCI-to-PCI bridge adapter is not required if any of the following apply:

    • The RAID controllers cannot fit into PCI bridge adapters (such as integrated controllers or controllers that can only fit into specially design slots).
    • The RAID controller is designed and sold only for systems that cannot accept full height PCI-to-PCI Bridge adapters (such as blade servers).
    • One of the RAID Controllers can be placed into a PCI bus slot that is already behind a PCI Bridge.

  • One monitor, one keyboard, and one mouse (or any pointing/drawing device).

Note Any USB-floppy drivers or LS-120 drives should be removed from the system and replaced with standard ATA floppy drives, if possible.

Important The test system must have received the "Designed for Windows" logo. All hardware (except for the device under test, monitor, keyboard, mouse and the floppy disk drive) must be included in the Windows Catalog.

Software Requirements

The following software is required to run the SCSI RAID Controller tests:

  • Microsoft Windows Vista
  • Microsoft Windows XP Professional with Service Pack 2 (SP2)
  • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
  • Microsoft Windows Server 2003, Datacenter Edition, with SP1
  • Microsoft Windows XP Professional x64 Edition
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows Server 2003, Datacenter x64 Edition
  • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
  • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems
  • Any drivers that are not shipped with the operating system
  • The current release of the Microsoft Windows Driver Kit (WDK)

Tester Knowledge Requirements

To run the SCSI RAID Controller tests, testers must know how to accomplish the following tasks:

  • Access and change the system BIOS settings.
  • Install SCSI and ATA hard disk drives.
  • Install a RAID controller.
  • Configure a RAID array.
  • Install a PCI-to-PCI bridge.
  • Install and configure Microsoft Debugging Tools for Windows.
  • Install Microsoft Windows Symbols files.
  • Install the appropriate operating system.
  • Download and install an operating system service pack.
  • Read and interpret test logs.
  • Report bugs in a standard bug format.

After you have reviewed the necessary requirements, you can prepare to test your SCSI RAID controller device.

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Preparing to Test SCSI RAID Controllers

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see SCSI RAID Controller Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, For more information about autologon, see [image] How to turn on automatic logon in Windows XP.

Test system configuration

There are two different procedures for configuring an SCSI RAID controller for basic functionality testing. Use the default configuration in most situations. However, if one of the following exceptions applies, use the secondary configuration:

  • The RAID controller test device is an integrated controller.

    Note The secondary procedure cannot be used for integrated controllers if a system that meets hardware requirements with two of these integrated controllers is available, or if there is a duplicate PCI adapter version of this RAID controller available.

  • The RAID controller is designed for and sold only in a host test system that will accept only a single version of the controller.

The following items apply to the default and secondary configurations:

  • All RAID arrays should be 40 GB in size.
  • Three RAID arrays will be created.
  • One RAID array will be created on the first JBOD by using the first RAID controller.
  • Two RAID arrays will be created on the second JBOD by using the second identical RAID controller.

All RAID controllers and JBODs are required to support only one RAID level (RAID 5, RAID 1, or RAID 0). If more than one RAID level is supported on the controller, the RAID levels must be configured for testing, as following:

  • If the device supports RAID 5, 1, and 0, do one of the following:
    • Configure the first JBOD for testing with a RAID 5 array and then configure the second JBOD for testing with a RAID 1 and a RAID 0 array.
    • Configure the first JBOD for testing with a RAID 1 array and configure the second JBOD for testing with a RAID 5 and a RAID 0 array.
  • If the device supports only RAID 5 and RAID 1, do one of the following:
    • Configure the first JBOD for testing with one RAID 5 array and configure the second JBOD for testing with two RAID 1 arrays.
    • Configure the first JBOD for testing with one RAID 1 array and configure the second JBOD for testing with two RAID 5 arrays.
  • If the device supports only RAID 5 and RAID 0, configure the first JBOD for testing with one RAID 5 array and then configure the second JBOD for testing with one RAID 5 array and one RAID 0 array.
  • If the device supports only RAID 1 and RAID 0, configure the first JBOD for testing with one RAID 1 array and then configure the second JBOD for testing with one RAID 1 array and one RAID 0 array.
  • If the device supports only RAID 5, configure the first JBOD for testing with one RAID 5 array and then configure the second JBOD for testing with two RAID 5 arrays.
  • If the device supports only RAID 1, configure the first JBOD for testing with one RAID 1 array and then configure the second JBOD for testing with two RAID 1 arrays.
  • If the device supports only RAID 0, configure the first JBOD for testing with one RAID 0 array and then configure the second JBOD for testing with two RAID 0 arrays.

For more information about configuring an SCSI RAID controller for basic functionality testing, see the following topics:

Preparing for SCSI RAID Controller Testing with the Default Configuration

Preparing for SCSI RAID Controller Testing with the Secondary Configuration


Preparing for SCSI RAID Controller Testing with the Default Configuration

Use the following procedures to configure the test system and test a SCSI RAID controller, unless one or both of the following conditions applies:

  • The RAID controller test device is an integrated controller.

    Note The secondary procedure cannot be used for integrated controllers if a system that meets hardware requirements with two of these integrated controllers is available, or if there is a duplicate PCI adapter version of this RAID controller available.

  • The RAID controller is designed for and sold only in a host test system that will accept only a single version of the controller.

If one or both of the preceding conditions applies, use the secondary configuration for SCSI RAID controller testing.

Before you run the SCSI RAID controller logo tests for the default configuration, you must configure the test system, install the operating system, and then install the DTM Client according to the following procedures.

To configure the test system in the default configuration
  1. Turn off the test system.
  2. Install one RAID controller (test device 1).
  3. Connect and install one JBOD or three hard disk drives to the first RAID controller.
  4. If the RAID Controller supports a CD-ROM, connect a CD-ROM drive to the secondary RAID controller.
  5. Install a PCI-to-PCI bridge in a PCI slot on the host test system. A PCI-to-PCI bridge adapter is not required if any of the following apply:
    • The RAID controllers cannot fit into PCI bridge adapters (such as integrated controllers or controllers that can fit only into specially design slots).
    • The RAID controller is designed and sold only for systems that cannot accept full height PCI-to-PCI Bridge adapters (such as blade servers).
    • One of the RAID Controllers can be placed into a PCI bus slot that is already behind a PCI Bridge.
  6. Install a secondary, duplicate RAID controller (test device 2) into the PCI-to-PCI bridge card.

    Note Install the secondary RAID controller directly into a PCI slot if the RAID controller cannot be installed into a PCI-to-PCI bridge because of its design (such as controllers that fit into specially designed slots or blade servers). Also, install the secondary RAID controller directly into a PCI slot if the RAID controller is designed for and sold only in systems that cannot accept full-height PCI-to-PCI Bridge adapters (such as blade servers).

  7. If possible, set the first and second RAID controllers to use the same IRQ.
  8. Connect the JBOD to the secondary RAID controller.
  9. Use the hardware RAID configuration utility for the test device, or the BIOS, and create one 40-GB RAID array and two 40-GB RAID arrays on the second JBOD. Use the RAID-level criteria in SCSI RAID Controller Testing Overview to determine the RAID levels on the JBODs for RAID controller testing.

To install the Windows Vista or Windows XP Professional or Windows Server 2003 operating system in the default configuration
  1. Do one of the following to install the appropriate operating system:
    • If the test RAID controller is bootable and the test RAID controller supports a CD-ROM drive, insert the operating system CD into the CD-ROM drive that is connected to the test RAID controller. Install the Windows operating system onto a NTFS 14-GB partition in the RAID array on the first JBOD.
    • If the test RAID controller does not support CD-ROM drives, insert the operating system CD into the CD-ROM drive that is connected to any alternate controller. Install the Windows operating system onto a NTFS 14-GB partition in the RAID array on the first JBOD.
    • If the test RAID controller is not bootable, install the operating system onto a NTFS 14-GB partition on a hard disk drive that is connected to the alternate non-test boot controller in the host test system.
  2. Install any software or drivers that are necessary to connect to and manage the peripheral devices.

    Note All drivers, except the drivers for the test device, must be signed and must be listed in Windows Catalog.

  3. Click Start, right-click My Computer, and then click Properties.
  4. On Windows Vista or Windows Longhorn Server, click Advanced System Settings. If you are prompted to enter Administrative credentials or allow the action, enter the credentials or allow the action.
  5. Click the General tab, and then note the amount of RAM that the computer has.
  6. Click the Advanced tab, and then under Performance, click Settings. The Performance Options dialog box appears.
  7. Click the Advanced tab, and then under Virtual Memory, click Change. The Virtual Memory dialog box appears.
  8. Click Custom Size, and then type a number that is larger than the size of RAM in the Initial Size text box.

    Note You specify the size of the page file in megabytes (MB). If the amount of RAM on your computer was specified by using gigabytes (GB) or some other measure, convert the amount of RAM to MB before choosing and entering a value for the page file size.

  9. In the Maximum Size text box, type a maximum size value that is larger than the initial size. (It is common for the maximum size to be one and a half to two times the initial size.)
  10. Click Set, and then click OK twice.
  11. In the Advanced tab of the System Properties dialog box, under Startup and Recovery, click Settings.
  12. Under Write debugging information, click the down arrow, and then select Small memory dump (64 KB).
  13. In the Small dump directory box, type X:\Minidump, where X is the drive letter of one of the RAID partitions.
  14. Click OK twice, and then restart the computer to update the page file size.
  15. Install the Debugging Tools for Windows to the C:\Debuggers directory.
  16. Copy the Microsoft Windows Symbols files to the C:\Symbols directory.
  17. Use Windows Disk Management to make all of the hard disk drives dynamic.

    Important If the test device is not bootable at this point, you are booting from an alternate boot controller. Do not add any partitions to the hard disks on the alternate boot controller.

  18. Use the Windows Disk Management utility to set up three 4 GB partitions on the second RAID array on the second JBOD, and do one of the following:
    • If you are testing with a 32-bit edition of the Windows operating system, format two of the partitions with the NTFS file system, and format the third partition with the FAT32 file system.
    • If you are testing with a 64-bit edition of Windows, format all three partitions with NTFS.
  19. If you are testing with Windows Server 2003, Enterprise Edition, use Windows Disk Management to create a software RAID 1 mirror of one of the NTFS partitions on the second JBOD to the unallocated space on the RAID array on the first JBOD.
  20. If you are testing with Windows Server 2003, Enterprise Edition, use Windows Disk Management to create a 4-GB NTFS software RAID 5 array that uses unallocated space on each of the three RAID arrays.
  21. If you are testing with Windows XP Professional, use Windows Disk Management to create a spanned 4-GB NTFS volume that uses unallocated space on each of the three RAID arrays.
  22. Install DTM Client.
  23. Configure the machine for testing in DTM Studio.
    1. Add the machine to a machine pool.
    2. Deploy the WDK\ConfigureScsiRaidStorageController” dimension.


Preparing for SCSI RAID Controller Testing with the Secondary Configuration

Use the following procedures to configure the test system and test a SCSI RAID controller if one or both of the following conditions applies:

  • The RAID controller test device is an integrated controller.

    Note Use the default procedure for integrated controllers if a system that meets hardware requirements with two of these integrated controllers is available, or if there is a duplicate PCI adapter version of this RAID controller available.

  • The RAID controller is designed for and sold only in a host test system that will accept only a single version of the controller.

Before you run the SCSI RAID controller logo tests with the secondary configuration, you must configure RAID levels, install the operating system, and then install the DTM Client according to the following procedures.

To configure RAID levels

Three RAID arrays will be created.

All RAID controllers and JBODs are required to support only one RAID level (RAID 5, RAID 1, or RAID 0). If more than one RAID level is supported on the controller, the RAID levels must be configured for testing, as follows:

  • If the device supports RAID 5, 1, and 0, configure the JBOD for testing with one RAID 5 array, one RAID 1 array, and one RAID 0 array.
  • If the device supports only RAID 5 and RAID 1, configure the JBOD for testing with two RAID 5 arrays and one RAID 1 array.
  • If the device supports only RAID 5 and RAID 0, configure the JBOD for testing with two RAID 5 arrays and one RAID 0 array.
  • If the device supports only RAID 1 and RAID 0, configure the JBOD for testing with two RAID 1 arrays and one RAID 0 array.
  • If the device supports only RAID 5, configure the JBOD for testing with three RAID 5 arrays.
  • If the device supports only RAID 1 arrays, configure the JBOD for testing with three RAID 1 arrays.
  • If the device supports only RAID 0 arrays, configure the JBOD for testing with three RAID 0 arrays.
To install the operating system in the secondary configuration
  1. Do one of the following:
    • If the test RAID controller is bootable and the test RAID controller supports CD-ROM drives, insert the operating system CD into the CD-ROM drive that is connected to the test RAID controller. Install the Windows operating system onto a NTFS 14-GB partition in the first RAID array on the JBOD.
    • If the test RAID controller does not support CD-ROM drives, insert the operating system CD into the CD-ROM drive that is connected to any alternate controller. Install the Windows operating system onto a NTFS 14-GB partition in the first RAID array on the JBOD.
    • If the test RAID controller is not bootable, install the operating system onto a NTFS 14-GB partition onto a hard disk drive connected to any alternate non test boot controller in the host test system.
  2. Install any software or drivers that are necessary to connect to and manage the peripheral devices.

    Note All drivers that are not associated with the test device must be signed, and the devices must be listed in the Windows Catalog.

  3. Click Start, right-click My Computer, and then click Properties.
  4. Click the General tab, and note the amount of RAM that the computer has.
  5. Click the Advanced tab, and then under Performance, click Settings. The Performance Options dialog box appears.
  6. Click the Advanced tab, and then under Virtual Memory, click Change. The Virtual Memory dialog box appears.
  7. Click Custom Size, and then type a number that is larger than the size of RAM in the Initial Size text box.

    Note You specify the size of the page file in megabytes (MB). If the amount of RAM on your computer was specified by using gigabytes (GB) or some other measure, convert the amount of RAM to MB before choosing and entering a value for the page file size.

  8. In the Maximum Size text box, type a maximum size value that is larger than the initial size. (It is common for the maximum size to be one and a half to two times the initial size.)
  9. Click Set, and then click OK twice.
  10. In the Advanced tab of the System Properties dialog box, under Startup and Recovery, click Settings.
  11. Under Write debugging information, click the down arrow, and then click Small memory dump (64 KB).
  12. In the Small dump directory box, type X:\Minidump, where X is the drive letter of one of the RAID partitions.
  13. Click OK twice, and then restart the computer to update the page file size.
  14. Install the Debugging Tools for Windows to the C:\Debuggers directory.
  15. Copy the Microsoft Windows Symbols files to the C:\Symbols directory.
  16. Use the Windows Disk Management utility to set up three 4-GB partitions on the second RAID array that was previously created on the JBOD, and then do one of the following:
    1. If you are testing with a 32-bit edition of the Windows operating system, format two of the partitions with the NTFS file system, and format the third partition with FAT32.
    2. If you are testing with a 64-bit edition of Windows, format all three partitions with NTFS.
  17. If you are testing with Windows Server 2003, Enterprise Edition, use Windows Disk Management to create a software RAID 1 mirror of one of the NTFS partitions on the second RAID array on the JBOD to the unallocated space on the first RAID array on the JBOD.
  18. If you are testing with Windows Server 2003, Enterprise Edition, use Windows Disk Management to create a 4-GB NTFS software RAID 5 array that uses unallocated space on RAID Array 1 and RAID Array 2.
  19. If you are testing with Windows XP Professional, use Windows Disk Management to create a spanned 4-GB NTFS volume that uses unallocated space on each of the three RAID arrays.
  20. Install DTM Client.
  21. Configure the machine for testing in DTM Studio:
    1. Add the machine to a machine pool.
    2. Deploy the WDK\ConfigureScsiRaidStorageController” dimension.


Running the SCSI RAID Controller Tests

To test SCSI RAID Controllers, do the following:

  1. Open Device Console in DTM Studio.
  2. Create a new submission for “Storage > Adapter or Controller > SCSI-RAID”.
    • If the device has a driver, select the driver INF when prompted.
    • Make sure to select the SCSI RAID Controller test from the device list.
  3. Select the tests that you want to start, choose Add Selected, and then click Schedule.

Crashdump Support Test

Setup: This test requires that the machine has Operating System Symbols installed in C:\symbols. This test will automatically install the Debugging Tools for Windows as a setup task.

Troubleshooting: If you encounter a test failure at any point before the final Logging phase of the test, ensure that you have the correct symbols.

Note This test will intentionally cause the system to stop responding. A bugcheck during the test is normal if caused by Bugcheck.sys.

Note This test restarts the system.

More Info:

Data Verification Test

Input: This test accepts a single drive letter and a PNP ID as input. These are both provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any file system.

Note This test restarts the system.

Ext Int13h Test

More Info:

Storage Device Stress

Input: This test accepts a string of drive letters as input. This string is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any file system.

More Info:

Driver Verifier

More Info:

Device Path Exerciser

More Info:

Sleep Stress with IO

More Info:

Disable Enable with IO

More Info:

Plug and Play Driver Test

More Info:

Prefast for Drivers Test

More Info:

Static Driver Verifier Test

More Info:

Stress Test

More Info:

Stress Test with low resource simulation

More Info:

Sleep Stress Disable Enable with IO

More Info:


Troubleshooting SCSI RAID Controller Testing

For more information about troubleshooting SCSI RAID Controller testing, see Troubleshooting Storage Tests.


Serial ATA Controller Testing Overview

These procedures test your Serial ATA controller for proper functionality by using the Microsoft Windows Driver Kit (WDK) and the Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as required for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

The test procedures are divided into the following types of topics:

  • Overview: The overview topics describe the hardware, software, and tester knowledge requirements.
  • Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.
  • Running: The running topics describe how to run the tests for your device or system.

Serial ATA Controller Tests

The tests that you need to run depend on the capabilities of the device or system that is being tested. The following list contains all of the tests that you might need for your test device:

  • Crashdump Support Test
  • Storage Data Verification Filter Test
  • Int 13h Extensions test
  • SATA IO Sig Test
  • Storage Device Stress test (SDStress)
  • Driver Verifier
  • Device Path Exerciser
  • System - Sleep Stress with IO
  • Disable Enable with IO
  • Plug and Play Driver Test
  • Prefast for Drivers
  • Static Driver Verifier
  • Stress Test
  • Core Stress Test

Run time: approximately 2 hours

Note The test descriptions are included in a separate section.

Hardware Requirements

The following hardware is required for Serial ATA Controller testing. You might need additional hardware if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One computer with the following:
    • Dual-core or equivalent processor (Windows Vista or Windows XP)
    • Quad-core or equivalent processor (Windows Longhorn Server or Windows Server 2003)
    • 2 GB memory (Windows Vista or Windows XP)
    • 6 GB memory (Windows Longhorn Server or Windows Server 2003)
    • Logo-compliant ACPI BIOS, with ACPI enabled by default

  • Serial ATA controller (the test device).
  • One Serial ATA hard disk drive with a capacity of at least 10 GB.
  • One blank floppy disk.
  • One standard serial ATA cable.
  • One monitor, one keyboard, and one mouse (or any pointing or drawing device).

Software Requirements

The following software is required to run the Serial ATA Controller tests:

  • Microsoft Windows Vista
  • Microsoft Windows XP Professional with Service Pack 2 (SP2)
  • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
  • Microsoft Windows Server 2003, Datacenter Edition, with SP1
  • Microsoft Windows XP Professional x64 Edition
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows Server 2003, Datacenter x64 Edition
  • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
  • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems
  • Any drivers that are not shipped with the operating system
  • The current release of the Microsoft Windows Driver Kit (WDK)

Tester Knowledge Requirements

To run the Serial ATA Controller tests, testers must know how to accomplish the following tasks:

  • Install a boot-capable controller.
  • Install a hard disk drive as a boot drive.
  • Format and partition a hard disk drive.
  • Install a CD-ROM drive as Device 1.
  • Access and change the system BIOS settings.
  • Install and use Microsoft Debugging Tools for Windows.
  • Install and use Microsoft Windows Symbols files.
  • Install the operating system from the product CD.

After you have reviewed the necessary requirements, you can prepare to test your Serial ATA Controller device.

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Preparing to Test Serial ATA Controllers

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see Serial ATA Controller Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, For more information about autologon, see [image] How to turn on automatic logon in Windows XP.

Test system configuration

There are two different procedures for configuring your Serial ATA controller for testing:

Preparing for Serial ATA Controller Testing with Configuration 1

Preparing for Serial ATA Controller Testing with Configuration 2


Preparing for Serial ATA Controller Testing with Configuration 1

Before running the tests in configuration 1, you must assemble and configure the test system.

To assemble the test system for Serial ATA controller configuration 1 testing
  1. Install one Serial ATA controller (the test device) as the boot device.
  2. Install one ATA/ATAPI controller.
  3. Attach one CD-ROM drive (CD-ROM Drive 1) to the ATA/ATAPI controller.
  4. Attach one Serial ATA hard disk drive to the serial ATA controller as Drive 1.

To configure the test system for Serial ATA controller configuration 1 testing
  1. Turn on the test system, and set the system BIOS to boot from Drive 1.
  2. Set the system BIOS to support the S3 state.
  3. Insert the appropriate Microsoft Windows operating system CD into CD-ROM Drive 1, and restart the test system.
  4. Install the Microsoft Windows operating system on Drive 1. During installation, delete any existing partitions and create one partition that uses at least 2 GB of disk space. Format the partition with the NTFS file system. Leave at least 2 GB of free space on this drive.
  5. If necessary, install any drivers that a manufacturer supplies that the devices in the test system require.
  6. Do the following to make the system page file larger than the size of RAM:
    1. Click Start, right-click My Computer, and click Properties.
    2. If the test operating system is Windows Vista or Windows Longhorn Server, click Advanced System Settings. If you are prompted to enter Administrative credentials or allow the action, enter the credentials or allow the action.
    3. In the General tab, note the amount of RAM that the computer has.
    4. Click the Advanced tab, and then under Performance, click Settings. The Performance Options dialog box appears.
    5. Click the Advanced tab, and under Virtual Memory, click Change. The Virtual Memory dialog box appears.
    6. Click Custom Size, and then type a number that is larger than the size of RAM in the Initial Size text box.

      Note You specify the size of the page file in megabytes (MB). If the amount of RAM on your computer was specified by using gigabytes (GB) or some other measure, convert the amount of RAM to MB before choosing and entering a value for the page file size.

    7. In the Maximum Size text box, type a maximum size value that is larger than the initial size. (It is common for the maximum size to be one and a half to two times the initial size.)
    8. Click Set, and then click OK twice.
    9. Click the Advanced tab of the System Properties dialog box, under Startup and Recovery, click Settings.
    10. Under Write debugging information, click the down arrow, and then select Small memory dump (64 KB).
    11. In the Small dump directory box, type X:\Minidump, where X is the drive letter of the NTFS partition on Disk 2.
    12. Click OK twice, and then restart the computer to update the page file size.
  7. If appropriate, enable the autologon functionality. For more information about autologon, see [image] How to turn on automatic logon in Windows XP.
  8. Install the DTM Client.
  9. Configure the machine for testing in DTM Studio:
    1. Add the machine to a machine pool.
    2. Deploy the WDK\ConfigureSerialAtaStorageController” dimension.


Preparing for Serial ATA Controller Testing with Configuration 2

Before running the tests in configuration 2, you must assemble and configure the test system.

To assemble the test system for Serial ATA controller configuration 2 testing
  1. Install one boot-capable controller (not the test device) that has signed drivers or in-box support.
  2. Install one Serial ATA controller (the test device).
  3. Attach one hard disk drive (Drive 1) to the controller that is installed in step 1.
  4. Attach one CD-ROM drive (CD-ROM Drive 1) to the controller that is installed in step 1.
  5. Attach one serial ATA hard disk drive to the serial ATA controller as Drive 2.

To configure the test system for Serial ATA controller configuration 2 testing
  1. Turn on the test system, and set the system BIOS to boot from the CD-ROM drive.
  2. Set the system BIOS to support the S3 state.
  3. Insert the appropriate Microsoft Windows operating system CD into CD-ROM Drive 1, and restart the test system.
  4. Install the Microsoft Windows operating system on Drive 1. During installation, delete any existing partitions and create one partition that uses at least 2 GB of disk space. Format the partition with the NTFS file system. Leave at least 2 GB of free space on this drive.
  5. If necessary, install any drivers that a manufacturer supplies that the devices in the test system require.
  6. On Drive 2, delete any existing partitions and create one partition that uses a minimum of 2 GB of disk space. Format the partition with the NTFS file system.
  7. If appropriate, enable the autologon functionality. For more information about autologon, see [image] How to turn on automatic logon in Windows XP.
  8. Install the DTM Client.
  9. Configure the machine for testing in DTM Studio:
    1. Add the machine to a machine pool.
    2. Deploy the WDK\ConfigureSerialAtaStorageController” dimension.


Running the Serial ATA Controller Tests

To test Serial ATA controllers, do the following:

  1. Open Device Console in DTM Studio.
  2. Create a new submission for “Storage > Adapter or Controller > Serial ATA”.
    • If the device has a driver, select the driver INF when prompted.
    • Make sure to select the SATA Controller test from the device list.
  3. Select the tests that you want to start, choose Add Selected, and then click Schedule.

Crashdump Support Test

Setup: This test requires that the machine has Operating System Symbols installed in C:\symbols. This test will automatically install the Debugging Tools for Windows as a setup task.

Troubleshooting: If you encounter a test failure at any point before the final Logging phase of the test, ensure that you have the correct symbols.

Note This test will intentionally cause the system to stop responding. A bugcheck during the test is normal if caused by Bugcheck.sys.

Note This test restarts the system.

More Info:

Data Verification Test

Input: This test accepts a single drive letter and a PNP ID as input. These are both provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any file system.

Note This test restarts the system.

Ext Int13h Test

More Info:

SATA IO Sig Test

More Info:

Storage Device Stress

Input: This test accepts a string of drive letters as input. This string is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any file system.

More Info:

Driver Verifier

More Info:

Device Path Exerciser

More Info:

Sleep Stress with IO

More Info:

Disable Enable with IO

More Info:

Plug and Play Driver Test

More Info:

Prefast for Drivers Test

More Info:

Static Driver Verifier Test

More Info:

Stress Test

More Info:

Stress Test with low resource simulation

More Info:

Sleep Stress Disable Enable with IO

More Info:


Troubleshooting Serial ATA Controller Testing

For more information about troubleshooting Serial ATA Controller testing, see Troubleshooting Storage Tests.


Serial ATA RAID Controller Testing Overview

These procedures test your Serial ATA RAID controller for proper functionality by using the Microsoft Windows Driver Kit (WDK) and the Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as required for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

The test procedures are divided into the following types of topics:

  • Overview: The overview topics describe the hardware, software, and tester knowledge requirements.
  • Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.
  • Running: The running topics describe how to run the tests for your device or system.

Serial ATA RAID Controller Tests

The tests that you need to run depend on the capabilities of the device or system that is being tested. The following list contains all of the tests that you might need for your test device:

  • Crashdump Support Test
  • Storage Data Verification Filter Test
  • Int 13h Extensions test
  • SATA IO Sig Test
  • Storage Device Stress test (SDStress)
  • Driver Verifier
  • Device Path Exerciser
  • System - Sleep Stress with IO
  • Disable Enable with IO
  • Plug and Play Driver Test
  • Prefast for Drivers
  • Static Driver Verifier
  • Stress Test
  • Core Stress Test

Run time: approximately 2 hours

Note The test descriptions are included in a separate section.

Hardware Requirements

The following hardware is required for Serial ATA RAID Controller testing. You might need additional hardware if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One computer with the following:
    • Dual-core or equivalent processor (Windows Vista or Windows XP)
    • Quad-core or equivalent processor (Windows Longhorn Server or Windows Server 2003)

      Note A system that contains two microprocessors that support hyper-threading can be used if hyper-threading is enabled.

    • 2 GB memory (Windows Vista or Windows XP)
    • 6 GB memory (Windows Longhorn Server or Windows Server 2003)

      Important The operating system must report that a minimum of 5500 MB of RAM is free and available. If you are testing the SAS RAID controller on Windows XP Professional, or if the SAS RAID controller will be sold only in systems that do not support four processors or 6 GB of RAM, the test system must have at least one microprocessor and 256 MB of RAM.

    • A PCI-based bus
    • Logo-compliant ACPI BIOS, with ACPI enabled by default

  • One SCSI or ATA CD-ROM drive.
  • If the Serial ATA RAID controller is not bootable, one ATA or SCSI controller is required to boot the operating system.
  • Two hard disk drives for each channel that the test device supports. Each disk must be a minimum size of 40 GB.
  • One PCI-to-PCI bridge adapter.

    Note A PCI-to-PCI bridge adapter is not required if any of the following apply:

    • The RAID controllers cannot fit into PCI bridge adapters (such as integrated controllers or controllers that can fit only into specially design slots).
    • The RAID controller is designed and sold only for systems that cannot accept full height PCI-to-PCI bridge adapters (such as blade servers).
    • One of the RAID controllers can be placed into a PCI bus slot that is already behind a PCI bridge.

  • One monitor, one keyboard, and one mouse (or any pointing/drawing device).

Note Any USB-floppy disk drives or LS-120 drives should be removed from the system and replaced with standard ATA floppy drives if possible.

Important The test system must have received the "Designed for Windows" logo. All hardware (except for the device under test, monitor, keyboard, mouse and the floppy disk drive) must be included in the Windows Catalog.

Software Requirements

The following software is required to run the Serial ATA RAID Controller tests:

  • Microsoft Windows Vista
  • Microsoft Windows XP Professional with Service Pack 2 (SP2)
  • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
  • Microsoft Windows Server 2003, Datacenter Edition, with SP1
  • Microsoft Windows XP Professional x64 Edition
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows Server 2003, Datacenter x64 Edition
  • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
  • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems
  • Any drivers that are not shipped with the operating system
  • The current release of the Microsoft Windows Driver Kit (WDK)

Tester Knowledge Requirements

To run the Serial ATA RAID Controller tests, testers must know how to accomplish the following tasks:

  • Access and change the system BIOS settings.
  • Install a hard disk drive.
  • Format and partition hard disk drives.
  • Install a Serial ATA RAID controller.
  • Configure a RAID array.
  • Install a PCI-to-PCI bridge.
  • Create and format logical drives.
  • Install and configure Microsoft Debugging Tools for Windows.
  • Install Microsoft Windows Symbols files.
  • Install the operating system from the product CD.
  • Read and interpret test logs.
  • Report bugs in a standard bug format.
  • Submit a Serial ATA RAID controller by using the online submissions site.

After you have reviewed the necessary requirements, you can prepare to test your Serial ATA RAID controller device.

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Preparing to Test Serial ATA RAID Controllers

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see Serial ATA RAID Controller Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, For more information about autologon, see [image] How to turn on automatic logon in Windows XP.

Test system configuration

There are two different procedures for configuring a Serial ATA RAID controller for basic functionality testing. Use the default configuration in most situations. However, if one of the following exceptions applies, use the secondary configuration:

  • The Serial ATA RAID controller test device is an integrated controller.

    Note Use the default (not the secondary) procedure for integrated controllers if a system that meets hardware requirements with two of these integrated controllers is available or if a duplicate PCI adapter version of this Serial ATA RAID controller is available.

  • The Serial ATA RAID controller is designed for and sold only in a host test system that accepts only a single version of the controller.

For more information about configuring an Serial ATA RAID controller for basic functionality testing, see the following topics:

Preparing for Serial ATA RAID Controller Testing with the Default Configuration

Preparing for Serial ATA RAID Controller Testing with the Secondary Configuration


Preparing for Serial ATA RAID Controller Testing with the Default Configuration

Use the following procedure to configure the test system and test a Serial ATA RAID controller, unless one or both of the following conditions applies:

  • The Serial ATA RAID controller test device is an integrated controller.

    Note You must use the default procedure for integrated controllers if a system that meets the hardware requirements with two of these integrated controllers is available, or if a duplicate PCI adapter version of this Serial ATA RAID controller is available.

  • The Serial ATA RAID controller is designed for and sold only in a host test system that will accept only a single version of the controller.

If one of the preceding conditions applies, use the secondary configuration for Serial ATA RAID Controller testing.

Before you run the Serial ATA RAID controller logo tests, you must configure the test system, determine the appropriate RAID levels for devices, install the operating system, and then install the DTM Client according to the following procedures.

To configure the test system with the default configuration

    Note All adapters should be operated with BIOS enabled, unless otherwise noted.

  1. Turn off the test system.
  2. Install one add-in controller adapter (not the test device) that has signed drivers or in-box support. If the test device is not bootable, the add-in controller must be boot-capable.
  3. Attach a CD-ROM drive to the add-in controller.
  4. If the test device is not bootable, install a hard disk drive on the add-in controller.
  5. Install one Serial ATA RAID controller (controller 1).
  6. Install one hard disk drive on each channel that the Serial ATA RAID controller supports. For example, if the test device supports four channels, it should have four hard disk drives connected to it.
  7. Install a PCI-to-PCI bridge in a PCI slot on the host test system, unless any of the following conditions apply:
    • The Serial ATA RAID controllers cannot fit into PCI bridge adapters (such as integrated controllers or controllers that can fit only into specially design slots).
    • The Serial ATA RAID controller is designed and sold only for systems that cannot accept full height PCI-to-PCI Bridge adapters (such as blade servers).
    • One of the Serial ATA RAID controllers can be placed into a PCI bus slot that is already behind a PCI bridge.
  8. Install a secondary, duplicate Serial ATA RAID controller (controller 2) into the PCI-to-PCI bridge card.

    Note Install the secondary Serial ATA RAID controller directly into a PCI slot if a PCI bridge card is not required.

  9. Install one hard disk drive on each channel that controller 2 supports. For example, if controller 2 supports four channels, it should have four hard disk drives connected to it.

To determine the appropriate RAID levels for the devices
  1. Create one 40-GB RAID array on controller 1 and two 40-GB RAID arrays on controller 2. The RAID array on controller 1 is referred to as RAID array 1, and the RAID arrays on controller 2 are referred to as RAID array 2 and RAID array 3.

    Note All RAID controllers are required to support only one RAID level.

  2. Configure the RAID arrays according to the following table.
    If the test device supports these RAID levels | RAID level for RAID Array 1 | RAID level for RAID Array 2 | RAID level for RAID Array 3
    0 only | 0 | 0 | 0
    1 only | 1 | 1 | 1
    5 only | 5 | 5 | 5
    0 and 1 only | 1 | 0 | 0
    0 and 5 only | 5 | 0 | 0
    1 and 5 only | 5 | 1 | 1
    0, 1, and 5 | 5 | 1 | 0

    3. Note If the test device does not support enough drives to create the required number of arrays, you can replace RAID array 3 with a hard disk drive that is attached to the add-in controller. If a hard disk drive is already attached to the add-in controller as a boot disk, you must add a second hard disk drive to the add-in controller and create the partitions on the hard disk drive that is not being used to boot.

To install the operating system with the default configuration

    Use the following procedure to install the operating system. When you are finished, the RAID array will be configured as shown in Figure 1 for Microsoft Windows Vista or Windows XP and as shown in Figure 2 for Windows Server 2003, Enterprise Edition.

    Figure 1: RAID array default configuration for Windows Vista or Windows XP

    Figure 2: RAID array default configuration for Windows Server 2003, Enterprise Edition

  1. Do one of the following to install the appropriate operating system:
    • If controller 1 is bootable, insert the operating system CD-ROM into the CD-ROM drive that is connected to the add-in controller, and then install the Windows operating system onto a NTFS-formatted, 14-GB partition on RAID Array 1.
    • If controller 1 is not bootable, insert the operating system CD-ROM into the CD-ROM drive that is connected to the add-in controller, and then install the Windows operating system onto a NTFS-formatted, 14-GB partition on the hard disk drive that is attached to the add-in controller.
  2. Install any software or drivers that are necessary to connect to and manage the peripheral devices.

    Note All drivers, except the drivers for the test device, must be signed and must be listed in Windows Catalog.

  3. Click Start, right-click My Computer, and then click Properties.
  4. Click the General tab, and then note the amount of RAM that the computer has.
  5. Click the Advanced tab, and then under Performance, click Settings. The Performance Options dialog box appears.
  6. Click the Advanced tab, and then under Virtual Memory, click Change. The Virtual Memory dialog box appears.
  7. Click Custom Size, and then type a number that is larger than the size of RAM in the Initial Size text box.

    Note You specify the size of the page file in megabytes (MB). If the amount of RAM on your computer was specified by using gigabytes (GB) or some other measure, convert the amount of RAM to MB before choosing and entering a value for the page file size.

  8. In the Maximum Size text box, type a maximum size value that is larger than the initial size. (It is common for the maximum size to be one and a half to two times the initial size.)
  9. Click Set, and then click OK twice.
  10. In the Advanced tab of the System Properties dialog box, under Startup and Recovery, click Settings.
  11. Under Write debugging information, click the down arrow, and then select Small memory dump (64 KB).
  12. In the Small dump directory box, type X:\Minidump, where X is the drive letter of one of the RAID partitions.
  13. Click OK twice, and then restart the computer to update the page file size.
  14. Install the Debugging Tools for Windows to the C:\Debuggers directory.
  15. Copy the Microsoft Windows Symbols files to the C:\Symbols directory.
  16. Use the Windows Disk Management utility to set up three 4-GB partitions on RAID Array 2, and do one of the following:
    • If you are testing with a 32-bit edition of the Windows operating system, format two of the partitions with the NTFS file system, and format the third partition with the FAT32 file system.
    • If you are testing with a 64-bit edition of Windows, format all three partitions with NTFS.
  17. If you are testing with Windows Server 2003, use Windows Disk Management to create a software RAID 1 mirror from one of the NTFS partitions on RAID Array 2 to the unallocated space on RAID Array 1.
  18. If you are testing with Windows Server 2003, use Windows Disk Management to create a 4-GB NTFS software RAID 5 array that uses unallocated space on RAID Array 1, RAID Array 2, and RAID Array 3.
  19. If you are testing with Windows Vista or Windows XP, use Windows Disk Management to create a 4-GB NTFS spanned volume that uses RAID Array 1, RAID Array 2, and RAID Array 3.
  20. Install DTM Client.
  21. Configure the machine for testing in DTM Studio.
    1. Add the machine to a machine pool.
    2. Deploy the WDK\ConfigureSerialRaidStorageController” dimension.


Preparing for Serial ATA RAID Controller Testing with the Secondary Configuration

You should configure the test system for Serial ATA RAID controller testing in the secondary configuration in the following situations:

  • The Serial ATA RAID controller test device is an integrated controller.

    Note You must use the default procedure for integrated controllers if a system that meets the hardware requirements with two of these integrated controllers is available, or if a duplicate PCI adapter version of this Serial ATA RAID controller is available.

  • The Serial ATA RAID controller is designed for and sold only in a host test system that will accept only a single version of the controller.

If the preceding situations do not apply, you must use the default procedure for Serial ATA RAID Controller testing.

Before you run the Serial ATA RAID controller logo tests with the secondary configuration, you must configure the test system, determine the appropriate RAID levels for devices, install the operating system, and then install the DTM Client according to the following procedures.

To configure the test system for SAS RAID controller testing

    Note All adapters should be operated with BIOS enabled, unless otherwise noted.

  1. Turn off the test system.
  2. Install an add-in controller (not the test device) that has signed drivers or in-box support. If the test device is not bootable, the add-in controller must be boot-capable.
  3. Attach a CD-ROM drive to the add-in controller adapter that you installed in step 2.
  4. If the test device is not bootable, install a hard disk drive on the add-in controller.
  5. Install one Serial ATA RAID controller (test device 1).
  6. Install one hard disk drive on each channel that the Serial ATA RAID controller supports. For example, if the test device supports four channels, then it should have four hard disk drives connected to it.

To configure the SAS RAID controller for basic functionality testing

All RAID controllers are required to support only one RAID level; but if more than one required RAID level is supported, these RAID levels must be configured for testing.

However, single Serial ATA RAID controllers might support testing only a decreased number of RAID levels because of the number of drives that are supported. In these cases, you can configure two RAID levels (either RAID 5 and RAID 0 or RAID 1 and RAID 0) for single configuration testing, even though three RAID levels might be supported.

Use the following table to determine the appropriate RAID level to configure the Serial ATA RAID Controllers for testing.

If the test device supports these RAID levels | RAID level for RAID Array 1 | RAID level for RAID Array 2
0 only | 0 | 0
1 only | 1 | 1
5 only | 5 | 5
0 and 1 only | 1 | 0
0 and 5 only | 5 | 0
1 and 5 only | 5 | 1
0, 1, and 5 | 5 | 0

Note All RAID arrays created should be 40 GB.

Note If the controller does not support enough drives to create the required number of arrays, you can replace RAID Array 2 with a hard disk drive that is attached to the add-in controller. If a hard disk drive is already attached to the add-in controller as a boot disk, you must add a second hard disk drive to the add-in controller and create the partitions on the hard disk drive that is not being used to boot.

To install the operating system in the secondary configuration

    Use the following procedure to install the operating system. When you are finished, the RAID array will be configured as shown in Figure 3 for a test device that supports enough hard disk drives to create two RAID arrays, and as shown in Figure 4 for a test device that does not support enough hard disk drives to create two RAID arrays.

  1. Do one of the following to install the appropriate operating system:
    • If the test Serial ATA RAID controller is bootable, insert the operating system CD-ROM into the CD-ROM drive that is connected to the add-in controller, and then install the Windows operating system onto a NTFS-formatted 14-GB partition on RAID array 1.
    • If the test Serial ATA RAID controller is not bootable, install the operating system onto a NTFS-formatted, 14-GB partition on a hard disk drive that is connected to any alternate boot controller that is not being tested in the host test system.
  2. Install any software or drivers that are necessary to connect to and manage the peripheral devices.
  3. Click Start, right-click My Computer, and then click Properties.
  4. On Windows Vista or Windows Longhorn Server, click Advanced System Settings. If you are prompted to enter Administrative credentials or allow the action, enter the credentials or allow the action.
  5. Click the General tab, and note the amount of RAM that the computer has.
  6. Click the Advanced tab, and then under Performance, click Settings. The Performance Options dialog box appears.
  7. Click the Advanced tab, and then under Virtual Memory, click Change. The Virtual Memory dialog box appears.
  8. Click Custom Size, and then type a number that is larger than the size of RAM in the Initial Size text box.

    Note You specify the size of the page file in megabytes (MB). If the amount of RAM on your computer was specified by using gigabytes (GB) or some other measure, convert the amount of RAM to MB before choosing and entering a value for the page file size.

  9. In the Maximum Size text box, type a maximum size value that is larger than the initial size. (It is common for the maximum size to be one and a half to two times the initial size.)
  10. Click Set, and then click OK twice.
  11. In the Advanced tab of the System Properties dialog box, under Startup and Recovery, click Settings.
  12. Under Write debugging information, click the down arrow, and then click Small memory dump (64 KB).
  13. In the Small dump directory box, type X:\Minidump, where X is the drive letter of one of the RAID partitions.
  14. Click OK twice, and then restart the computer to update the page file size.
  15. Install the Debugging Tools for Windows to the C:\Debuggers directory.
  16. Copy the Microsoft Windows Symbols files to the C:\Symbols directory.
  17. Configure all of the disks to be dynamic.
  18. Use the Windows Disk Management utility to set up three 4-GB partitions on RAID Array 1, and then do one of the following:
    1. If you are testing with a 32-bit edition of the Windows operating system, format two of the partitions with the NTFS file system, and format the third partition with FAT32.
    2. If you are testing with a 64-bit edition of Windows, format all three partitions with NTFS.
  19. If you are testing with Windows Server 2003, Enterprise Edition, use Windows Disk Management to create a software RAID 1 mirror of one of the NTFS partitions on the first array to the unallocated space on the second array.
  20. If you are testing with Windows Vista or Windows XP, use Windows Disk Management to create a spanned volume that uses the unallocated space on both arrays to create an NTFS partition.
  21. Install DTM Client.
  22. Configure the machine for testing in DTM Studio:
    1. Add the machine to a machine pool.
    2. Deploy the WDK\ConfigureSerialRaidStorageController” dimension.


Running the Serial ATA RAID Controller Tests

To test SAS RAID Controllers, do the following:

  1. Open Device Console in DTM Studio.
  2. Create a new submission for “Storage > Adapter or Controller > Serial ATA RAID”.
    • If the device has a driver, select the driver INF when prompted.
    • Make sure to select the SATA RAID Controller test from the device list.
  3. Select the tests that you want to start, choose Add Selected, and then click Schedule.

Crashdump Support Test

Setup: This test requires that the machine has Operating System Symbols installed in C:\symbols. This test will automatically install the Debugging Tools for Windows as a setup task.

Troubleshooting: If you encounter a test failure at any point before the final Logging phase of the test, ensure that you have the correct symbols.

Note This test will intentionally cause the system to stop responding. A bugcheck during the test is normal if caused by Bugcheck.sys.

Note This test restarts the system.

More Info:

Data Verification Test

Input: This test accepts a single drive letter and a PNP ID as input. These are both provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any file system.

Note This test restarts the system.

Ext Int13h Test

More Info:

SATA IO Sig Test

More Info:

Storage Device Stress

Input: This test accepts a string of drive letters as input. This string is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any file system.

More Info:

Driver Verifier

More Info:

Device Path Exerciser

More Info:

Sleep Stress with IO

More Info:

Disable Enable with IO

More Info:

Plug and Play Driver Test

More Info:

Prefast for Drivers Test

More Info:

Static Driver Verifier Test

More Info:

Stress Test

More Info:

Stress Test with low resource simulation

More Info:

Sleep Stress Disable Enable with IO

More Info:


Troubleshooting Serial ATA RAID Controller Testing

For more information about troubleshooting Serial ATA RAID Controller testing, see Troubleshooting Storage Tests.


Storage > CD or DVD Drive Testing Overview

ATA/ATAPI CD/DVD Drive Testing Overview

IEEE 1394 CD/DVD Drive Testing Overview

PCCard CD/DVD Drive Testing Overview

SATA CD/DVD Drive Testing Overview

SCSI CD/DVD Drive Testing Overview

USB CD/DVD Drive Testing Overview


ATA/ATAPI CD/DVD Drive Testing Overview

The procedures presented in this section outline the process for testing your ATA/ATAPI CD/DVD Drive for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as requried for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

Using the Test Procedure Help Topics

The test procedures are divided into the following types of topics:

Overview: The overview topics describe the hardware, software, and tester knowledge requirements.

Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.

Running: The running topics describe how to run to run the tests for your device or system.

ATA/ATAPI CD/DVD Drive Tests

The list of test you need to run depend upon the capabilities of the device or system being tested. The following is the complete list of tests that could be required for your test device:

MMC Test

Storage Device Stress test (SDStress)

System - Sleep Stress with IO

Disable Enable with IO

Plug and Play Driver Test

Stress Test

Core Stress Test

If the drive is writable:

UDF Formatter Tests

Run time: approximately 2 hours

Hardware requirements

The following hardware is required for ATA/ATAPI CD/DVD Drive testing. Additional hardware may be required if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One computer with the following:
    • Dual-core or equivalent processor (Windows Vista / XP)
    • Quad-core or equivalent processor (Windows Longhorn Server / Server 2003)
    • 2 GB memory (Windows Vista / XP)
    • 6 GB memory (Windows Longhorn Server / Server 2003)
    • Logo-compliant ACPI BIOS, with ACPI enabled by default
    • One dual channel ATA/ATAPI controller implemented on the motherboard
    • One monitor, one keyboard, and one mouse (or any pointing/drawing device)

  • One ATA/ATAPI CD/DVD drive (test device)
  • Blank medias supported by the test device
  • One DMA-capable ATA/ATAPI hard disk drive with minimum 10 GB capacity
  • Two standard ATA/ATAPI cables

ATA-66 and ATA-100 controllers require 80-conductor cables.

  • Two ATA/ATAPI cable-select cables

Software requirements

The following software is required to run the ATA/ATAPI CD/DVD Drive tests:

One of the following operating systems:

  • Microsoft Windows Vista
  • Microsoft Windows XP Professional with Service Pack 2 (SP2)
  • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
  • Microsoft Windows Server 2003, Datacenter Edition, with SP1
  • Microsoft Windows Server XP Professional x64 Edition
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows Server 2003, Datacenter x64 Edition
  • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
  • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems
  • Any drivers that are not shipped with the operating system
  • The current release of the Microsoft WDK

Tester knowledge requirements

To run the ATA/ATAPI CD/DVD Drive tests, testers must know how to accomplish the following tasks:

  • Install a hard disk drive as a Device 0
  • Format and partition a hard disk
  • Install a CD/DVD drive as a Device 0 and Device 1
  • Access and change the system BIOS settings
  • Install the operating system from the product CD


Preparing for ATA/ATAPI CD/DVD Drive Testing

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see the ATA/ATAPI CD/DVD Drive Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, see [image] How to turn on automatic logon in Windows XP.

To configure the test system for ATA/ATAPI CDDVD drive testing

  1. Install the test device using a standard ATA/ATAPI cable. You may install the test device as Device 1 or Cable Select Device 1 on the primary ATA/ATAPI channel, or as Device 0, Device 1, Cable Select Device 0, or Cable Select Device 1 on the secondary ATA/ATAPI channel.
  2. Install one hard disk drive as a stand-alone Device 0 on the primary ATA/ATAPI channel of the test system using a standard ATA/ATAPI cable.
  3. Set the system BIOS to support the S3 state.
  4. Install the appropriate Microsoft Windows operating system on the hard disk in the test system.
  5. If necessary, install any drivers supplied by the manufacturer that are required by devices in the test system.
  6. If appropriate, enable auto logon functionality.
  7. Install DTM Client.
  8. Configure the machine for testing in DTM Studio.
    1. Add the machine to a machine pool.
    2. Deploy the WDK\ConfigureCdDvdDrives” dimension.


Running the ATA/ATAPI CD/DVD Drive Tests

Open Device Console in DTM Studio.

Create a new submission for “Storage > CD or DVD Drive”.

The test device should not require a driver. Please select “No Driver Files” when prompted.

Make sure to select the test CD/DVD Drive from the device list.

Select the tests which you wish to launch, choose Add Selected, and then click schedule.

MMC Test

Input: This test accepts a single drive letter. This is automatically by DTM.

Storage Device Stress

Input: This test accepts a string of drive letters as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

More Info:

Disable Enable with IO

More Info:

Plug and Play Driver Test

More Info:

Stress Test

More Info:

Stress Test with low resource simulation

More Info:

Sleep Stress Disable Enable with IO

More Info:

If the drive is writable:

UDF Formatter Test

Input: This test accepts a single drive letter. This is automatically by DTM.


Troubleshooting ATA/ATAPI CD/DVD Drive Testing

For more information about troubleshooting ATA/ATAPI CD/DVD drive testing, see Troubleshooting Storage Tests.


IEEE 1394 CD/DVD Drive Testing Overview

The procedures presented in this section outline the process for testing your IEEE 1394 CD/DVD Drive for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as requried for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

Using the Test Procedure Help Topics

The test procedures are divided into the following types of topics:

Overview: The overview topics describe the hardware, software, and tester knowledge requirements.

Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.

Running: The running topics describe how to run to run the tests for your device or system.

IEEE 1394 CD/DVD Drive Tests

The list of test you need to run depend upon the capabilities of the device or system being tested. The following is the complete list of tests that could be required for your test device:

1394 Configuration tests

MMC Test

Storage Device Stress test (SDStress)

System - Sleep Stress with IO

Disable Enable with IO

Plug and Play Driver Test

Stress Test

Core Stress Test

If the drive is writable:

UDF Formatter Tests

Run time: approximately 2 hours

Hardware requirements

The following hardware is required for IEEE 1394 CD/DVD Drive testing. Additional hardware may be required if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One computer with the following:
    • Dual-core or equivalent processor (Windows Vista / XP)
    • Quad-core or equivalent processor (Windows Longhorn Server / Server 2003)
    • 2 GB memory (Windows Vista / XP)
    • 6 GB memory (Windows Longhorn Server / Server 2003)
    • Logo-compliant ACPI BIOS, with ACPI enabled by default
    • One dual channel ATA/ATAPI controller implemented on the motherboard
    • One IEEE 1394 host controller
    • One monitor, one keyboard, and one mouse (or any pointing/drawing device)

  • One IEEE 1394 CD/DVD drive (test device)
  • Blank medias supported by the test device
  • One IEEE 1394 cable
  • One ATA/ATAPI CD-ROM drive, minimum 8x speed
  • One ATA/ATAPI hard disk drive, minimum capacity 10 GB
  • Two standard ATA/ATAPI cables

ATA-66 and ATA-100 controllers require 80-conductor cables.

Software requirements

The following software is required to run the IEEE 1394 CD/DVD Drive tests:

One of the following operating systems:

  • Microsoft Windows Vista
  • Microsoft Windows XP Professional with Service Pack 2 (SP2)
  • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
  • Microsoft Windows Server 2003, Datacenter Edition, with SP1
  • Microsoft Windows Server XP Professional x64 Edition
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows Server 2003, Datacenter x64 Edition
  • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
  • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems
  • Microsoft Windows Vista
  • Any drivers that are not shipped with the operating system
  • The current release of the Microsoft WDK

Tester knowledge requirements

To run the IEEE 1394 CD/DVD Drive tests, testers must know how to accomplish the following tasks:

  • Install a hard disk drive as a Device 0
  • Format and partition a hard disk
  • Install a CD-ROM drive as a Device 0
  • Install an IEEE 1394 controller
  • Install an audio adapter
  • Access and change the system BIOS settings
  • Install the operating system from the product CD


Preparing for IEEE 1394 CD/DVD Drive Testing

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see the IEEE 1394 CD/DVD Drive Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, see [image] How to turn on automatic logon in Windows XP.

Test system configuration

The IEEE 1394 CD/DVD drive logo program requires the following to prepare the test system for testing an IEEE 1394 CD/DVD drive:

To assemble the test system for IEEE 1394 CD/DVD drive testing

  1. With the test system turned off and disconnected from the power supply, install an ATA/ATAPI hard disk drive as a stand-alone Device 0 on the primary ATA/ATAPI channel using a standard ATA/ATAPI cable.
  2. Install an ATA/ATAPI CD-ROM drive as a stand-alone Device 0 on the secondary ATA/ATAPI channel using a standard ATA/ATAPI cable.
  3. If the IEEE 1394 host controller is not embedded on the system motherboard, install one IEEE 1394 host controller.
  4. Attach the test device to the IEEE 1394 host controller.

To configure the test system for IEEE 1394 CD/DVD drive testing

  1. Turn on the test system.
  2. Set the system BIOS to support the S3 state.
  3. Install the Microsoft Windows operating system on the hard disk.
    During installation, create one partition and format the partition with the NTFS file system. Leave a minimum of 3,000 MB of free disk space for three additional partitions.
  4. If necessary, install any manufacturer-supplied drivers required by devices in the test system.
  5. If appropriate, enable auto logon functionality.
  6. Install DTM Client.
  7. Configure the machine for testing in DTM Studio.
    1. Add the machine to a machine pool.
    2. Deploy the WDK\ConfigureCdDvdDrives” dimension.


Running the IEEE 1394 CD/DVD Drive Tests

Open Device Console in DTM Studio.

Create a new submission for “Storage > CD or DVD Drive”.

The test device should not require a driver. Please select “No Driver Files” when prompted.

Make sure to select the test CD/DVD Drive from the device list.

Select the tests which you wish to launch, choose Add Selected, and then click schedule.

1394 Configuration tests

MMC Test

Input: This test accepts a single drive letter. This is automatically by DTM.

Storage Device Stress

Input: This test accepts a string of drive letters as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

More Info:

Disable Enable with IO

More Info:

Plug and Play Driver Test

More Info:

Stress Test

More Info:

Stress Test with low resource simulation

More Info:

Sleep Stress Disable Enable with IO

More Info:

If the drive is writable:

UDF Formatter Test

Input: This test accepts a single drive letter. This is automatically by DTM.


Troubleshooting IEEE 1394 CD/DVD Drive Testing

For more information about troubleshooting IEEE 1394 CD/DVD drive testing, see Troubleshooting Storage Tests.


PCCard CD/DVD Drive Testing Overview

The procedures presented in this section outline the process for testing your PCCard CD/DVD Drive for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as requried for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

Using the Test Procedure Help Topics

The test procedures are divided into the following types of topics:

Overview: The overview topics describe the hardware, software, and tester knowledge requirements.

Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.

Running: The running topics describe how to run to run the tests for your device or system.

PCCard CD/DVD Drive Tests

The list of test you need to run depend upon the capabilities of the device or system being tested. The following is the complete list of tests that could be required for your test device:

CardBus Card Configuration Space Register test

CardBus Card Common Silicon Guidelines test

CardBus Bridge Power Management Register Test

MMC Test

Storage Device Stress test (SDStress)

System - Sleep Stress with IO

Disable Enable with IO

Plug and Play Driver Test

Stress Test

Core Stress Test

If the drive is writable:

UDF Formatter Tests

Run time: approximately 2 hours

Hardware requirements

The following hardware is required for PCCard CD/DVD Drive testing. Additional hardware may be required if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One computer with the following:
    • Dual-core or equivalent processor (Windows Vista / XP)
    • Quad-core or equivalent processor (Windows Longhorn Server / Server 2003)
    • 2 GB memory (Windows Vista / XP)
    • 6 GB memory (Windows Longhorn Server / Server 2003)
    • Logo-compliant ACPI BIOS, with ACPI enabled by default
    • Dual PC Card controllers
    • Minimum 10 GB hard disk drive
    • One monitor, one keyboard, and one mouse (or any pointing or drawing device)

  • Two PC Card CD/DVD drive (test device)
  • Blank Medias supported by the test device
  • One PC Card network adapter

Software requirements

The following software is required to run the PCCard CD/DVD Drive tests:

One of the following operating systems:

  • Microsoft Windows Vista
  • Microsoft Windows XP Professional with Service Pack 2 (SP2)
  • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
  • Microsoft Windows Server 2003, Datacenter Edition, with SP1
  • Microsoft Windows Server XP Professional x64 Edition
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows Server 2003, Datacenter x64 Edition
  • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
  • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems
  • Any drivers that are not shipped with the operating system
  • The current release of the Microsoft WDK

Tester knowledge requirements

To run the PCCard CD/DVD Drive tests, testers must know how to accomplish the following tasks:

  • Format and partition a hard disk
  • Install a PC Card CD-R and CD-RW drive
  • Install a PC Card network adapter
  • Access and change the system BIOS settings
  • Install the operating system from the product CD


Preparing for PCCard CD/DVD Drive Testing

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see the PCCard CD/DVD Drive Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, see [image] How to turn on automatic logon in Windows XP.

To configure the system for PC Card CD/DVD drive testing

  1. Install the CD/DVD drive (test device) on the PC Card channel of the test system.
  2. Install the PC Card network adapter on the second PC Card controller in the test system.
  3. Set the system BIOS to support the S3 state.
  4. Install the appropriate Microsoft Windows operating system on the hard disk in the test system.
  5. If necessary, install any manufacturer-supplied drivers required by devices in the test system.
  6. If appropriate, enable auto logon functionality.
  7. Install DTM Client.
  8. Configure the machine for testing in DTM Studio.
    1. Add the machine to a machine pool.
    2. Deploy the WDK\ConfigureCdDvdDrives” dimension.


Running the PCCard CD/DVD Drive Tests

Open Device Console in DTM Studio.

Create a new submission for “Storage > CD or DVD Drive”.

The test device should not require a driver. Please select “No Driver Files” when prompted.

Make sure to select the test CD/DVD Drive from the device list.

Select the tests which you wish to launch, choose Add Selected, and then click schedule.

CardBus Card Common Silicon Guidelines

Note: Ensure that the CardBus card is installed during this test.

More Info:

CardBus Bridge Power Management Register

Note: Ensure that the CardBus card is installed during this test.

More Info:

CardBus Bridge Register

More Info:

MMC Test

Input: This test accepts a single drive letter. This is automatically by DTM.

Storage Device Stress

Input: This test accepts a string of drive letters as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

More Info:

Disable Enable with IO

More Info:

Plug and Play Driver Test

More Info:

Stress Test

More Info:

Stress Test with low resource simulation

More Info:

Sleep Stress Disable Enable with IO

More Info:

If the drive is writable:

UDF Formatter Test

Input: This test accepts a single drive letter. This is automatically by DTM.


Troubleshooting PCCard CD/DVD Drive Testing

For more information about troubleshooting PCCard CD/DVD drive testing, see Troubleshooting Storage Tests.


SATA CD/DVD Drive Testing Overview

The procedures presented in this section outline the process for testing your SATA CD/DVD Drive for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as requried for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

Using the Test Procedure Help Topics

The test procedures are divided into the following types of topics:

Overview: The overview topics describe the hardware, software, and tester knowledge requirements.

Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.

Running: The running topics describe how to run to run the tests for your device or system.

SATA CD/DVD Drive Tests

The list of test you need to run depend upon the capabilities of the device or system being tested. The following is the complete list of tests that could be required for your test device:

MMC Test

Storage Device Stress test (SDStress)

System - Sleep Stress with IO

Disable Enable with IO

Plug and Play Driver Test

Stress Test

Core Stress Test

Run time: approximately 2 hours

Hardware requirements

The following hardware is required for SATA CD/DVD Drive testing. Additional hardware may be required if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One computer with the following:
    • Dual-core or equivalent processor (Windows Vista / XP)
    • Quad-core or equivalent processor (Windows Longhorn Server / Server 2003)
    • 2 GB memory (Windows Vista / XP)
    • 6 GB memory (Windows Longhorn Server / Server 2003)
    • Logo-compliant ACPI BIOS, with ACPI enabled by default
    • One monitor, one keyboard, and one mouse (or any pointing/drawing device)

  • One Serial ATA controller
  • One bootable bus controller (for example, a SCSI controller) if the Serial ATA controller is not bootable. If the Serial ATA controller is bootable, you do not need an additional controller.
  • One Serial ATA CD/DVD drive (the test device)
  • Blank medias supported by the test device
  • One hard disk drive with minimum 10 GB capacity
  • One Serial ATA cable

Software requirements

The following software is required to run the SATA CD/DVD Drive tests:

One of the following operating systems:

  • Microsoft Windows Vista
  • Microsoft Windows XP Professional with Service Pack 2 (SP2)
  • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
  • Microsoft Windows Server 2003, Datacenter Edition, with SP1
  • Microsoft Windows Server XP Professional x64 Editio
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows Server 2003, Datacenter x64 Edition
  • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
  • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems
  • Any drivers that are not shipped with the operating system
  • The current release of the Microsoft WDK

Tester knowledge requirements

To run the SATA CD/DVD Drive tests, testers must know how to accomplish the following tasks:

  • Install a hard disk drive as a Device 0
  • Format and partition a hard disk
  • Install a CD/DVD drive as a Device 0 and Device 1
  • Access and change the system BIOS settings
  • Install the operating system from the product CD


Preparing for SATA CD/DVD Drive Testing

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see the SATA CD/DVD Drive Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, see [image] How to turn on automatic logon in Windows XP.

To configure the test system for Serial ATA CD/DVD drive testing

  1. Install the bootable bus controller.
  2. Install the hard disk drive and connect it to the bootable controller.
  3. If the bootable controller that you installed in the first step is not a Serial ATA controller, then install a Serial ATA controller.
  4. Install the test device using a Serial ATA cable.
  5. Set the system BIOS to support the S3 state.
  6. Install the appropriate Microsoft Windows operating system on the hard disk in the test system.
  7. If necessary, install any drivers supplied by the manufacturer that are required by devices in the test system.
  8. If appropriate, enable auto logon functionality.
  9. Install DTM Client.
  10. Configure the machine for testing in DTM Studio.
    1. Add the machine to a machine pool.
    2. Deploy the WDK\ConfigureCdDvdDrives” dimension.


Running the SATA CD/DVD Drive Tests

Open Device Console in DTM Studio.

Create a new submission for “Storage > CD or DVD Drive”.

The test device should not require a driver. Please select “No Driver Files” when prompted.

Make sure to select the test CD/DVD Drive from the device list.

Select the tests which you wish to launch, choose Add Selected, and then click schedule.

MMC Test

Input: This test accepts a single drive letter. This is automatically by DTM.

Storage Device Stress

Input: This test accepts a string of drive letters as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

More Info:

Disable Enable with IO

More Info:

Plug and Play Driver Test

More Info:

Stress Test

More Info:

Stress Test with low resource simulation

More Info:

Sleep Stress Disable Enable with IO

More Info:

If the drive is writable:

UDF Formatter Test

Input: This test accepts a single drive letter. This is automatically by DTM.


Troubleshooting SATA CD/DVD Drive Testing

For more information about troubleshooting SATA CD/DVD drive testing, see Troubleshooting Storage Tests.


SCSI CD/DVD Drive Testing Overview

The procedures presented in this section outline the process for testing your SCSI CD/DVD Drive for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as requried for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

Using the Test Procedure Help Topics

The test procedures are divided into the following types of topics:

Overview: The overview topics describe the hardware, software, and tester knowledge requirements.

Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.

Running: The running topics describe how to run to run the tests for your device or system.

SCSI CD/DVD Drive Tests

The list of test you need to run depend upon the capabilities of the device or system being tested. The following is the complete list of tests that could be required for your test device:

MMC Test

Storage Device Stress test (SDStress)

System - Sleep Stress with IO

Disable Enable with IO

Plug and Play Driver Test

Stress Test

Core Stress Test

Run time: approximately 2 hours

Hardware requirements

The following hardware is required for SCSI CD/DVD Drive testing. Additional hardware may be required if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One computer with the following:
    • Dual-core or equivalent processor (Windows Vista / XP)
    • Quad-core or equivalent processor (Windows Longhorn Server / Server 2003)
    • 2 GB memory (Windows Vista / XP)
    • 6 GB memory (Windows Longhorn Server / Server 2003)
    • Logo-compliant ACPI BIOS, with ACPI enabled by default
    • One PCI bus
    • One monitor, one keyboard, and one mouse (or any pointing or drawing device)

  • One SCSI CD/DVD drive (test device)
  • Several pieces of blank medias for the test device
  • A SCSI adapter with appropriate bus interface for the test device, such as Narrow, Wide, or LVD
  • One SCSI hard disk drive, minimum 10 GB capacity

Software requirements

The following software is required to run the SCSI CD/DVD Drive tests:

One of the following operating systems:

  • Microsoft Windows Vista
  • Microsoft Windows XP Professional with Service Pack 2 (SP2)
  • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
  • Microsoft Windows Server 2003, Datacenter Edition, with SP1
  • Microsoft Windows Server XP Professional x64 Edition
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows Server 2003, Datacenter x64 Edition
  • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
  • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems
  • Any drivers that are not shipped with the operating system
  • The current release of the Microsoft WDK

Tester knowledge requirements

To run the SCSI CD/DVD Drive tests, testers must know how to accomplish the following tasks:

  • Install a hard disk drive
  • Set the SCSI ID on a hard disk drive
  • Format and partition a hard disk
  • Install a CD/DVD drive
  • Set the SCSI ID on a CD/DVD drive
  • Install a SCSI adapter
  • Access and change the system BIOS settings
  • Install the operating system from the product CD


Preparing for SCSI CD/DVD Drive Testing

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see the SCSI CD/DVD Drive Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, see [image] How to turn on automatic logon in Windows XP.

To configure the test system for SCSI CD/DVD drive testing

Note: All adapters are operated with BIOS enabled and external termination unless otherwise noted.

  1. Set the SCSI ID on the test device to 6, and then physically install the test device on the SCSI adapter.
  2. Set the SCSI ID on the SCSI hard disk drive to 0, and then physically install the hard disk drive on the SCSI adapter.
  3. Set the system BIOS to support the S3 state.
  4. Install the appropriate Microsoft Windows operating system on the hard disk.
  5. If necessary, install any manufacturer-supplied drivers required by devices in the test system.
  6. If appropriate, enable auto logon functionality.
  7. Install DTM Client.
  8. Configure the machine for testing in DTM Studio.
    1. Add the machine to a machine pool.
    2. Deploy the WDK\ConfigureCdDvdDrives” dimension.


Running the SCSI CD/DVD Drive Tests

Open Device Console in DTM Studio.

Create a new submission for “Storage > CD or DVD Drive”.

The test device should not require a driver. Please select “No Driver Files” when prompted.

Make sure to select the test CD/DVD Drive from the device list.

Select the tests which you wish to launch, choose Add Selected, and then click schedule.

MMC Test

Input: This test accepts a single drive letter. This is automatically by DTM.

Storage Device Stress

Input: This test accepts a string of drive letters as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

More Info:

Disable Enable with IO

More Info:

Plug and Play Driver Test

More Info:

Stress Test

More Info:

Stress Test with low resource simulation

More Info:

Sleep Stress Disable Enable with IO

More Info:

If the drive is writable:

UDF Formatter Test

Input: This test accepts a single drive letter. This is automatically by DTM.


Troubleshooting SCSI CD/DVD Drive Testing

For more information about troubleshooting SCSI CD/DVD drive testing, see Troubleshooting Storage Tests.


USB CD/DVD Drive Testing Overview

The procedures presented in this section outline the process for testing your USB CD/DVD Drive for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as requried for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

Using the Test Procedure Help Topics

The test procedures are divided into the following types of topics:

Overview: The overview topics describe the hardware, software, and tester knowledge requirements.

Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.

Running: The running topics describe how to run to run the tests for your device or system.

USB CD/DVD Drive Tests

The list of test you need to run depend upon the capabilities of the device or system being tested. The following is the complete list of tests that could be required for your test device:

USB Address Description Test

USB Descriptor Test

USB Device Control Requests

USB Device Framework

USB Enumeration Stress

USB Selective Suspend

USB Serial Number

USB Specification Compliance

MMC Test

Storage Device Stress test (SDStress)

System - Sleep Stress with IO

Disable Enable with IO

Plug and Play Driver Test

Stress Test

Core Stress Test

Run time: approximately 2 hours

Hardware requirements

The following hardware is required for USB CD/DVD Drive testing. Additional hardware may be required if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One computer with the following:
    • Dual-core or equivalent processor (Windows Vista / XP)
    • Quad-core or equivalent processor (Windows Longhorn Server / Server 2003)
    • 2 GB memory (Windows Vista / XP)
    • 6 GB memory (Windows Longhorn Server / Server 2003)
    • Logo-compliant ACPI BIOS, with ACPI enabled by default
    • Either a USB 2.0 host controller embedded on the system motherboard, or a USB 2.0 controller PCI adapter.

      Note: The USB controller must be able to wake the system using ACPI mechanisms.

  • One USB CD/DVD drive (test device)
  • One DMA-capable ATA/ATAPI hard disk drive, minimum 10 GB capacity
  • One ATA/ATAPI CD-ROM drive, minimum 8X speed
  • Two ATA/ATAPI cables
  • One USB 2.0 high-speed hub

Software requirements

The following software is required to run the USB CD/DVD Drive tests:

One of the following operating systems:

  • Microsoft Windows Vista
  • Microsoft Windows XP Professional with Service Pack 2 (SP2)
  • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
  • Microsoft Windows Server 2003, Datacenter Edition, with SP1
  • Microsoft Windows Server XP Professional x64 Edition
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows Server 2003, Datacenter x64 Edition
  • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
  • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems
  • Any drivers that are not shipped with the operating system
  • The current release of the Microsoft WDK

Tester knowledge requirements

To run the USB CD/DVD Drive tests, testers must know how to accomplish the following tasks:

  • Install a CD-ROM drive as a stand-alone Device 0.
  • Install a hard disk drive as a stand-alone Device 0.
  • Format and partition a hard disk.
  • Install the operating system from the product CD


Preparing for USB CD/DVD Drive Testing

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see the USB CD/DVD Drive Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, see [image] How to turn on automatic logon in Windows XP.

To configure the test system for USB CD/DVD drive testing

  1. If test system does not have an embedded USB 2.0 controller, install a USB 2.0 controller.
  2. Connect the USB 2.0 controller to the high-speed USB 2.0 hub.
  3. Connect the test device to the downstream port of the high-speed USB 2.0 hub.

    Note: Do not connect the USB test device directly to the root hub of the USB 2.0 controller.

  4. Install an ATA/ATAPI hard disk drive as a stand-alone Device 0 on the primary ATA/ATAPI channel using a standard ATA/ATAPI cable.
  5. Install an ATA/ATAPI CD-ROM drive as a stand-alone Device 0 on the secondary ATA/ATAPI channel using a standard ATA/ATAPI cable.
  6. Set the system BIOS to support the S3 state.
  7. If necessary, install any manufacturer-supplied drivers that are required by devices in the test system.
  8. If appropriate, enable auto logon functionality.
  9. Install DTM Client.
  10. Configure the machine for testing in DTM Studio.
    1. Add the machine to a machine pool.
    2. Deploy the WDK\ConfigureCdDvdDrives” dimension.


Running the USB CD/DVD Drive Tests

Open Device Console in DTM Studio.

Create a new submission for “Storage > CD or DVD Drive”.

The test device should not require a driver. Please select “No Driver Files” when prompted.

Make sure to select the test CD/DVD Drive from the device list.

Select the tests which you wish to launch, choose Add Selected, and then click schedule.

USB Address Description Test

More Info:

USB Descriptor Test

More Info:

USB Device Control Requests

More Info:

USB Device Framework

More Info:

USB Enumeration Stress

More Info:

USB Selective Suspend

More Info:

USB Serial Number

More Info:

USB Specification Compliance

More Info:

MMC Test

Input: This test accepts a single drive letter. This is automatically by DTM.

Storage Device Stress

Input: This test accepts a string of drive letters as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

More Info:

Disable Enable with IO

More Info:

Plug and Play Driver Test

More Info:

Stress Test

More Info:

Stress Test with low resource simulation

More Info:

Sleep Stress Disable Enable with IO

More Info:

If the drive is writable:

UDF Formatter Test

Input: This test accepts a single drive letter. This is automatically by DTM.


Troubleshooting USB CD/DVD Drive Testing

For more information about troubleshooting USB CD/DVD drive testing, see Troubleshooting Storage Tests.


Storage > Hard Drive Testing Overview

ATA/ATAPI Hard Disk Drive Testing Overview

Fibre Channel Hard Disk Drive Testing Overview

IEEE 1394 Hard Disk Drive Testing Overview

PC Card Hard Disk Drive Testing Overview

SAS Hard Disk Drive Testing Overview

SATA Hard Disk Drive Testing Overview

SCSI Hard Disk Drive Testing Overview

USB Hard Disk Drive Testing Overview


ATA/ATAPI Hard Disk Drive Testing Overview

The procedures presented in this section outline the process for testing your ATA/ATAPI Hard Disk Drive for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as required for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

Using the Test Procedure Help Topics

The test procedures are divided into the following types of topics:

Overview: The overview topics describe the hardware, software, and tester knowledge requirements.

Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.

Running: The running topics describe how to run to run the tests for your device or system.

ATA/ATAPI Hard Disk Drive Tests

The list of tests you need to run depend upon the capabilities of the device or system being tested. To see the complete list of tests that could be required for your test device:

Storage Data Verification Filter Test

SMART test utility

Storage Device Stress test (SDStress)

Anti-Virus/File System Filter Test Kit

Syscache Test

System - Sleep Stress with IO

Disable Enable with IO

Plug and Play Driver Test

Stress Test

Core Stress Test

If the disk is a Hybrid disk then it should run the following logo test:

PitonDisk Test

Run time: approximately 2 hours

Hardware requirements

The following hardware is required for ATA/ATAPI Hard Disk Drive testing. Additional hardware may be required if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One computer with the following:
    • Dual-core or equivalent processor (Windows Vista / XP)
    • Quad-core or equivalent processor (Windows Longhorn Server / Server 2003)
    • 2 GB memory (Windows Vista / XP)
    • 6 GB memory (Windows Longhorn Server / Server 2003)
    • Logo-compliant ACPI BIOS, with ACPI enabled by default
    • One dual channel ATA/ATAPI controller implemented on the motherboard

  • Two identical ATA/ATAPI hard disk drives - These are the test devices.
  • One ATA/ATAPI CD-ROM drive
  • Two standard ATA/ATAPI cables

    Note: ATA-66 and ATA-100 controllers require 80-conductor cables.

  • One cable-select ATA/ATAPI cable

Software requirements

The following software is required to run the ATA/ATAPI Hard Disk Drive tests:

One of the following operating systems:

  • Microsoft Windows Vista
  • Microsoft Windows XP Professional with Service Pack 2 (SP2)
  • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
  • Microsoft Windows Server 2003, Datacenter Edition, with SP1
  • Microsoft Windows Server XP Professional x64 Edition
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows Server 2003, Datacenter x64 Edition
  • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
  • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems
  • Any drivers that are not shipped with the operating system
  • The current release of the Microsoft WDK

Tester knowledge requirements

To run the ATA/ATAPI Hard Disk Drive tests, testers must know how to accomplish the following tasks:

  • Install a hard disk drive as a Device 0, a Device 1, and a cable-select Device 0.
  • Install a CD-ROM drive as a stand-alone Device 0, a Device 1, and a cable-select Device Format and partition a hard disk.
  • Use Disk Management to convert a disk formatted with the GPT disk partitioning style to the MBR disk partitioning style.
  • Use Disk Management to create mirrored volumes on a disk.
  • Install the operating system from the product CD


Preparing for ATA/ATAPI Hard Disk Drive Testing

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see ATA/ATAPI Hard Disk Drive Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about auto logon, see [image] How to turn on automatic logon in Windows XP.

Test system configuration

The ATA/ATAPI hard disk drive kit requires the following to prepare the test system for ATA/ATAPI hard disk drive testing:

To configure the test system for ATA/ATAPI hard disk drive testing

  1. Install the hard disk drive (test device) as a stand-alone Device 0 on the primary ATA/ATAPI channel using a standard ATA/ATAPI cable.
  2. Install the CD-ROM drive using a standard ATA/ATAPI cable. You may install the CD-ROM drive as Device 1 or Cable Select Device 1 on the primary ATA/ATAPI channel, or as Device 0, Device 1, Cable Select Device 0, or Cable Select Device 1 on the secondary ATA/ATAPI channel.
  3. Set the system BIOS to support the S3 state.
  4. Install the appropriate Microsoft Windows operating system on the test device.
  5. If necessary, install any drivers supplied by manufacturers that are required by devices in the test system.
  6. With the test system turned off, configure the test device as a Device 0.
    This drive is referred to as Drive 1 in the following procedures.
  7. With the test system turned off, install an identical hard disk drive using a standard ATA/ATAPI cable. You may install this drive as Device 1 or Cable Select Device 1 on the primary ATA/ATAPI channel, or as Device 0, Device 1, Cable Select Device 0, or Cable Select Device 1 on the secondary ATA/ATAPI channel. This drive is referred to as Drive 2 in the following procedures.
  8. If testing the hybrid disk, install the disk on a secondary channel and the disk should be a secondary disk.
  9. Remove any partitions on the test device, and convert the test device to use the MBR partitioning style.
  10. If appropriate, enable auto logon functionality.
  11. Install the DTM client
  12. Configure the machine for testing in DTM Studio.
    1.Add the machine to a machine pool.
    2.Deploy the “WDK\ConfigureHardDiskDrive” dimension.


Running the ATA/ATAPI Hard Disk Drive Tests

Open Device Console in DTM Studio.

Create a new submission for “Storage > Hard Drive”.

The test device should not require a driver. Please select “No Driver Files” when prompted.

Make sure to select the test Hard Disk Drive from the device list.

Select the tests which you wish to launch, choose Add Selected, and then click schedule.

Data Verification Test

Input: This test accepts a single drive letter and a PNP ID as input. These are both provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

Note: This test reboots the system.

Storage Device Stress

Input: This test accepts a string of drive letters as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

More Info:

IFS Test

Input: This test accepts a single drive letter as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem. The test will reformat this partition and perform a series of operations.

WARNING: Any data saved on the test device will be lost.

Note: This test reboots the system.

More Info:

SyscacheTest

Input: This test accepts a single drive letter as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

More Info:

Piton Logo Test

Input: This test accepts device number as input. This is provided automatically by DTM.

More Info:

Sleep Stress with IO

More Info:

Disable Enable with IO

More Info:

Plug and Play Driver Test

More Info:

Stress Test

More Info:

Stress Test with low resource simulation

More Info:

Sleep Stress Disable Enable with IO

More Info:


Troubleshooting ATA/ATAPI Hard Disk Drive Testing

For more information about troubleshooting ATA/ATAPI hard disk drive testing, see Troubleshooting Storage Tests.


Fibre Channel Hard Disk Drive Testing Overview

The procedures presented in this section outline the process for testing your Fibre Channel Hard Disk Drive for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as requried for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

Using the Test Procedure Help Topics

The test procedures are divided into the following types of topics:

Overview: The overview topics describe the hardware, software, and tester knowledge requirements.

Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.

Running: The running topics describe how to run to run the tests for your device or system.

Fibre Channel Hard Disk Drive Tests

The list of test you need to run depend upon the capabilities of the device or system being tested. The following is the complete list of tests that could be required for your test device:

Storage Data Verification Filter Test

SCSI Compliance test

Storage Device Stress test (SDStress)

Anti-Virus/File System Filter Test Kit

Syscache Test

System - Sleep Stress with IO

Disable Enable with IO

Plug and Play Driver Test

Stress Test

Core Stress Test

If the disk is a Hybrid disk then it should run the following logo test:

PitonDisk Test

Run time: approximately 2 hours

Hardware requirements

The following hardware is required for Fibre Channel Hard Disk Drive testing. Additional hardware may be required if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One computer with the following:
    • Dual-core or equivalent processor (Windows Vista / XP)
    • Quad-core or equivalent processor (Windows Longhorn Server / Server 2003)
    • 2 GB memory (Windows Vista / XP)
    • 6 GB memory (Windows Longhorn Server / Server 2003)
    • Logo-compliant ACPI BIOS, with ACPI enabled by default
    • One SCSI controller
    • One monitor, one keyboard, and one mouse (or any pointing or drawing device)

  • Two identical Fibre Channel hard disk drives. These are the test devices.
  • One Fibre Channel controller
  • One SCSI hard disk drives, minimum 10 GB capacity
  • One CD-ROM drive, minimum 8X speed
  • One Fibre Channel hub

Software requirements

The following software is required to run the Fibre Channel Hard Disk Drive tests:

One of the following operating systems:

  • Microsoft Windows Vista
  • Microsoft Windows XP Professional with Service Pack 2 (SP2)
  • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
  • Microsoft Windows Server 2003, Datacenter Edition, with SP1
  • Microsoft Windows Server XP Professional x64 Edition
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows Server 2003, Datacenter x64 Edition
  • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
  • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems
  • Any drivers that are not shipped with the operating system
  • The current release of the Microsoft WDK

Tester knowledge requirements

To run the Fibre Channel Hard Disk Drive tests, testers must know how to accomplish the following tasks:

  • Install a hard disk drive, CD-ROM drive, Fibre Channel controller, and Fibre Channel hub
  • Format and partition a hard disk drive
  • Use Disk Management to create dynamic disks and mirrored volumes on a disk
  • Install the operating system from the product CD


Preparing for Fibre Channel Hard Disk Drive Testing

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see Fibre Channel Hard Disk Drive Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, see [image] How to turn on automatic logon in Windows XP.

Test system configuration

The Fibre Channel hard disk drive logo program requires the following to prepare the test system for Fibre Channel hard disk drive testing:

To assemble the test system for Fibre Channel hard disk drive testing

  1. If the test system does not have a SCSI adapter installed, install the SCSI adapter.
  2. Install two identical SCSI hard disk drives and one CD-ROM drive onto the SCSI bus.
  3. Install one Fibre Channel controller.
  4. Install one Fibre Channel hub on the Fibre Channel controller.
  5. Connect Fibre Channel hard disk drives (test devices) to the Fibre Channel hub.

To configure the test system for Fibre Channel hard disk drive testing

  1. Set the system BIOS to support the S3 state.
  2. Install the appropriate operating system on one of the SCSI hard disk drives.
  3. If necessary, install any manufacturer-supplied drivers that are required by devices in the test system.
  4. If appropriate, enable auto logon functionality.
  5. Restart the system.
  6. Using the Windows Disk Management utility, delete all existing partitions on the Fibre Channel hard disk drives.
  7. Create two partitions
  8. Use Disk Management to convert the first and second Fibre Channel hard disk drives (Drive 1 and Drive 2) to dynamic disks.
  9. Use Disk Management to create an NTFS mirrored volume that is larger than 10 GB on Drive 1 and on Drive 2.
    Leave a minimum of 4 GB free disk space on Drive 2
  10. Install the DTM client
  11. Configure the machine for testing in DTM Studio.
    1. Add the machine to a machine pool.
    2. Deploy the “WDK\ConfigureHardDiskDrive” dimension.


Running the Fibre Channel Hard Disk Drive Tests

Open Device Console in DTM Studio.

Create a new submission for “Storage > Hard Drive”.

The test device should not require a driver. Please select “No Driver Files” when prompted.

Make sure to select the test Hard Disk Drive from the device list.

Select the tests which you wish to launch, choose Add Selected, and then click schedule.

Data Verification Test

Input: This test accepts a single drive letter and a PNP ID as input. These are both provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

Note: This test reboots the system.

Storage Device Stress

Input: This test accepts a string of drive letters as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

More Info:

IFS Test

Input: This test accepts a single drive letter as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem. The test will reformat this partition and perform a series of operations.

WARNING: Any data saved on the test device will be lost.

Note: This test reboots the system.

More Info:

SyscacheTest

Input: This test accepts a single drive letter as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

More Info:

SCSI Compliance

Input: This test accepts the physical path of the test device as input. This is provided automatically by DTM.

More Info:

Sleep Stress with IO

More Info:

Disable Enable with IO

More Info:

Plug and Play Driver Test

More Info:

Stress Test

More Info:

Stress Test with low resource simulation

More Info:

Sleep Stress Disable Enable with IO

More Info:


Troubleshooting Fibre Channel Hard Disk Drive Testing

For more information about troubleshooting Fibre Channel hard disk drive testing, see Troubleshooting Storage Tests.


IEEE 1394 Hard Disk Drive Testing Overview

The procedures presented in this section outline the process for testing your IEEE 1394 Hard Disk Drive for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as requried for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

Using the Test Procedure Help Topics

The test procedures are divided into the following types of topics:

Overview: The overview topics describe the hardware, software, and tester knowledge requirements.

Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.

Running: The running topics describe how to run to run the tests for your device or system.

IEEE 1394 Hard Disk Drive Tests

The list of test you need to run depend upon the capabilities of the device or system being tested. The following is the complete list of tests that could be required for your test device:

1394 Configuration test

1394 Interoperability test

Storage Data Verification Filter Test

Storage Device Stress test (SDStress)

Anti-Virus/File System Filter Test Kit

Syscache Test

System - Sleep Stress with IO

Disable Enable with IO

Plug and Play Driver Test

Stress Test

Core Stress Test

Run time: approximately 2 hours

Hardware requirements

The following hardware is required for IEEE 1394 Hard Disk Drive testing. Additional hardware may be required if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware

requirements.

  • One computer with the following:
    • Dual-core or equivalent processor (Windows Vista / XP)
    • Quad-core or equivalent processor (Windows Longhorn Server / Server 2003)
    • 2 GB memory (Windows Vista / XP)
    • 6 GB memory (Windows Longhorn Server / Server 2003)
    • Logo-compliant ACPI BIOS, with ACPI enabled by default
    • One dual-channel ATA/ATAPI controller implemented on the motherboard
    • One IEEE 1394 host controller

  • One IEEE 1394 hard disk drive—the test device
  • One ATA/ATAPI hard disk drive from a different manufacturer than the test device, minimum 10 GB capacity
  • One ATA/ATAPI DMA-capable CD-ROM drive
  • One IEEE 1394 cable
  • Two standard ATA/ATAPI cables

Software requirements

The following software is required to run the IEEE 1394 Hard Disk Drive tests:

One of the following operating systems:

  • Microsoft Windows Vista
  • Microsoft Windows XP Professional with Service Pack 2 (SP2)
  • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
  • Microsoft Windows Server 2003, Datacenter Edition, with SP1
  • Microsoft Windows Server XP Professional x64 Edition
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows Server 2003, Datacenter x64 Edition
  • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
  • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems
  • Any drivers that are not shipped with the operating system
  • The current release of the Microsoft WDK

Tester knowledge requirements

To run the IEEE 1394 Hard Disk Drive tests, testers must know how to accomplish the following tasks:

  • Install an IEEE 1394 controller
  • Install a hard disk drive as a Device 0
  • Format and partition a hard disk
  • Install a CD-ROM drive as a stand-alone Device 0
  • Use Disk Management to convert a disk formatted with the GPT disk partitioning style to the MBR disk partitioning style
  • Install the operating system from the product CD


Preparing for IEEE 1394 Hard Disk Drive Testing

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see IEEE 1394 Hard Disk Drive Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, see [image] How to turn on automatic logon in Windows XP.

Test system configuration

The Microsoft Windows IEEE 1394 Hard Disk Drive logo program requires the following to prepare the test system for IEEE 1394 hard disk drive testing:

To configure the test system for IEEE 1394 hard disk drive testing

  1. Install the ATA/ATAPI hard disk drive as a stand-alone Device 0 on the primary ATA/ATAPI channel using a standard ATA/ATAPI cable.
  2. Install the ATA/ATAPI CD-ROM drive as a stand-alone Device 0 on the secondary ATA/ATAPI channel using a standard ATA/ATAPI cable.
  3. If the IEEE 1394 controller is not an embedded component, install one IEEE 1394 controller.
  4. Install the IEEE 1394 hard disk drive (test device) as a stand-alone device on the IEEE 1394 socket port 1 of the IEEE 1394 controller using an IEEE 1394 cable.
  5. Set the system BIOS to support the S3 state.
  6. Install the appropriate Microsoft Windows operating system on the ATA/ATAPI hard disk.
  7. If necessary, install any manufacturer-supplied drivers that are required by devices in the test system.
  8. Remove any partitions on the test device, and convert the test device to use the MBR partitioning style.
  9. If appropriate, enable auto logon functionality.
  10. Install the DTM client
  11. Configure the machine for testing in DTM Studio.
    1. Add the machine to a machine pool.
    2. Deploy the “WDK\ConfigureHardDiskDrive” dimension.


Running the IEEE 1394 Hard Disk Drive Tests

Open Device Console in DTM Studio.

Create a new submission for “Storage > Hard Drive”.

The test device should not require a driver. Please select “No Driver Files” when prompted.

Make sure to select the test Hard Disk Drive from the device list.

Select the tests which you wish to launch, choose Add Selected, and then click schedule.

1394 Configuration test

More Info:

1394 Interoperability test

More Info:

Data Verification Test

Input: This test accepts a single drive letter and a PNP ID as input. These are both provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

Note: This test reboots the system.

Storage Device Stress

Input: This test accepts a string of drive letters as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

More Info:

IFS Test

Input: This test accepts a single drive letter as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem. The test will reformat this partition and perform a series of operations.

WARNING: Any data saved on the test device will be lost.

Note: This test reboots the system.

More Info:

SyscacheTest

Input: This test accepts a single drive letter as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

More Info:

Sleep Stress with IO

More Info:

Disable Enable with IO

More Info:

Plug and Play Driver Test

More Info:

Stress Test

More Info:

Stress Test with low resource simulation

More Info:

Sleep Stress Disable Enable with IO

More Info:


Troubleshooting IEEE 1394 Hard Disk Drive Testing

For more information about troubleshooting IEEE 1394 hard disk drive testing, see Troubleshooting Storage Tests.


PC Card Hard Disk Drive Testing Overview

The procedures presented in this section outline the process for testing your PC Card Hard Disk Drive for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as requried for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

Using the Test Procedure Help Topics

The test procedures are divided into the following types of topics:

Overview: The overview topics describe the hardware, software, and tester knowledge requirements.

Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.

Running: The running topics describe how to run to run the tests for your device or system.

PC Card Hard Disk Drive Tests

The list of test you need to run depend upon the capabilities of the device or system being tested. The following is the complete list of tests that could be required for your test device:

CardBus Card Configuration Space Register test

CardBus Card Common Silicon Guidelines test

CardBus Bridge Power Management Register Test

Storage Data Verification Filter Test

Storage Device Stress test (SDStress)

Anti-Virus/File System Filter Test Kit

Syscache Test

System - Sleep Stress with IO

Disable Enable with IO

Plug and Play Driver Test

Stress Test

Core Stress Test

Run time: approximately 2 hours

Hardware requirements

The following hardware is required for PC Card Hard Disk Drive testing. Additional hardware may be required if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One computer with the following:
    • Dual-core or equivalent processor (Windows Vista / XP)
    • Quad-core or equivalent processor (Windows Longhorn Server / Server 2003)
    • 2 GB memory (Windows Vista / XP)
    • 6 GB memory (Windows Longhorn Server / Server 2003)
    • Logo-compliant ACPI BIOS, with ACPI enabled by default
    • Ultra direct memory access (UDMA)-capable ATA/ATAPI hard disk drive, minimum 10 GB capacity
    • One ATA/ATAPI CD-ROM drive, minimum 8x speed
    • Dual PC Card controllers
    • One monitor, one keyboard, and one mouse (or any pointing/drawing device)

  • Two PC Card hard disk drives (these are the test devices)
  • One PC Card network adapter

Software requirements

The following software is required to run the PC Card Hard Disk Drive tests:

One of the following operating systems:

  • Microsoft Windows Vista
  • Microsoft Windows XP Professional with Service Pack 2 (SP2)
  • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
  • Microsoft Windows Server 2003, Datacenter Edition, with SP1
  • Microsoft Windows Server XP Professional x64 Edition
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows Server 2003, Datacenter x64 Edition
  • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
  • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems
  • Any drivers that are not shipped with the operating system
  • The current release of the Microsoft WDK

Tester knowledge requirements

To run the PC Card Hard Disk Drive tests, testers must know how to accomplish the following tasks:

  • Format and partition a hard disk.
  • Install a PC Card hard disk drive.
  • Install a PC Card network adapter.
  • Install the operating system from the product CD


Preparing for PC Card Hard Disk Drive Testing

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see the PC Card Hard Disk Drive Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, see [image] How to turn on automatic logon in Windows XP.

Test system configuration

The PC Card Hard Disk Drive logo program requires the following to prepare the test system for PC Card hard disk drive testing:

To configure the system for PC Card hard disk drive testing

  1. Install one PC Card hard disk drive (test device) on the PC Card channel of the test system.
  2. Install the PC Card network adapter on the second PC Card controller in the test system.
  3. Set the system BIOS to support the S3.
  4. Install the appropriate Microsoft Windows operating system on the ATA/ATAPI hard disk in the test system.
  5. If necessary, install any manufacturer-supplied drivers required by devices in the test system.
  6. Remove any partitions on the test device, and convert the test device to use the MBR partitioning style.
  7. If appropriate, enable auto logon functionality.
  8. Install the DTM client
  9. Configure the machine for testing in DTM Studio.
    1. Add the machine to a machine pool.
    2. Deploy the “WDK\ConfigureHardDiskDrive” dimension.


Running the PC Card Hard Disk Drive Tests

Open Device Console in DTM Studio.

Create a new submission for “Storage > Hard Drive”.

The test device should not require a driver. Please select “No Driver Files” when prompted.

Make sure to select the test Hard Disk Drive from the device list.

Select the tests which you wish to launch, choose Add Selected, and then click schedule.

CardBus Card Common Silicon Guidelines

Note: Ensure that the CardBus card is installed during this test.

More Info:

CardBus Bridge Power Management Register

Note: Ensure that the CardBus card is installed during this test.

More Info:

CardBus Bridge Register

More Info:

Data Verification Test

Input: This test accepts a single drive letter and a PNP ID as input. These are both provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

Note: This test reboots the system.

Storage Device Stress

Input: This test accepts a string of drive letters as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

More Info:

IFS Test

Input: This test accepts a single drive letter as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem. The test will reformat this partition and perform a series of operations.

WARNING: Any data saved on the test device will be lost.

Note: This test reboots the system.

More Info:

SyscacheTest

Input: This test accepts a single drive letter as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

More Info:

Sleep Stress with IO

More Info:

Disable Enable with IO

More Info:

Plug and Play Driver Test

More Info:

Stress Test

More Info:

Stress Test with low resource simulation

More Info:

Sleep Stress Disable Enable with IO

More Info:


Troubleshooting PC Card Hard Disk Drive Testing

For more information about troubleshooting PC Card hard disk drive testing, see Troubleshooting Storage Tests.


SAS Hard Disk Drive Testing Overview

The procedures presented in this section outline the process for testing your SAS Hard Disk Drive for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as requried for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

Using the Test Procedure Help Topics

The test procedures are divided into the following types of topics:

Overview: The overview topics describe the hardware, software, and tester knowledge requirements.

Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.

Running: The running topics describe how to run to run the tests for your device or system.

SAS Hard Disk Drive Tests

The list of test you need to run depend upon the capabilities of the device or system being tested. The following is the complete list of tests that could be required for your test device:

Storage Data Verification Filter Test

SCSI Compliance test

Storage Device Stress test (SDStress)

Anti-Virus/File System Filter Test Kit

Syscache Test

System - Sleep Stress with IO

Disable Enable with IO

Plug and Play Driver Test

Stress Test

Core Stress Test

Run time: approximately 2 hours

Hardware requirements

The following hardware is required for SAS Hard Disk Drive testing. Additional hardware may be required if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One computer with the following:
    • Dual-core or equivalent processor (Windows Vista / XP)
    • Quad-core or equivalent processor (Windows Longhorn Server / Server 2003)
    • 2 GB memory (Windows Vista / XP)
    • 6 GB memory (Windows Longhorn Server / Server 2003)
    • Logo-compliant ACPI BIOS, with ACPI enabled by default

  • Two dual-ported SAS controllers
  • Two identical SAS hard disk drives—the test devices
  • One SCSI controller
  • One SCSI hard disk drives with a minimum capacity of 10 GB
  • One CD-ROM drive with a minimum speed of 8X

Software requirements

The following software is required to run the SAS Hard Disk Drive tests:

  • Microsoft Windows Vista
  • Microsoft Windows XP Professional with Service Pack 2 (SP2)
  • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
  • Microsoft Windows Server 2003, Datacenter Edition, with SP1
  • Microsoft Windows Server XP Professional x64 Edition
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows Server 2003, Datacenter x64 Edition
  • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
  • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems
  • Any drivers that are not shipped with the operating system
  • The current release of the Microsoft WDK

Tester knowledge requirements

To run the SAS Hard Disk Drive tests, testers must know how to accomplish the following tasks:

  • Install a hard disk drive
  • Install a CD-ROM drive
  • Install a SAS controller
  • Install a SAS hub
  • Format and partition a hard disk
  • Use Disk Management to create dynamic disks and mirrored volumes on a disk
  • Install the operating system from the product CD


Preparing for SAS Hard Disk Drive Testing

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see the SAS Hard Disk Drive Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, see [image] How to turn on automatic logon in Windows XP.

Test system configuration

The Serial Attached SCSI (SAS) Hard Disk Drive logo program requires the following to prepare the test system for testing the SAS hard disk drive.

To assemble the test system for SAS hard disk drive testing

Note: All adapters are operated with BIOS enabled and external termination, unless otherwise noted.

  1. If the test system does not contain a SCSI adapter, install the SCSI adapter.
  2. Install SCSI hard disk drive on the SCSI bus.
  3. Install the SCSI CD-ROM drive on the SCSI bus.
  4. Install two dual-ported SAS controllers.
  5. Connect one SAS hard disk drive to the SAS port.

To configure the test system for SAS hard disk drive testing

  1. Set the system BIOS to support the S3 state.
  2. Install the appropriate Microsoft Windows operating system on the SCSI hard disk drive.
  3. If necessary, install any manufacturer-supplied drivers that are required by devices in the test system.
  4. If appropriate, enable auto logon functionality.
  5. Restart the test system.
  6. Using the Windows Disk Management utility, delete all existing partitions on the SAS hard disk drives.
  7. Use the Windows Disk Management utility to make the SAS hard disk drives as dynamic disks. These disk drives are referred to as Drive 1 and Drive 2.
  8. Use the Windows Disk Management utility to create an NTFS mirrored volume that is larger than 10 GB on Drive 1 and Drive 2. Leave a minimum of 4 GB of free space on Drive 2.
  9. Install the DTM client
  10. Configure the machine for testing in DTM Studio.
    1. Add the machine to a machine pool.
    2. Deploy the “WDK\ConfigureHardDiskDrive” dimension.


Running the SAS Hard Disk Drive Tests

Open Device Console in DTM Studio.

Create a new submission for “Storage > Hard Drive”.

The test device should not require a driver. Please select “No Driver Files” when prompted.

Make sure to select the test Hard Disk Drive from the device list.

Select the tests which you wish to launch, choose Add Selected, and then click schedule.

Data Verification Test

Input: This test accepts a single drive letter and a PNP ID as input. These are both provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

Note: This test reboots the system.

SCSI Compliance

Input: This test accepts the physical path of the test device as input. This is provided automatically by DTM.

More Info:

Storage Device Stress

Input: This test accepts a string of drive letters as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

More Info:

IFS Test

Input: This test accepts a single drive letter as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem. The test will reformat this partition and perform a series of operations.

WARNING: Any data saved on the test device will be lost.

Note: This test reboots the system.

More Info:

SyscacheTest

Input: This test accepts a single drive letter as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

More Info:

Sleep Stress with IO

More Info:

Disable Enable with IO

More Info:

Plug and Play Driver Test

More Info:

Stress Test

More Info:

Stress Test with low resource simulation

More Info:

Sleep Stress Disable Enable with IO

More Info:


Troubleshooting SAS Hard Disk Drive Testing

For more information about troubleshooting SAS hard disk drive testing, see Troubleshooting Storage Tests.


SATA Hard Disk Drive Testing Overview

The procedures presented in this section outline the process for testing your Serial ATA (SATA) Hard Disk Drive for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as requried for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

Using the Test Procedure Help Topics

The test procedures are divided into the following types of topics:

Overview: The overview topics describe the hardware, software, and tester knowledge requirements.

Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.

Running: The running topics describe how to run to run the tests for your device or system.

SATA Hard Disk Drive Tests

The list of test you need to run depend upon the capabilities of the device or system being tested. The following is the complete list of tests that could be required for your test device:

Storage Data Verification Filter Test

SCSI Compliance test

Storage Device Stress test (SDStress)

Anti-Virus/File System Filter Test Kit

Syscache Test

System - Sleep Stress with IO

Disable Enable with IO

Plug and Play Driver Test

Stress Test

Core Stress Test

Run time: approximately 2 hours

Hardware requirements

The following hardware is required for SATA Hard Disk Drive testing. Additional hardware may be required if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One computer with the following:
    • Dual-core or equivalent processor (Windows Vista / XP)
    • Quad-core or equivalent processor (Windows Longhorn Server / Server 2003)
    • 2 GB memory (Windows Vista / XP)
    • 6 GB memory (Windows Longhorn Server / Server 2003)
    • Logo-compliant ACPI BIOS, with ACPI enabled by default

  • One Serial ATA controller with at least two channels
  • One ATA/ATAPI controller
  • One Serial ATA hard disk drive. This is the test device.
  • One ATA/ATAPI CD-ROM drive
  • One Serial ATA cable

Software requirements

The following software is required to run the SATA Hard Disk Drive tests:

One of the following operating systems:

  • Microsoft Windows Vista
  • Microsoft Windows XP Professional with Service Pack 2 (SP2)
  • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
  • Microsoft Windows Server 2003, Datacenter Edition, with SP1
  • Microsoft Windows Server XP Professional x64 Edition
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows Server 2003, Datacenter x64 Edition
  • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
  • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems
  • Any drivers that are not shipped with the operating system
  • The current release of the Microsoft WDK

Tester knowledge requirements

To run the SATA Hard Disk Drive tests, testers must know how to accomplish the following tasks:

  • Install the hard disk drive.
  • Install the CD-ROM drive as a stand-alone Device 0, a Device 1, or a cable-select Device 1.
  • Format and partition a hard disk.
  • Use DiskPart to convert a disk formatted with the GPT disk partitioning style to the MBR disk partitioning style. With 3 partitions: 20GB NTFS, 4GB NTFS, 4 GB NTFS.
  • Install the operating system from the product CD to the 20 GB partition.


Preparing for SATA Hard Disk Drive Testing

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see the SATA Hard Disk Drive Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, see [image] How to turn on automatic logon in Windows XP.

Test system configuration

The serial ATA hard disk drive logo program requires the following to prepare the test system for serial ATA hard disk drive testing:

To configure the test system for Serial ATA hard disk drive testing

  1. Install the CD-ROM drive as Drive 0 on an ATA/ATAPI controller.
  2. Install a serial ATA controller and attach two serial ATA hard disks. These hard disks are referred to as Drive 1 and Drive 2.
  3. Set the system BIOS to support the S3 state.
  4. Install the appropriate Microsoft Windows operating system on the test device.
    During installation, delete any existing partitions on Drive 1 and create 3 partitions: 20GB NTFS, 4GB NTFS, 4 GB NTFS.
  5. If necessary, install any drivers supplied by a manufacturer.
  6. Remove any partitions on the test device, and convert the test device to use the MBR partitioning style.
  7. If appropriate, enable auto logon functionality.
  8. Install the DTM client
  9. Configure the machine for testing in DTM Studio.
    1. Add the machine to a machine pool.
    2. Deploy the “WDK\ConfigureHardDiskDrive” dimension.


Running the SATA Hard Disk Drive Tests

Open Device Console in DTM Studio.

Create a new submission for “Storage > Hard Drive”.

The test device should not require a driver. Please select “No Driver Files” when prompted.

Make sure to select the test Hard Disk Drive from the device list.

Select the tests which you wish to launch, choose Add Selected, and then click schedule.

Data Verification Test

Input: This test accepts a single drive letter and a PNP ID as input. These are both provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

Note: This test reboots the system.

SCSI Compliance

Input: This test accepts the physical path of the test device as input. This is provided automatically by DTM.

More Info:

Storage Device Stress

Input: This test accepts a string of drive letters as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

More Info:

IFS Test

Input: This test accepts a single drive letter as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem. The test will reformat this partition and perform a series of operations.

WARNING: Any data saved on the test device will be lost.

Note: This test reboots the system.

More Info:

SyscacheTest

Input: This test accepts a single drive letter as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

More Info:

Sleep Stress with IO

More Info:

Disable Enable with IO

More Info:

Plug and Play Driver Test

More Info:

Stress Test

More Info:

Stress Test with low resource simulation

More Info:

Sleep Stress Disable Enable with IO

More Info:


Troubleshooting SATA Hard Disk Drive Testing

For more information about troubleshooting SATA hard disk drive testing, see Troubleshooting Storage Tests.


SCSI Hard Disk Drive Testing Overview

The procedures presented in this section outline the process for testing your SCSI Hard Disk Drive for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as requried for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

Using the Test Procedure Help Topics

The test procedures are divided into the following types of topics:

Overview: The overview topics describe the hardware, software, and tester knowledge requirements.

Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.

Running: The running topics describe how to run to run the tests for your device or system.

SCSI Hard Disk Drive Tests

The list of test you need to run depend upon the capabilities of the device or system being tested. The following is the complete list of tests that could be required for your test device:

Storage Data Verification Filter Test

SCSI Compliance test

Storage Device Stress test (SDStress)

Anti-Virus/File System Filter Test Kit

Syscache Test

System - Sleep Stress with IO

Disable Enable with IO

Plug and Play Driver Test

Stress Test

Core Stress Test

Run time: approximately 2 hours

Hardware requirements

The following hardware is required for SCSI Hard Disk Drive testing. Additional hardware may be required if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One computer with the following:
    • Dual-core or equivalent processor (Windows Vista / XP)
    • Quad-core or equivalent processor (Windows Longhorn Server / Server 2003)
    • 2 GB memory (Windows Vista / XP)
    • 6 GB memory (Windows Longhorn Server / Server 2003)
    • Logo-compliant ACPI BIOS, with ACPI enabled by default
    • One PCI bus
    • One floppy disk drive
    • One monitor, one keyboard, and one mouse (or any pointing/drawing device)

  • Two identical SCSI hard disk drives—the test devices
  • One SCSI adapter with appropriate bus interface for the test device, such as Narrow, Wide, or LVD
  • One bootable SCSI CD-ROM drive

Software requirements

The following software is required to run the SCSI Hard Disk Drive tests:

One of the following operating systems:

  • Microsoft Windows Vista
  • Microsoft Windows XP Professional with Service Pack 2 (SP2)
  • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
  • Microsoft Windows Server 2003, Datacenter Edition, with SP1
  • Microsoft Windows Server XP Professional x64 Edition
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows Server 2003, Datacenter x64 Edition
  • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
  • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems
  • Any drivers that are not shipped with the operating system
  • The current release of the Microsoft WDK

Tester knowledge requirements

To run the SCSI Hard Disk Drive tests, testers must know how to accomplish the following tasks:

  • Install a SCSI adapter with the BIOS enabled
  • Physically set the SCSI ID on a hard disk drive and a CD-ROM drive
  • Install a hard disk drive
  • Format and partition a hard disk
  • Install a CD-ROM drive
  • Use Disk Management to convert a disk formatted with the GPT disk partitioning style to the MBR disk partitioning style
  • Use Disk Management to create mirrored volumes on a disk
  • Install the operating system from the product CD


Preparing for SCSI Hard Disk Drive Testing

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see the SCSI Hard Disk Drive Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, see [image] How to turn on automatic logon in Windows XP.

Test system configuration

The SCSI Hard Disk Drive logo program requires the following to prepare the test system for testing the SCSI hard disk drive.

To assemble the test system for SCSI hard disk drive testing

Note: All adapters are operated with BIOS enabled and external termination unless otherwise noted.

  1. Set the SCSI IDs on the hard disk drives (test devices) as follows:
    Drive 1 = SCSI ID 0
    Drive 2 = SCSI ID 1
  2. Install the hard disk drives (test devices) on the SCSI adapter.
  3. Set the SCSI ID on the SCSI CD-ROM drive to 6, and then physically install the SCSI CD-ROM drive on the SCSI adapter on a separate channel than the test devices.

To configure the test system for SCSI hard disk drive testing

  1. Set the system BIOS to support the S3 state.
  2. Install the appropriate Microsoft Windows operating system on Drive 1.
    During installation, create one partition and format the partition with the NTFS file system.
  3. If necessary, install any manufacturer-supplied drivers required by devices in the test system.
  4. Remove any partitions on the test device, and convert the test device to use the MBR partitioning style.
  5. If appropriate, enable auto logon functionality.
  6. Install the DTM client
  7. Configure the machine for testing in DTM Studio.
    1. Add the machine to a machine pool.
    2. Deploy the “WDK\ConfigureHardDiskDrive” dimension.


Running the SCSI Hard Disk Drive Tests

Open Device Console in DTM Studio.

Create a new submission for “Storage > Hard Drive”.

The test device should not require a driver. Please select “No Driver Files” when prompted.

Make sure to select the test Hard Disk Drive from the device list.

Select the tests which you wish to launch, choose Add Selected, and then click schedule.

Data Verification Test

Input: This test accepts a single drive letter and a PNP ID as input. These are both provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

Note: This test reboots the system.

SCSI Compliance

Input: This test accepts the physical path of the test device as input. This is provided automatically by DTM.

More Info:

Storage Device Stress

Input: This test accepts a string of drive letters as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

More Info:

IFS Test

Input: This test accepts a single drive letter as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem. The test will reformat this partition and perform a series of operations.

WARNING: Any data saved on the test device will be lost.

Note: This test reboots the system.

More Info:

SyscacheTest

Input: This test accepts a single drive letter as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

More Info:

Sleep Stress with IO

More Info:

Disable Enable with IO

More Info:

Plug and Play Driver Test

More Info:

Stress Test

More Info:

Stress Test with low resource simulation

More Info:

Sleep Stress Disable Enable with IO

More Info:


Troubleshooting SCSI Hard Disk Drive Testing

For more information about troubleshooting SCSI hard disk drive testing, see Troubleshooting Storage Tests.


USB Hard Disk Drive Testing Overview

The procedures presented in this section outline the process for testing your USB Hard Disk Drive for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as requried for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

Using the Test Procedure Help Topics

The test procedures are divided into the following types of topics:

Overview: The overview topics describe the hardware, software, and tester knowledge requirements.

Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.

Running: The running topics describe how to run to run the tests for your device or system.

USB Hard Disk Drive Tests

The list of test you need to run depend upon the capabilities of the device or system being tested. The following is the complete list of tests that could be required for your test device:

USB Address Description Test

USB Descriptor Test

USB Device Control Requests

USB Device Framework

USB Enumeration Stress

USB Selective Suspend

USB Serial Number

USB Specification Compliance

Storage Data Verification Filter Test

Storage Device Stress test (SDStress)

Anti-Virus/File System Filter Test Kit

Syscache Test

System - Sleep Stress with IO

Disable Enable with IO

Plug and Play Driver Test

Stress Test

Core Stress Test

Run time: approximately 2 hours

Hardware requirements

The following hardware is required for USB Hard Disk Drive testing. Additional hardware may be required if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One computer with the following:
    • Dual-core or equivalent processor (Windows Vista / XP)
    • Quad-core or equivalent processor (Windows Longhorn Server / Server 2003)
    • 2 GB memory (Windows Vista / XP)
    • 6 GB memory (Windows Longhorn Server / Server 2003)
    • Logo-compliant ACPI BIOS, with ACPI enabled by default
    • Either a USB 2.0 host controller embedded on the system motherboard, or a USB 2.0 controller PCI adapter.
    • The USB controller must be able to wake the system using ACPI mechanisms.

  • Two identical USB hard disk drives - These are the test devices.
  • One UDMA-capable ATA/ATAPI hard disk drive, minimum 10 GB capacity
  • One ATA/ATAPI CD-ROM drive, minimum 8X speed
  • Two USB cables
  • Two standard ATA/ATAPI cables

    Note: ATA-66 and ATA-100 controllers require 80-conductor cables.

  • One USB 2.0 high-speed hub

Software requirements

The following software is required to run the USB Hard Disk Drive tests:

One of the following operating systems:

  • Microsoft Windows Vista
  • Microsoft Windows XP Professional with Service Pack 2 (SP2)
  • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
  • Microsoft Windows Server 2003, Datacenter Edition, with SP1
  • Microsoft Windows Server XP Professional x64 Edition
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows Server 2003, Datacenter x64 Edition
  • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
  • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems
  • Any drivers that are not shipped with the operating system
  • The current release of the Microsoft WDK

Tester knowledge requirements

To run the USB Hard Disk Drive tests, testers must know how to accomplish the following tasks:

  • Install a hard disk drive as a stand-alone Device 0.
  • Install a CD-ROM drive as a stand-alone Device 0.
  • Install a USB hard disk drive on a USB controller.
  • Format and partition a hard disk.
  • Install the operating system from the product CD


Preparing for USB Hard Disk Drive Testing

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see the USB Hard Disk Drive Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, see [image] How to turn on automatic logon in Windows XP.

Test system configuration

The USB Hard Disk Drive logo program requires the following to prepare the test system for USB hard disk drive testing:

To configure the test system for USB hard disk drive testing

  1. Physically install the ATA/ATAPI hard disk drive as a stand-alone Device 0 on the primary ATA/ATAPI channel using a standard ATA/ATAPI cable.
  2. Physically install the ATA/ATAPI CD-ROM drive as a stand-alone Device 0 on the secondary ATA/ATAPI channel using a standard ATA/ATAPI cable.
  3. If test system does not have an embedded USB 2.0 controller, install a USB 2.0 controller.
  4. Connect the USB 2.0 controller to the high-speed USB 2.0 hub.
  5. Connect the test device to the downstream port of the high-speed USB 2.0 hub.

    Note: Do not connect the USB test device directly to the root hub of the USB 2.0 controller.

  6. Set the system BIOS to support the S3 state.
  7. Install the appropriate operating system on the ATA/ATAPI hard disk drive.
  8. If necessary, install any manufacturer-supplied drivers required by devices in the test system.
  9. Remove any partitions on the test device, and convert the test device to use the MBR partitioning style.
  10. If appropriate, enable auto logon functionality.
  11. Install the DTM client
  12. Configure the machine for testing in DTM Studio.
    1. Add the machine to a machine pool.
    2. Deploy the “WDK\ConfigureHardDiskDrive” dimension.


Running the USB Hard Disk Drive Tests

Open Device Console in DTM Studio.

Create a new submission for “Storage > Hard Drive”.

The test device should not require a driver. Please select “No Driver Files” when prompted.

Make sure to select the test Hard Disk Drive from the device list.

Select the tests which you wish to launch, choose Add Selected, and then click schedule.

USB Address Description Test

More Info:

USB Descriptor Test

More Info:

USB Device Control Requests

More Info:

USB Device Framework

More Info:

USB Enumeration Stress

More Info:

USB Selective Suspend

More Info:

USB Serial Number

More Info:

USB Specification Compliance

More Info:

Data Verification Test

Input: This test accepts a single drive letter and a PNP ID as input. These are both provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

Note: This test reboots the system.

More Info:

Storage Device Stress

Input: This test accepts a string of drive letters as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

More Info:

IFS Test

Input: This test accepts a single drive letter as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem. The test will reformat this partition and perform a series of operations.

WARNING: Any data saved on the test device will be lost.

Note: This test reboots the system.

More Info:

SyscacheTest

Input: This test accepts a single drive letter as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

More Info:

Sleep Stress with IO

More Info:

Disable Enable with IO

More Info:

Plug and Play Driver Test

More Info:

Stress Test

More Info:

Stress Test with low resource simulation

More Info:

Sleep Stress Disable Enable with IO

More Info:


Troubleshooting USB Hard Disk Drive Testing

For more information about troubleshooting USB hard disk drive testing, see Troubleshooting Storage Tests.


Personal Audio Player Hard Drive Testing Overview

The procedures presented in this section outline the process for testing your Portable Media Device for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as required for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

Hardware requirements

The following hardware is required for Portable Media Device testing. Additional hardware may be required if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • 1 PC running Windows XPSP2 (Cell Phones) or Windows Vista (DSCs and Cell Phones) with an internal or external USB port connected. USB 2.0 is recommended.
  • Device with USB cable

Software requirements

The following software is required to run the Portable Media Device tests:

Digital Still Cameras:

No additional software is required, but your device must install with the Microsoft Media Transfer Protocol class driver. Your device must appear as “Portable Devices” in Device Manager in Windows Vista.

Cellular Handsets:

If your Operating System is Windows XPSP2, you need to download and install Windows Media Player 11 at <download link here once WMP11 is released>

You need to provide your Windows Portable Devices cellular phone driver. The driver INF file must install the device as a WPD class with the following ClassGuid:

Class=WPD

ClassGUID={EEC5AD98-8080-425f-922A-DABF3DE3F69A}

Your device must appear under the “Windows Portable Devices” (on XPSP2) or “Portable Devices” (on Vista) category in Device Manager.

Tester knowledge requirements

To run the Portable Media Device tests, testers must know how to accomplish the following tasks:

  1. Switch the device to a PC connectivity mode before plugging in.
  2. Plug in device to a USB port of the PC and maintain the connectivity throughout the test run.
  3. Provide continuous power to the device during the duration of the test run.
  4. Troubleshoot device installation, by checking if the device is installed successfully using Device Manager, or by looking at the SetupAPI device installation logs.

Run time: approximately <TBD> hours

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Preparing to test Personal Audio Player Hard Drives

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see the Portable Media Device Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, see Running with autologon enabled.

Test system configuration

Set the logo test dimension for the machine pool

  1. Switch to the Job Monitor window.
    You can also open a new Job Monitor window by clicking Explorers, and then clicking Job Monitor.
  2. In the Machine Pool tab of the Job Monitor window, right-click the machine pool that contains the computers whose dimensions you want to set for logo testing and select Properties.
  3. In the Machine Pool Properties dialog box, click the MCU Policy tab.
  4. Select the logo test dimensions Wdk\ConfigureCellularHandsetsPortableDevice and Wdk\ConfigureDigitalStillCameraPortableDevice in the Available Dimensions pane, and then click Add.

    The logo test dimension that you selected is shown in the Dimensions in Policy pane.
  5. Click Apply, and then click OK.


Testing Personal Audio Player Hard Drives

Running the Cellular Phone Logo Tests

  1. Connect a WPD Cellular Phone Device to the DTM Test Client Machine
  2. Install the WPD Cellular Phone Driver for this device
  3. From Device Console, locate this device in the "WPD" node on the left hand pane
  4. Select and run these jobs from the "Portable Media Device" -> "Cellular Handsets" Category

WPD Compliance Tests (WDK)

WPD Compliance Stress Tests (WDK)

USB Device Framework (CV)

USB HIDView (CV)

USB Specification Compliance

USB Selective Suspend

USB Enumeration Stress

USB Device Control Requests

USB Descriptor test

USB Address Description Test

USB Serial Number

Running the Cellular Phone Terminal Server Logo Tests

[TBD Vishalm]

Running the Digital Still Camera Logo Tests

  1. Connect a PTP or MTP camera to the DTM Test Client Machine
  2. Once the DSC shows up in device manager, locate this device in the “WPD” node on the left hand pane.
  3. Select and run these jobs from the “Portable Media Device” -> “DSC” category depending on the logo the device is applying for either Gold or Silver.
    • MTP Camera or Camcorder [Gold Logo] Mtp Test
    • PTP Camera or Camcorder [Silver Logo] Mtp Test


Troubleshooting Personal Audio Player Hard Drives

Troubleshooting the Cellular Handset Logo Tests

If the tests do not run after being scheduled:

The tests require the following constaint before they can be run:

WPD\PortableDeviceType Exists

To enable this, you need to apply the Wdk\ConfigureCellularHandsetsPortableDevice dimension on your test machine pool [described in the “Test System Configuration” section]. On XPSP2 systems, you also need to install Windows Media Player 11 before running the tests [described in the “Software Requirements” section].

If many tests start to fail after some time, especially when running the Stress test, check that the device has not gone into a bad state:

  1. Device is still connected to the test machine and powered on
  2. Device node is still visible in Device Manager
  3. Browse device contents in My Computer by viewing objects or files in the device storage. If device hangs or stops responding, the driver/device may have gone into a bad state.
  4. If the device has gone into a persistent bad state, then reset the device or remove and insert the batteries.

Troubleshooting the Digital Still Camera Logo Tests

This is how the tests are run manually:

  1. Plug the device under test
  2. PreRun: mtpinfup.exe, it will update/disable the inbox driver to a test driver and then generate an xml file which contains the list of active devices. Place that xml file in the same folder as MtpTest binaries if mtpinfup.exe was run from a different folder. After the previous step, the in box driver will not be able to talk the device now; mtp test will be talking with the device.
  3. Run MtpTest, select and run the test cases
  4. PostRun: "mtpinfup.exe /post" to return back to the original setup so that test driver is updated to inbox driver and the in box driver can talk to the device now. (i.e., device contents can be browsed in “Computer”

Notes:

  1. Some devices need to be plugged out and plugged back in every time the driver (INF file) has been updated.
  2. If the device has gone into a persistent bad state, then reset the device or remove and insert the batteries.
  3. Updating drivers require admin privileges.


Storage > Media Changer Device Testing Overview

The procedures presented in this section outline the process for testing your Medium Changer for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as requried for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

Media Changer Tests

The list of test you need to run depend upon the capabilities of the device or system being tested. To see the complete list of tests that could be required for your device, see the Medium Changer Tests

Medium Changer Test

Medium changer stress

Device Path Exerciser

System - Sleep Stress with IO

Disable Enable with IO

Plug and Play Driver Test

Storage Device Stress test (SDStress)

Core Stress Test

System - Sleep Stress with IO

If your device uses a Tape Drive:

Tape I/O Test

If testing in Windows XP / Server 2003:

NTBackup test

If your device uses an Optical drive:

MMC Test

Media Lock Test

Storage Device Stress test (SDStress)

If the drive is writable:

UDF Formatter Tests

If your device connects via iSCSI:

iSCSI iSNS Compliance Test

iSCSI Mutual CHAP (Target)

iSCSI Oneway CHAP (Target)

iSCSI Ping Test (Target)

If your device uses a Tape Drive:

iSCSI Digest - Tape (Target)

If you are submitting a driver:

Driver Verifier

Prefast for Drivers

Static Driver Verifier

Run Inf Test against a single INF

If your device is connected via 1394:

1394 Configuration Tests

If your device is connected via Cardbus:

CardBus Card Configuration Space Register test

CardBus Card Common Silicon Guidelines test

CardBus Bridge Power Management Register Test

If your device is connected via USB:

USB Address Description

USB Descriptor Test

USB Device Control Requests

USB Device Framework (CV)

USB Enumeration Stress

USB HIDView (CV)

USB Selective Suspend

USB Serial Number

USB Specification Compliance

Run time: approximately 24-72 hours

Hardware requirements

The following hardware is required for Medium Changer testing. Additional hardware may be required if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One test system with the following:
    • Dual-core or equivalent processor (Windows Vista / XP)
    • Quad-core or equivalent processor (Windows Longhorn Server / Server 2003)
    • 2 GB memory (Windows Vista / XP)
    • 6 GB memory (Windows Longhorn Server / Server 2003)
    • A PCI bus
    • A Logo-compliant ACPI BIOS, with ACPI enabled by default

      • Note: For Windows Vista / XP Professional on a desktop system, the test system must support the S3 and S4 sleep states. For Windows Vista / XP Professional on a mobile system, the test system must support the S4 sleep state and either the S1 or S3 sleep state. For Windows Longhorn Server / Server 2003, the test system must support the S4 sleep state.

  • One CD-ROM drive
  • One hard disk drive
  • One bootable controller for the same bus used by the CD-ROM drive and the hard disk drive
  • One Storage adapter of the same bus type as the medium changer. If you are testing an iSCSI Medium changer, this should be a Gigabit Ethernet NIC.
  • One iSCSI, SCSI, SAS, or Fibre Channel medium changer, the test device. The medium changer must have the following characteristics:
    • One frame or module
    • At least ¼ of the drives must be installed. If this is less than 4 than 4 drives should be installed. If the medium changer supports less than 4 drives, all drives should be installed.

  • One tenth the supported capacity in media is required. If this is less than 20, then 20 pieces of media are required. If the medium changer’s capacity is less than 20, the supported capacity in media is required.
  • One cleaning cartridge.

Software requirements

The following software is required to run the Medium Changer tests:

  • One of the following operating systems:
    • Microsoft Windows Vista
    • Microsoft Windows XP Professional with Service Pack 2 (SP2)
    • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
    • Microsoft Windows Server 2003, Datacenter Edition, with SP
    • Microsoft Windows Server XP Professional x64 Edition
    • Microsoft Windows Server 2003, Enterprise x64 Edition
    • Microsoft Windows Server 2003, Datacenter x64 Edition
    • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
    • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems

  • Any drivers that are not shipped with the operating system
  • The current release of Microsoft WDK
  • If testing an iSCSI Medium Changer
    • The latest version of the Microsoft iSCSI software initiator.
      To download the iSCSI software initiator, search for “iSCSI software initiator” at the [image] Microsoft Download Center
    • The latest version of the Microsoft iSNS server.
      To download the Microsoft iSNS server, search for “iSNS” at the [image] Microsoft Download Center
    • The Microsoft .NET Framework Version 1.1, which is available from the [image] Microsoft Download Center

Tester knowledge requirements

To run the Medium Changer tests, testers must know how to accomplish the following tasks:

  • Install medium changer software.
  • Install the Removable Storage Manager (Windows Vista / Longhorn Server)
  • Configure the Removable Storage Manager.
  • Read test logs and event logs.
  • Report bugs in a standard bug format.
  • Format and partition a hard disk drive.
  • Install the appropriate Windows operating system from the product CD.
  • Install DTM Client.
  • Launch tests from DTM Studio’s Device Console (Submission mode).
  • If testing an iSCSI Medium Changer:
    • Set up an iSCSI environment and record the IP addresses and target names of the devices
    • Set the secret for oneway and mutual CHAP (if supported)
    • Configure an iSCSI tape drive to use an iSNS server
    • Log on to an iSCSI target device
    • Install the operating system from the product CD.
    • Download and install Microsoft iSCSI software initiator, Microsoft iSNS server, and Microsoft .NET Framework Version 1.1.

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Preparing to Test Media Changer Devices

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see the Medium Changer Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, see Running with autologon enabled.

Test system configuration

  1. Install the appropriate Microsoft Windows operating system.
  2. Install the test device and any accessories.
    • If your drive connects via iSCSI:

    1. Connect your device to the Gigabit Ethernet Adapter.

    • If your drive connects via USB:

    1. Connect the USB 2.0 controller to the High Speed USB 2.0 hub.
    2. Connect the test device to the downstream port of the high-speed USB 2.0 hub.

  3. Install the device driver that is supplied by the manufacturer, if necessary.
    • If your drive connects via iSCSI:
      1. Configure your device through the Microsoft iSCSI Initiator.
      2. Configure the target device to use Challenge Handshake Authentication Protocol (CHAP). You must configure the device to use oneway (target authenticates initiator) CHAP. If your device supports mutual CHAP, also configure the device to use mutual CHAP.

        Note: When you configure the device to use CHAP, you must provide a secret that is between 12 and 16 characters long. If you are configuring the device to use both oneway CHAP and mutual CHAP, you must provide different secrets for the target and the initiator.

      3. Log on to the target tape drive.

        Important: You must be logged on to the iSCSI target device that is used for testing, or the Logo tests will not work properly.

      4. Install the iSNS software on the test system, and configure the target to use the iSNS server.
      5. If your device supports digest and you are required to configure it, configure the test device to support digest.

    • If the medium changer is not configured automatically after the operating system and device drivers are installed, then configure it manually. Refer to the articles on [image] Microsoft Support for instructions about how to configure the medium changer manually.
    • (Windows Vista / Longhorn Server) Install Removable Storage Manager.
    • Insert all of the required media, including the cleaning cartridge, into the medium changer. See Hardware Requirements for the amount of media necessary.
    • Use the following procedure to mount the media:
      1. Open the start menu and click Run
      2. Type “compmgmt.msc” and click enter.
      3. If a dialog box appears asking your permission to run the program, click Allow.
      4. In left pane of the Computer Management window, expand Storage, and then click Removable Storage. If you do not see Removable Storage please see step 5.
      5. If you are testing with Microsoft Windows XP, on the View menu, click Full.
      6. In left pane of the Computer Management window, expand Removable Storage, expand Media Pools, and then expand Free, Import, and Unrecognized.
      7. Move each piece of media into the Free pool by selecting the media in either the Import or Unrecognized pool, and dragging it to the Free pool.
      8. Mount media on each drive in the test device by right-clicking a piece of media that is listed in the Free pool, and then clicking Mount. Repeat this step for each drive.

    • Install DTM Client.
    • Configure the machine for testing in DTM Studio.
      1. Add the machine to a machine pool. LINK TO COMMON DTM DOC
      2. Deploy the “WDK\ConfigurationMediumChanger” dimension. LINK TO COMMON DTM DOC


Testing Media Changer Devices

Open Device Console in DTM Studio.

Create a new submission for “Storage > Medium Changer Device”. LINK TO COMMON DTM DOC

During the submission make sure to load the same driver you installed on the system in step 3 of Test system configuration.

If you are not loading a driver, make sure to select both the Medium Changer under the Medium Changers node in the device list and either the Tape Drive under the Tape Drives Node or the Optical Drive under the DVD/CD-ROM Drives node.

When scheduling jobs take care in which device they are scheduled against.

To schedule jobs against a particular device, select that device in the left pane of device console then select the tests which you wish to launch, choose Add Selected.

Jobs in the Tape Drive or iSCSI Device category should be scheduled on the Tape Drive when applicable.

Jobs in the CD-DVD Drives category should be scheduled on the Optical Drive when applicable.

All other jobs should be scheduled on the Medium Changer Device.

When you are ready to run the jobs, click schedule.

Important: MMC Test, Media Lock Test, and UDF Formatter Test require manual user intervention. Please schedule these tests alone and proceed to the test console after scheduling.

Important: All the iSCSI tests require a configuration file to setup the communication between the HBA (Initiator) and the iSCSI targets. This information includes the CHAP Username, target secret to Logon on to the target, the target name, target IP address, HBA PNPID, etc. This information must be entered in a UI at the time of scheduling the job. This UI will generate the configuration file, which is copied to the client machine during each job. The following screen shot shows the extension UI:

Medium Changer Test

Setup:

This test requires that media is inserted in the drive (see steps 6 & 7 of Test System Configuration).

More Info:

LINK TO TEST DOC

Medium Changer Stress

Input:

This test requires the medium changer drive number as input. This is provided automatically by DTM.

More Info:

LINK TO TEST DOC

DR - Device Path Exerciser

More Info:

LINK TO TEST DOC

DR - Sleep Stress with IO

More Info:

LINK TO TEST DOC

DR - Disable Enable with IO

More Info:

LINK TO TEST DOC

DR - Plug and Play Driver Test

More Info:

LINK TO TEST DOC

DR - Stress Test

More Info:

LINK TO TEST DOC

DR - Stress Test with low resource simulation

More Info:

LINK TO TEST DOC

DR - Sleep Stress Disable Enable with IO

More Info:

LINK TO TEST DOC

Tape I/O

Note: This test will only appear if your device uses a tape drive.

Input:

This test requires the tape drive number as input. This is provided automatically by DTM.

Setup:

This test requires that media is inserted in the drive (see steps 6 & 7 of Test System Configuration).

More Info:

LINK TO TEST DOC

NTBackup

Note: This test will only appear if your device uses a tape drive and you are testing in Windows XP / Server 2003.

Input:

This test requires the tape drive number as input. This is provided automatically by DTM.

Setup:

This test requires that media is inserted in the drive (see steps 6 & 7 of Test System Configuration).

More Info:

LINK TO TEST DOC

MMC Test

Note: This test will only appear if your device uses an optical drive.

More Info:

LINK TO TEST DOC

Media Lock Test

Note: This test will only appear if your device uses an optical drive.

More Info:

LINK TO TEST DOC

Storage Device Stress

Note: This test will only appear if your device uses an optical drive.

More Info:

LINK TO TEST DOC

UDF Formatter Test

Note: This test will only appear if your device uses an optical drive.

More Info:

LINK TO TEST DOC

iSCSI Target iSNS Test

Note: This test will only appear if your device is connected via iSCSI.

More Info:

LINK TO TEST DOC

iSCSI Target Mutual CHAP Test

Note: This test will only appear if your device is connected via iSCSI.

More Info:

LINK TO TEST DOC

iSCSI Target Oneway CHAP Test

Note: This test will only appear if your device is connected via iSCSI.

More Info:

LINK TO TEST DOC

iSCSI Target Ping Test

Note: This test will only appear if your device is connected via iSCSI.

More Info:

LINK TO TEST DOC

iSCSI Target Digest Test (Tape)

Note: This test will only appear if your device uses a tape drive and is connected via iSCSI.

More Info:

LINK TO TEST DOC

DR - Driver Verifier

Note: This test will only appear if you load a driver.

More Info:

LINK TO TEST DOC

DR - Prefast for Drivers Test

Note: This test will only appear if you load a driver.

More Info:

LINK TO TEST DOC

DR - Static Driver Verifier Test

Note: This test will only appear if you load a driver.

More Info:

LINK TO TEST DOC

Run Inf Test against a single INF

Note: This test will only appear if you load a driver.

More Info:

LINK TO TEST DOC

1394 Configuration Tests

Note: This test will only appear if your device is connected via 1394.

More Info:

LINK TO TEST DOC

CardBus Card Configuration Space Register

Note: This test will only appear if your device is connected via CardBus.

Precaution: Please remove all other CardBus cards before running this test.

More Info:

LINK TO TEST DOC

CardBus Card Common Silicon Guidelines

Note: This test will only appear if your device is connected via CardBus.

Precaution: Please remove all other CardBus cards before running this test.

More Info:

LINK TO TEST DOC

CardBus Bridge Power Management Register

Note: This test will only appear if your device is connected via CardBus.

Precaution: Please remove all other CardBus cards before running this test.

More Info:

LINK TO TEST DOC

USB Address Description

Note: This test will only appear if your device is connected via USB.

More Info:

LINK TO TEST DOC

USB Descriptor Test

Note: This test will only appear if your device is connected via USB.

More Info:

LINK TO TEST DOC

USB Device Control Requests

Note: This test will only appear if your device is connected via USB.

More Info:

LINK TO TEST DOC

USB Device Framework (CV)

Note: This test will only appear if your device is connected via USB.

More Info:

LINK TO TEST DOC

USB Enumeration Stress

Note: This test will only appear if your device is connected via USB.

More Info:

LINK TO TEST DOC

USB HIDView (CV)

Note: This test will only appear if your device is connected via USB.

More Info:

LINK TO TEST DOC

USB Selective Suspend

Note: This test will only appear if your device is connected via USB.

More Info:

LINK TO TEST DOC

USB Serial Number

Note: This test will only appear if your device is connected via USB.

More Info:

LINK TO TEST DOC

USB Specification Compliance

Note: This test will only appear if your device is connected via USB.

More Info:

LINK TO TEST DOC


Troubleshooting Medium Changer Testing

  • Before you create a submission make sure your client is in Ready Mode. If it is not, right click the machine and choose Change Status > Reset.
  • If you plug in your device and it does not appear in DTM Studio try clicking the refresh button in Device Console before creating a submission. If the device still does not appear, try restarting the client machine.
  • If jobs are not getting your devices parameters check the following:
    • Right click on your device and choose View Device XML.
    • Look for a section at the bottom with the name StorageDevice.
    • If this is missing please ensure that you have done step 9 of Test System Configuration.
    • If the StorageDevice section appears, check that the job is getting the correct parameters:
      • Right click on the job in Job Monitor’s Job Execution Status pane.
      • Choose View Result Report.
      • Check the Effective Parameters section at the bottom of the report.
      • If the parameters are incorrect you may have associated the wrong device with the submission, the device may be installed incorrectly, or the installed driver may be wrong.
      • If this is empty your submission may be invalid.
      • Create a new submission and launch the test again.
      • If the parameters are still empty your client installation may be corrupt.
      • Delete the machine from the machine pool, uninstall the client then repeat steps 8 & 9 of Test System Configuration.

  • If jobs are appearing incorrectly.
    • Right click on your device and choose View Device XML.
    • Look for a section at the bottom with the name StorageDevice.
    • If this is missing please ensure that you have done step 9 of Test System Configuration.
    • If the information inside this section appears incorrect, please insure that your device is properly installed with the correct driver.

For more information about troubleshooting Media Chanager Device testing, see Troubleshooting Storage Tests.


Storage > RAID Testing

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


iSCSI Bridge RAID Testing Overview

The procedures presented in this section outline the process for testing your iSCSI Bridge for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as requried for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

iSCSI Bridge Tests

The list of test you need to run depend upon the capabilities of the device or system being tested. The following is the complete list of tests that could be required for your test device:

iSCSI Digest - Disk (Target)

Storage Data Verification Filter Test

iSCSI Digest - Tape (Target)

iSCSI iSNS Compliance Test

iSCSI Mutual CHAP (Target)

iSCSI Oneway CHAP (Target)

iSCSI Ping Test (Target)

NTBackup test

Storage Device Stress test (SDStress)

Core Stress Test

System - Sleep Stress with IO

Run time: approximately 2 hours

Hardware requirements

The following hardware is required for iSCSI Bridge testing. Additional hardware may be required if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One computer with the following:
    • Dual-core or equivalent processor (Windows Vista / XP)
    • Quad-core or equivalent processor (Windows Longhorn Server / Server 2003)
    • 2 GB memory (Windows Vista / XP)
    • 6 GB memory (Windows Longhorn Server / Server 2003)
    • Logo-compliant ACPI BIOS, with ACPI enabled by default

  • An iSCSI bridge (the test device).
  • An iSCSI disk storage system for the protocol that the bridge connects to.
  • An iSCSI media changer for the protocol that the bridge connects to, if the bridge supports media changers.
  • One 1-GBit (gigabit) Ethernet adapter.
  • A monitor, a keyboard, and a mouse.

Software requirements

The following software is required to run the iSCSI Bridge tests:

One of the following operating systems:

  • Microsoft Windows Vista
  • Microsoft Windows XP Professional with Service Pack 2 (SP2)
  • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
  • Microsoft Windows Server 2003, Datacenter Edition, with SP1
  • Microsoft Windows Server XP Professional x64 Edition
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows Server 2003, Datacenter x64 Edition
  • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
  • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems
  • Any drivers that are not shipped with the operating system
  • The current release of the Microsoft WDK

Tester knowledge requirements

To run the iSCSI Bridge tests, testers must know how to accomplish the following tasks:

  • Set up an iSCSI environment and record the Internet Protocol (IP) addresses and target names of the devices
  • Set the secret for oneway and mutual CHAP (if supported)
  • Configure an iSCSI target device to use an iSNS server
  • Log on to an iSCSI target device
  • Format and partition a hard disk
  • Install the operating system from the product CD

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Preparing to Test iSCSI Bridge Devices

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see the iSCSI Bridge Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, see Running with autologon enabled.

Test system configuration

Follow the procedure below to configure the test system to run the iSCSI bridge logo tests.

To assemble the test system for iSCSI bridge testing

  1. Connect the test system to an existing gigabit network.
  2. Connect the iSCSI bridge to the network.
  3. Connect the iSCSI disk storage system to the network.
  4. Connect the iSCSI media changer to the iSCSI bridge, if the bridge supports media changers.

To configure the test system for iSCSI bridge testing

  1. Turn on the test system.
  2. Install the Microsoft Windows operating system on the hard disk.
  3. If necessary, install any manufacturer-supplied drivers required by devices in the test system.
  4. Download and install the [image] Microsoft .NET Framework Version 1.1.
  5. Configure at least one of the target devices to use Challenge Handshake Authentication Protocol (CHAP). You must configure at least one target device to use oneway (target authenticates initiator) CHAP. If the bridge supports mutual CHAP, also configure at least one target device to use mutual CHAP.

    6. Note When you configure a device to use CHAP, you must provide a secret that is between 12 and 16 characters long. If you are configuring a device to use both oneway CHAP and mutual CHAP, you must provide different secrets for the target and the initiator.

  6. Log on to all target devices behind the bridge that you are testing.

    7. Important You must be logged on to the iSCSI target devices that are used for testing, or the logo tests will not work properly.

  7. Use Configuration Manager to create two NTFS volumes and one FAT 32 volume on the disk storage system. Assign the drive letters X and Y to the NTFS volumes. Assign the drive letter Z to the FAT 32 volume. The NTFS volumes must be larger than 2 GB and smaller than 4 GB. The FAT 32 volume must be smaller than 4 GB.
  8. Install the iSNS software on the test system, and configure the targets to use the iSNS server.
  9. If your device supports digest and you are required to configure it, configure the test device to support digest.
  10. Install the DTM client
  11. Configure the machine for testing in DTM Studio.
    1. Add the machine to a machine pool.
    2. Deploy the “WDK\ConfigureiScsiBridgeRaidStorage” dimension.


Testing iSCSI Bridge Devices

  1. Select all the devices behind the bridge in the logo submission
  2. Schedule all the jobs listed in the device console for this submission
  3. For iSCSI target tests: The configuration UI will pop up when the jobs are scheduled.
    • Fill the configuration UI
    • Save the configuration data
    • Schedule the job

Disk iSCSI Target Digest Test

More Info:

Data Verification Test

More Info:

iSCSI Target Digest Test

More Info:

iSCSI Target iSNS Test

More Info:

iSCSI Target Mutual CHAP Test

More Info:

iSCSI Target Oneway CHAP Test

More Info:

iSCSI Target Ping Test

More Info:

NTBackup Test

More Info:

Storage Device Stress

More Info:

Stress Test

More Info:

Stress Test with low resource simulation

More Info:

Sleep Stress Disable Enable with IO

More Info:


Troubleshooting iSCSI Bridge Testing

For information about troubleshooting iSCSI Bridge testing, see Troubleshooting Storage Tests


Storage > RAID > Hardware-based RAID Testing

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Fibre Channel Hardware-based RAID Systems Testing Overview

The procedures presented in this section outline the process for testing your Hardware Based RAID System > Fibre Channel for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as required for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

Hardware Based RAID System > Fibre Channel Tests

The list of test you need to run depend upon the capabilities of the device or system being tested. To see the complete list of tests that could be required for your device, see the Hardware Based RAID System > Fibre Channel Tests.

Crashdump Support Test

Storage Data Verification Filter Test

Anti-Virus/File System Filter Test Kit

SCSI Compliance test

Storage Device Stress test (SDStress)

Syscache Test

Device Path Exerciser

System - Sleep Stress with IO

Disable Enable with IO

Plug and Play Driver Test

DR - Stress Test

Core Stress Test

System - Sleep Stress with IO

If your device supports MPIO and testing in Windows Vista / Longhorn Server:

Multi-Path I/O Test

If you are submitting a driver:

Driver Verifier

Prefast for Drivers

Static Driver Verifier

Run Inf Test against a single INF

If your device supports VDS in hardware / driver:

VDSHW-PCI

If your device supports VSS in hardware / driver:

VSSHW-PCI

Run time: approximately 96 hours

Hardware requirements

The following hardware is required for Hardware Based RAID System > Fibre Channel testing. Additional hardware may be required if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One computer with the following:
    • Dual-core or equivalent processor (Windows Vista / XP)
    • Quad-core or equivalent processor (Windows Longhorn Server / Server 2003)
    • 2 GB memory (Windows Vista / XP)
    • 6 GB memory (Windows Longhorn Server / Server 2003
    • Logo-compliant ACPI BIOS, with ACPI enabled by default

  • One Fibre Channel RAID storage system. This is the test device.

    Note: The RAID system must be either a single cabinet that consists of an array controller enclosed in an external subsystem with hard disk drives, or an external array controller that connects to a RAID JBOD. The RAID system may not consist of only a PCI-based controller and one RAID JBOD.

  • One PCI-based Fibre Channel host bus adapter (HBA). Two HBAs are required if the test system supports multi-path.

    Note: The PCI-based HBA that is selected to test the RAID system should be supported by the manufacturer for use with the RAID system. Any drivers for the HBA that are used on the test system for this HBA must be have received a “Designed for Windows” logo, and the HBA model must be included in the Windows Catalog.

  • One bootable ATA or SCSI hard disk drive is required if the RAID system does not support boot. This drive must have a minimum capacity of 18 GB.
  • One set of cables, for the appropriate bus, for each HBA.

    Note: All hardware (except the test device, monitor, keyboard, mouse and the floppy disk drive) must be listed in the Windows Catalog.

Software requirements

The following software is required to run the Hardware Based RAID System > Fibre Channel tests:

  • One of the following operating systems:
    • Microsoft Windows Vista
    • Microsoft Windows XP Professional with Service Pack 2 (SP2)
    • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
    • Microsoft Windows Server 2003, Datacenter Edition, with SP1
    • Microsoft Windows Server XP Professional x64 Edition
    • Microsoft Windows Server 2003, Enterprise x64 Edition
    • Microsoft Windows Server 2003, Datacenter x64 Edition
    • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
    • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems

  • Any drivers that are not shipped with the operating system
  • he current release of Microsoft WDK
  • Microsoft Windows Symbol files [image] Windows Symbol Files

Tester knowledge requirements

To run the Hardware Based RAID System > Fibre Channel tests, testers must know how to accomplish the following tasks:

  • Access and change system BIOS settings
  • Install SCSI and ATA hard disk drives
  • Install a RAID system
  • Configure a RAID array
  • Identify the operating system version and install correct Microsoft Windows Symbol files
  • Install the operating system from the product CD
  • Read test logs
  • Report bugs in the standard format

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Preparing to Test Fibre Channel Hardware-Based RAID Systems

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see the Hardware Based RAID System > Fibre Channel Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, see Running with autologon enabled.

Test system configuration

  1. Configure the RAID system by using the RAID system operator panel, by using the command-line interface, or by connecting another system to the RAID system and running the configuration utility.
    1. All RAID devices are only required to support one RAID level: either RAID 5, RAID 1, or RAID 0. If your RAID system supports more than one RAID level you must test all RAID levels that the device supports.
    2. Create three 40-GB RAID arrays on the raid system. Configure the arrays according to the following table:
      3. If the test device supports these RAID levels… | … then configure RAID array 1 to use RAID level… | … and configure RAID array 2 to use RAID level… | … and configure RAID array 3 to use RAID level…
0 only | 0 | 0 | 0
1 only | 1 | 1 | 1
5 only | 5 | 5 | 5
0 and 1 only | 1 | 1 | 0
0 and 5 only | 5 | 5 | 0
1 and 5 only | 5 | 5 | 1
0, 1, and 5 | 5 | 1 | 0
    3. If the HBA you are using to test the RAID system is bootable, and the RAID system supports boot, then you must also create another 20 GB partition.

  2. Turn off the test system.
  3. Install one Fibre Channel HBA in the test computer system and connect it to the RAID system by using the appropriate cables for the bus.

    4. Note: If the test RAID system supports more than one bus protocol, then you must test and submit your device for a Designed For Windows logo once with each protocol that you want to have it qualified for.

    Note: The PCI-based HBA that is selected to test the RAID system should be supported for use with the RAID system by the manufacturer of the RAID system. Any drivers that are used on the test system for this HBA must be signed by WHQL and the HBA model and firmware version must be included in the Windows Catalog.

  4. If the RAID system supports multipath drivers, install a second, identical HBA in the test system and connect it to the RAID system by using the appropriate cables for the bus.
  5. If the HBA you are using to test the RAID system is bootable, and the RAID system supports boot, then:
    1. Install any HBA or RAID system drivers, including multi-path drivers that are necessary to connect to or manage the test device.
    2. Format the 20 GB NTFS partition created in 1.4 and install the appropriate operating system onto this partition.

  6. If the HBA you are using to test the RAID system is not bootable, or if the RAID system does not support boot, then:
    1. Install the alternate boot controller on the test system.
    2. Connect a hard disk drive to an alternate boot controller on the test system.
    3. Install any drivers necessary for the alternate boot controller.
    4. Install the appropriate operating system onto a 20 GB NTFS partition on the hard disk drive.
    5. Install any HBA or RAID system drivers, including multi-path drivers that are necessary to connect to or manage the peripheral devices.

  7. At this point you should have the system installed and booting to the test OS.
  8. From the Start menu, right-click My Computer, and then select Properties.
  9. Note the amount of RAM that the computer has.
  10. If the test OS is Windows Vista or Windows Longhorn Server, click Advanced System Settings. You may be required to enter Administrative credentials and / or allow the action. Please do so.
  11. On the Advanced tab of the System Properties dialog box, click Settings in the Performance area.
  12. On the Advanced tab of the Performance Options dialog box, click Change in the Virtual Memory area.
  13. Click Custom Size, and in the Initial Size box, enter a number that is larger than the size of the RAM you noted in step 9.

    14. Note: You specify the size of the page file in megabytes (MB). If the amount of RAM on your computer was specified by using gigabytes (GB) or some other measure, convert the amount of RAM to MB before choosing and entering a value for the page file size.

  14. Enter a Maximum Size value that is larger than the initial size. (It is common for the maximum size to be 1.5 to 2 times the initial size.)
  15. Click Set.
  16. Click OK to close the Virtual Memory dialog box.
  17. Click OK to close the Performance Options dialog box.
  18. On the Advanced tab of the System Properties dialog box, click Settings in the Startup and Recovery area.
    1. If the HBA selected for testing the RAID system is bootable and the RAID system supports boot, then, in the Write debugging information area of the Startup and Recovery dialog box, select Small memory dump (64 KB), and then type X:\Minidump in the Small dump directory box, where X is the drive letter of the RAID partition.
    2. If the HBA selected for testing the RAID system is not bootable, or if the RAID system does not support boot, then, in the Write debugging information area of the Startup and Recovery dialog box, select Small memory dump (64 KB), and then type X:\Minidump in the Small dump directory box, where X is the drive letter of a hard disk drive that is connected to an alternate, non-test boot controller in the test computer system.

  19. Click OK to close the Startup and Recovery dialog box.
  20. Click OK to close the System Properties dialog box.
  21. Restart the operating system to update the page file size.
  22. Install the Microsoft [image] Windows Symbol Files to the C:\Symbols directory
  23. From the Start menu, select Run.
  24. Type “diskmgmt.msc” and hit Enter.
    1. If the test OS is Windows Vista or Windows Longhorn Server you may be required to enter Administrative credentials and / or allow the action. Please do so.

  25. If the disks appear as inactive, activate them. Right click the disk and choose Initialize Disk.
  26. Partition and format all disks
    1. Right click each disk and choose Convert to Basic Disk if not basic already.
    2. Right click each disk and choose New Partition.
      1. Each partition should be a Primary Partition, use all of the disk space, use any drive letter, and be formatted in NTFS.

  27. Install DTM Client.
  28. Configure the machine for testing in DTM Studio.
    1. Add the machine to a machine pool.
    2. Deploy the “WDK\ConfigureFibreChannelHardwareBasedRaidSystem” dimension.


Testing Fibre Channel Hardware-Based RAID Systems

Open Device Console in DTM Studio.

Create a new submission for “Storage > RAID Storage > Hardware based RAID System > Fibre Channel”.

If your Hardware based RAID System uses an MPIO DSM be sure to load the same version that was installed on the client, the final version you wish to be signed.

If your Hardware based RAID System does not use a driver make sure to select all of the Disks contained in the array under the Disk Drive node in the device list.

If your device supports any of the following features please indicate by checking the box when prompted: MPIO, VDS, VSS.

Select the tests which you wish to launch, choose Add Selected, and then click schedule.

Crashdump Support Test

Setup: This test requires that the machine has Operating System Symbols installed in c:\symbols (see step 22 of Test System Configuration). This test will automatically install the debugging tools for windows as a setup task.

Troubleshooting: If you encounter a test failure at any point before the final Logging phase of the test, please ensure that you have the correct symbols.

Note: This test will intentionally crash the system. A bugcheck during the test is normal if caused by bugcheck.sys.

Note: This test reboots the system.

More Info:

Data Verification Test

Input: This test accepts a single drive letter and a PCI ID as input. These are both provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

Important: If the RAID system supports Multi-path I/O, then while the test is running, manually disconnect one cable from one of the identical HBAs connected to the RAID system. After the test is complete, reconnect the cable to the RAID system.

Note: This test reboots the system.

IFS Test

Input: This test accepts a single drive letter as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem. The test will reformat this partition and perform a series of operations.

WARNING: Any data saved on the test device will be lost.

Note: This test reboots the system.

More Info:

SCSI Compliance

Input: This test accepts the physical path of the test device as input. This is provided automatically by DTM.

More Info:

Storage Device Stress

Input: This test accepts a string of drive letters as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

Important: If the RAID system supports Multi-path I/O, then while the test is running, manually disconnect one cable from one of the identical HBAs connected to the RAID system. After the test is complete, reconnect the cable to the RAID system.

More Info:

SysCacheTest

Input: This test accepts a single drive letter as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

More Info:

DR - Device Path Exerciser

More Info:

DR - Sleep Stress with IO

More Info:

DR - Disable Enable with IO

More Info:

DR - Plug and Play Driver Test

More Info:

DR - Stress Test

More Info:

DR - Stress Test with low resource simulation

More Info:

DR - Sleep Stress Disable Enable with IO

More Info:

Multipath I-O Test

Note: This test will only appear if your device supports MPIO and testing in Windows Vista / Longhorn Server:

More Info:

DR - Driver Verifier

Note: This test will only appear if you load a driver.

More Info:

DR - Prefast for Drivers Test

Note: This test will only appear if you load a driver.

More Info:

DR - Static Driver Verifier Test

Note: This test will only appear if you load a driver.

More Info:

Run Inf Test against a single INF

Note: This test will only appear if you load a driver.

More Info:

VDSHW-PCI

Note: This test will only appear if your device supports VDS in hardware / driver.

More Info:

VSSHW-PCI

Note: This test will only appear if your device supports VSS in hardware / driver.

More Info:


Troubleshooting Fibre Channel Hardware-Based RAID Systems

For information about troubleshooting Fibre Channel Hardware-Based RAID System testing, see Troubleshooting Storage Tests.


iSCSI Hardware-based RAID Testing Overview

The procedures presented in this section outline the process for testing your Hardware Based RAID System > ISCSI for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as requried for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

Hardware Based RAID System > ISCSI Tests

Storage Data Verification Filter Test

Anti-Virus/File System Filter Test Kit

iSCSI Digest - Disk (Target)

iSCSI iSNS Compliance Test

iSCSI Mutual CHAP (Target)

iSCSI Oneway CHAP (Target)

iSCSI Ping Test (Target)

SCSI Compliance test

Storage Device Stress test (SDStress)

Syscache Test

Device Path Exerciser

System - Sleep Stress with IO

Disable Enable with IO

Plug and Play Driver Test

DR - Stress Test

Core Stress Test

System - Sleep Stress with IO

If your device supports MPIO and testing in Windows Vista / Longhorn Server:

Multi-Path I/O Test

If you are submitting a driver:

Driver Verifier

Prefast for Drivers

Static Driver Verifier

Run Inf Test against a single INF

If your device supports VDS in hardware / driver:

VDSHW-PCI

If your device supports VSS in hardware / driver:

VSSHW-PCI

Run time: approximately 96 hours

Hardware requirements

The following hardware is required for Hardware Based RAID System > ISCSI testing. Additional hardware may be required if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One computer with the following
    • Dual-core or equivalent processor (Windows Vista / XP)
    • Quad-core or equivalent processor (Windows Longhorn Server / Server 2003)
    • 2 GB memory (Windows Vista / XP)
    • 6 GB memory (Windows Longhorn Server / Server 2003)
    • Logo-compliant ACPI BIOS, with ACPI enabled by default

  • One ISCSI RAID storage system. This is the test device.

    • Note: The RAID system must be either a single cabinet that consists of an array controller enclosed in an external subsystem with hard disk drives, or an external array controller that connects to a RAID JBOD. The RAID system may not consist of only a PCI-based controller and one RAID JBOD.

  • One Gigabit Ethernet NIC.

    • Important: Two Gigabit Ethernet NICS, or one Gigabit Ethernet NIC and an iSCSI HBA are required if the iSCSI RAID system supports Microsoft MPIO.

  • One 1-GB Ethernet switch
  • One bootable ATA or SCSI hard disk drive. This drive must have a minimum capacity of 18 GB.
  • One Gigabit Ethernet cables, two if the test device supports MPIO.

    • Note: All hardware (except the test device, monitor, keyboard, mouse and the floppy disk drive) must be listed in the Windows Catalog.

Software requirements

The following software is required to run the Hardware Based RAID System > ISCSI tests:

One of the following operating systems:

  • Microsoft Windows Vista
  • Microsoft Windows XP Professional with Service Pack 2 (SP2)
  • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
  • Microsoft Windows Server 2003, Datacenter Edition, with SP1
  • Microsoft Windows Server XP Professional x64 Edition
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows Server 2003, Datacenter x64 Edition
  • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
  • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems

Any drivers that are not shipped with the operating system

The current release of Microsoft WDK

Microsoft Windows Symbol files [image] WHDC Symbols

The latest version of the Microsoft iSCSI software initiator.
To download the iSCSI software initiator, search for “iSCSI software initiator” at the [image] Microsoft Download Center.

The latest version of the Microsoft iSNS server.
To download the Microsoft iSNS server, search for “iSNS” at the [image] Microsoft Download Center.

The Microsoft .NET Framework Version 1.1, which is available from the [image] Microsoft Download Center.

Tester knowledge requirements

To run the Hardware Based RAID System > ISCSI tests, testers must know how to accomplish the following tasks:

  • Access and change system BIOS settings
  • Install SCSI and ATA hard disk drives
  • Install a RAID system
  • Configure a RAID array
  • Identify the operating system version and install correct Microsoft Windows Symbol files
  • Install the operating system from the product CD
  • Read test logs
  • Report bugs in the standard format
  • Set up an iSCSI environment and record the IP addresses and target names of the devices
  • Set the secret for oneway and mutual CHAP (if supported)
  • Configure an iSCSI tape drive to use an iSNS server
  • Log on to an iSCSI target device
  • Install the operating system from the product CD.
  • Download and install Microsoft iSCSI software initiator, Microsoft iSNS server, and Microsoft .NET Framework Version 1.1.

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Preparing to test iSCSI Hardware-based RAID Systems

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see the Hardware Based RAID System > ISCSI Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, see Running with autologon enabled.

Test system configuration

  1. Install the Gigabit Ethernet NIC in the test system. If the test device supports MPIO install a second NIC or iSCSI HBA.
  2. Connect the switch to power.

    3. Note: Do not connect the switch to any other network.

  3. Connect the test system to the switch using the Gigabit Ethernet NIC.
  4. If the iSCSI disk storage system supports Microsoft MPIO, then connect either the second Gigabit Ethernet NIC or the iSCSI HBA to the switch.
  5. Connect the disk storage system to the switch.
  6. Install the appropriate operating system onto a NTFS partition at least 20 GB in size on the hard disk drive.
  7. If the test device supports MPIO install any multi-path drivers.
  8. Download and install [image] Microsoft .NET Framework Version 1.1.
  9. Configure the target device to use Challenge Handshake Authentication Protocol (CHAP). You must configure the device to use oneway (target authenticates initiator) CHAP. If your device supports mutual CHAP, also configure the device to use mutual CHAP.

    10. Note: When you configure the device to use CHAP, you must provide a secret that is between 12 and 16 characters long. If you are configuring the device to use both oneway CHAP and mutual CHAP, you must provide different secrets for the target and the initiator.

  10. Log on to the target disk storage system with Persistent Login set.

    11. Important: You must be logged on to the iSCSI target device that is used for testing, or the HCT tests will not work properly.

  11. From the Start menu, select Run.
  12. Type “diskmgmt.msc” and hit Enter.
  13. Make sure the test disks are set as basic disks.
  14. Create three NTFS formatted partitions of at least 2GB and no greater than 4GB. All of these partitions should be exposed with a single logon.
  15. Install the iSNS software on the test system, and configure the target to use the iSNS server.
  16. If your device supports digest and you are required to configure it, configure the test device to support digest.
  17. Bind your disks in the Favorite Targets tab of iSCSI Initiator Properties.
  18. Install DTM Client.
  19. Configure the machine for testing in DTM Studio.
    1. Add the machine to a machine pool.
    2. Deploy the “WDK\ConfigureiSCSIHardwareBasedRaidSystem” dimension.


Testing iSCSI Hardware-based RAID Systems

Open Device Console in DTM Studio.

Create a new submission for “Storage > RAID Storage > Hardware based RAID System > ISCSI”.

If your Hardware based RAID System uses an MPIO DSM be sure to load the same version that was installed on the client, the final version you wish to be signed.

If your Hardware based RAID System does not use a driver make sure to select all of the Disks contained in the array under the Disk Drive node in the device list.

If your device supports any of the following features please indicate by checking the box when prompted: MPIO, VDS, VSS.

Select the tests which you wish to launch, choose Add Selected, and then click schedule.

Important: The following tests should be run last: iSCSI Digest - Disk (Target) Test, iSCSI iSNS Compliance Test, iSCSI Mutual CHAP (Target) Test, iSCSI Oneway CHAP (Target) Test, iSCSI Ping Target Test.

Important: All the iSCSI tests require a configuration file to setup the communication between the HBA (Initiator) and the iSCSI targets. This information includes the CHAP Username, target secret to Logon on to the target, the target name, target IP address, HBA PNPID, etc. This information must be entered in a UI at the time of scheduling the job. This UI will generate the configuration file, which is copied to the client machine during each job. The following screen shot shows the extension UI:

Data Verification Test

Input: This test accepts a single drive letter and a PCI ID as input. These are both provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

Important: If the RAID system supports Multi-path I/O, then while the test is running, manually disconnect one cable from one of the identical HBAs connected to the RAID system. After the test is complete, reconnect the cable to the RAID system.

Note: This test reboots the system.

IFS Test

Input: This test accepts a single drive letter as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem. The test will reformat this partition and perform a series of operations.

WARNING: Any data saved on the test device will be lost.

Note: This test reboots the system.

More Info:

iSCSI Digest - Disk (Target) Test

Important: Please run all iSCSI tests after all other tests.

More Info:

iSCSI iSNS Compliance Test

Important: Please run all iSCSI tests after all other tests.

More Info:

iSCSI Mutual CHAP (Target) Test

Important: Please run all iSCSI tests after all other tests.

More Info:

iSCSI Oneway CHAP (Target) Test

Important: Please run all iSCSI tests after all other tests.

More Info:

iSCSI Ping Target Test

Important: Please run all iSCSI tests after all other tests.

More Info:

SCSI Compliance

Input: This test accepts the physical path of the test device as input. This is provided automatically by DTM.

More Info:

Storage Device Stress

Input: This test accepts a string of drive letters as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

Important: If the RAID system supports Multi-path I/O, then while the test is running, manually disconnect one cable from one of the identical HBAs connected to the RAID system. After the test is complete, reconnect the cable to the RAID system.

More Info:

SysCacheTest

Input: This test accepts a single drive letter as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

More Info:

DR - Device Path Exerciser

More Info:

DR - Sleep Stress with IO

More Info:

DR - Disable Enable with IO

More Info:

DR - Plug and Play Driver Test

More Info:

DR - Stress Test

More Info:

DR - Stress Test with low resource simulation

More Info:

DR - Sleep Stress Disable Enable with IO

More Info:

Multipath I-O Test

Note: This test will only appear if your device supports MPIO and testing in Windows Vista / Longhorn Server:

More Info:

DR - Driver Verifier

Note: This test will only appear if you load a driver.

More Info:

DR - Prefast for Drivers Test

Note: This test will only appear if you load a driver.

More Info:

DR - Static Driver Verifier Test

Note: This test will only appear if you load a driver.

More Info:

Run Inf Test against a single INF

Note: This test will only appear if you load a driver.

More Info:

VDSHW-PCI

Note: This test will only appear if your device supports VDS in hardware / driver.

More Info:

VSSHW-PCI

Note: This test will only appear if your device supports VSS in hardware / driver.

More Info:


Troubleshooting iSCSI Hardware-based RAID System Testing

For information about troubleshooting iSCSI Hardware-based RAID System testing, see Troubleshooting Storage Tests.


SAS Hardware-based RAID Testing Overview

The procedures presented in this section outline the process for testing your SAS RAID Controller for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as required for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

SAS RAID Controller Tests

The list of test you need to run depend upon the capabilities of the device or system being tested. The following is the complete list of tests that could be required for your test device:

Crashdump Support Test

Storage Data Verification Filter Test

Int 13h Extensions test

Storage Device Stress test (SDStress)

Tape I/O Test

Driver Verifier

Device Path Exerciser

System - Sleep Stress with IO

Disable Enable with IO

Plug and Play Driver Test

Prefast for Drivers

Static Driver Verifier

Stress Test

Core Stress Test

System - Sleep Stress with IO

Run time: approximately 2 hours

Hardware requirements

The following hardware is required for SAS RAID Controller testing. Additional hardware may be required if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One test system that has received the "Designed for Windows" logo and includes the following:
  • One computer with the following:
    • Dual-core or equivalent processor (Windows Vista / XP)
    • Quad-core or equivalent processor (Windows Longhorn Server / Server 2003)
    • 2 GB memory (Windows Vista / XP)
    • 6 GB memory (Windows Longhorn Server / Server 2003)
    • Logo-compliant ACPI BIOS, with ACPI enabled by default

      Note A system that contains two microprocessors that support hyper-threading can be used if hyper-threading is enabled.

      Important The operating system must report that a minimum of 5500 MB of RAM is free and available. If you are testing the SAS RAID controller on Windows XP Professional, or if the SAS RAID controller will only be sold in systems that do not support four processors or 6 GB of RAM, the test system must have at least one microprocessor and 256 MB of RAM.

    • PCI-based bus
    • Logo-compliant ACPI BIOS, with ACPI enabled by default

      For Windows Vista/XP Professional, the test system must support the S3 and S4 states.

      For Windows XP Professional on mobile systems, the test system must support the S1 or S3 states and the S4 state.

      For the Windows Server 2003 operating system family, the test system is only required to support the S4 state.

  • If the SAS RAID controller is not bootable, one bootable ATA or SCSI controller and one ATA or SCSI hard disk drive are required.
  • One ATA or SCSI CD-ROM drive.
  • If the test device is an add-on SAS RAID controller, two identical test devices are required. If the test device is an integrated SAS RAID controller, only one test device is required.
  • If the test device is an integrated SAS RAID controller, you must have one of the following:
    • One SAS JBOD that supports a minimum of six hard disk drives
    • Six SAS hard disk drives

  • If the test device is an add-on SAS RAID controller, you must have one of the following:
    • Two SAS JBODs. One SAS JBOD must support a minimum of three hard disk drives, and the other SAS JBOD must support a minimum of six hard disk drives.
    • One SAS JBOD and three SAS hard disk drives. The SAS JBOD must support a minimum of six hard disk drives.
    • One SAS JBOD and six Serial ATA hard disk drives. The SAS JBOD must support a minimum of three hard disk drives.
    • Three SAS hard disk drives and six Serial ATA hard disk drives.

  • One PCI-to-PCI bridge adapter is required, except if any of the following situations apply:
    • The SAS RAID controllers cannot fit into PCI bridge adapters. This situation might occur with an integrated controller or a controller that can only fit into a specially-design slot.
    • The SAS RAID controller is designed and sold only for systems that cannot accept full height PCI-to-PCI bridge adapters. This situation might occur with a blade server.
    • One of the SAS RAID controllers can be placed into a PCI bus slot that is already behind a PCI bridge.

  • If you are using six Serial ATA hard disk drives instead of a SAS JBOD, twelve SAS edge expanders and six SAS fanout expanders are required.

    • Important All hardware (except the test device, monitor, keyboard, and mouse) must be included in the Windows Catalog.

Software requirements

The following software is required to run the SAS RAID Controller tests:

One of the following operating systems:

  • Microsoft Windows Vista
  • Microsoft Windows XP Professional with Service Pack 2 (SP2)
  • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
  • Microsoft Windows Server 2003, Datacenter Edition, with SP1
  • Microsoft Windows Server XP Professional x64 Edition
  • Microsoft Windows Server 2003, Enterprise x64 Edition
  • Microsoft Windows Server 2003, Datacenter x64 Edition
  • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
  • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems
  • Any drivers that are not shipped with the operating system
  • The current release of the Microsoft WDK

Tester knowledge requirements

To run the SAS RAID Controller tests, testers must know how to accomplish the following tasks:

  • Access and change the system BIOS settings
  • Install SAS and ATA hard disk drives
  • Install a SAS RAID controller
  • Configure a RAID array
  • Install a PCI-to-PCI bridge
  • Install and configure Debugging Tools for Windows
  • Install Windows Symbols files
  • Install the appropriate operating system
  • Download and install an operating system service pack
  • Read test logs
  • Report bugs in a standard bug format

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Preparing to Test SAS Hardware-based RAID Controllers

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see the SAS RAID Controller Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, see Running with autologon enabled.

Basic Functionality Testing

There are two different procedures for configuring a SAS RAID controller for basic functionality testing. Use the secondary configuration procedure if one or both of the following exceptions applies. If neither exception applies, use the default configuration procedure.

  • The SAS RAID controller test device is an integrated controller.

    Note Use the default configuration procedure for integrated controllers if a system that meets the hardware requirements with two of the integrated controllers is available or if a duplicate PCI adapter version of the SAS RAID controller is available.

  • The SAS RAID controller is designed for and sold only in a host test system that will accept only a single version of the controller.

1. Preparing for SAS Raid Controller Testing with the Secondary Configuration

Use the following procedure to configure the test system and test a SAS RAID controller only if the SAS RAID controller is an integrated controller.

Important This procedure cannot be used for integrated controllers if a system that meets hardware requirements with two of the integrated controllers is available or if a duplicate PCI adapter version of the SAS RAID controller is available.

1.1 Secondary configuration procedure for SAS RAID controller basic functionality testing

Note All adapters should be operated with BIOS enabled and write caching enabled.

  1. Turn off the test system.
  2. Install an add-in controller (not the test device) that has signed drivers or in-box support. If the test device is not bootable, the add-in controller must be boot-capable.
  3. If the test device is not bootable, attach a hard disk drive to the add-in controller. This disk is referred to as Disk 1.
  4. Attach a CD-ROM drive to the add-in controller.
  5. Install one SAS RAID controller (the test device).
  6. Connect one SAS JBOD or six SAS hard disk drives to the SAS RAID controller.
  7. If the test system contains any USB floppy disk drives or LS-120 drives, remove them and replace them with standard ATA floppy disk drives.

1.2 To configure the SAS RAID controller for basic functionality testing

  1. If the test device supports enough hard disk drives to create two RAID arrays, create two 40-GB RAID arrays on the test device. These RAID arrays are referred to as RAID Array 1 and RAID Array 2.
  2. If the test device does not support enough hard disk drives to create two RAID arrays, create one 40-GB RAID array on the test device. This RAID array is referred to as RAID Array 1. Attach a hard disk drive to the add-in controller, and use this hard disk drive instead of RAID Array 2 wherever RAID Array 2 is mentioned.
  3. Configure the RAID arrays according to the following table:

If the test device supports these RAID levels… | … then configure RAID Array 1 to use RAID level… | … and configure RAID Array 2 to use RAID level...
0 only | 0 | 0
1 only | 1 | 1
5 only | 5 | 5
0 and 1 only | 1 | 0
0 and 5 only | 5 | 0
1 and 5 only | 5 | 1
0, 1, and 5 | 5 | 1

To install the operating system in the secondary configuration

Use the following procedure to install the operating system. When you are finished, the RAID array will be configured as shown in Figure 3 if the test device supports enough hard disk drives to create two RAID arrays and as shown in Figure 4 if the test device does not support enough hard disk drives to create two RAID arrays.

Figure 3 RAID array secondary configuration for a device that supports enough hard disk drives to create two RAID arrays

Figure 4 RAID array secondary configuration for a device that does not support enough hard disk drives to create two RAID arrays

  1. If the test SAS RAID controller is bootable, install the operating system onto a 14-GB NTFS partition on RAID Array 1. If the test SAS RAID controller is not bootable, install the operating system onto a 14-GB NTFS partition on Disk 1.
  2. Install any software or drivers that are necessary to connect to and manage the peripheral devices.
  3. Click Start, right click My Computer, and then click Properties.
  4. On Windows Vista or Windows Longhorn Server, click Advanced System Settings. You may be required to enter Administrative credentials and / or allow the action. Please do so.
  5. On the General tab, note the amount of RAM that the computer has.
  6. Click the Advanced tab, and then under Performance, click Settings.
    The Performance Options dialog box appears.
  7. Click the Advanced tab, and then under Virtual Memory, click Change.
    The Virtual Memory dialog box appears.
  8. Click Custom Size, and then type a number that is larger than the size of RAM in the Initial Size text box.

    Note You specify the size of the page file in megabytes (MB). If the amount of RAM on your computer was specified using gigabytes (GB) or some other measure, convert the amount of RAM to MB before choosing and entering a value for the page file size.

  9. In the Maximum Size text box, type a maximum size value that is larger than the initial size. (It is common for the maximum size to be one and a half to two times the initial size.)
  10. Click Set, and then click OK twice.
  11. On the Advanced tab of the System Properties dialog box, under Startup and Recovery, click Settings.
  12. Under Write debugging information, click the down arrow, and then select Small memory dump (64 KB). In the Small dump directory box, type X:\Minidump, where X is the drive letter of one of the RAID partitions.
  13. Click OK twice, and then restart the computer to update the page file size.
  14. Install Debugging Tools for Windows to the C:\Debuggers directory.
  15. Copy the Windows Symbols files to the C:\Symbols directory.
  16. Use Windows Disk Management to make all of the disks dynamic.

    Important If the test device is not bootable, you are booting from an alternate boot controller.

  17. Use the Windows Disk Management utility to set up three 4-GB partitions on RAID Array 1. If you are testing with a 32-bit edition of Microsoft Windows, format two of the partitions with the NTFS file system, and format the third partition with FAT32. If you are testing with a 64-bit edition of Windows, format all three partitions with NTFS.
  18. If you are testing with Windows Server 2003, Enterprise Edition, use Windows Disk Management to create a software RAID 1 mirror from one of the NTFS partitions on RAID Array 1 to the unallocated space on RAID Array 2.
  19. If you are testing with Windows Server 2003, Enterprise Edition, use Windows Disk Management to create a 4-GB NTFS software RAID 5 array that uses unallocated space on RAID Array 1 and RAID Array 2.
  20. If you are testing with Windows Vista/XP Professional, use Windows Disk Management to create a spanned volume that uses the unallocated space on RAID Array 1 and RAID Array 2.
  21. Install DTM Client.
  22. Configure the machine for testing in DTM Studio.
    1. Add the machine to a machine pool.
    2. Deploy the WDK\ConfigureSasRaidStorageController” dimension.

2. Preparing for SAS RAID Controller Testing with the Default Configuration

Use the following procedure to configure the test system and install the software to test a SAS RAID controller, unless one or both of the following conditions applies:

Use the following procedure to configure the test system and install the software to test a SAS RAID controller, unless one or both of the following conditions applies:

  • The SAS RAID controller is an integrated controller.

    Note Use this default configuration procedure for integrated controllers if a system that meets the hardware requirements with two of the integrated controllers is available or if a duplicate PCI adapter version of the SAS RAID controller is available.

  • The SAS RAID controller is designed for and sold only in a host test system that will accept only a single version of the controller.

2.1 Default test system configuration

2.1.1 To assemble the test system

Note All adapters should be operated with BIOS enabled and write caching enabled.

  1. Turn off the test system.
  2. If the test device is not bootable, install one boot-capable, add-in controller (not the test device) that has signed drivers or in-box support
  3. Attach a CD-ROM drive to the system if one is not already attached.
  4. Install one SAS RAID controller (controller 1).
  5. Connect either one SAS JBOD or three SAS hard disk drives to controller 1.
  6. Install a PCI-to-PCI bridge in a PCI slot on the host test system, unless any of the following conditions apply:
    • The SAS RAID controller cannot fit into a PCI bridge adapter, which may be the case with integrated controllers or controllers that can only fit into specially designed slots.
    • The SAS RAID controller is designed and sold only for systems that cannot accept full-height PCI-to-PCI bridge adapters, which may be the case with blade servers.
    • One of the SAS RAID controllers can be placed into a PCI bus slot that is already behind a PCI bridge.

  7. Install a secondary, duplicate SAS RAID controller (controller 2) into the PCI-to-PCI bridge card.

    Note Install the secondary SAS RAID controller directly into a PCI slot if a PCI bridge card is not required.

  8. If possible, set the first and second SAS RAID controllers to use the same IRQ.
  9. Connect one SAS JBOD or six Serial ATA hard disk drives to controller 2. If you are using Serial ATA hard disk drives instead of a SAS JBOD, use the following cable configuration for each Serial ATA hard disk drive: the SAS controller connected to an edge expander connected to a fanout expander connected to an edge expander connected to the Serial ATA hard disk drive.
  10. If the test system contains any USB floppy disk drives or LS-120 drives, remove them and replace them with standard ATA floppy disk drives.
  11. Turn on the test system.

2.1.2. To configure the test system

  1. Create one 40-GB RAID array on controller 1 and two 40-GB RAID arrays on controller 2. Configure the RAID arrays according to the following table. The RAID array on controller 1 is referred to as RAID Array 1, and the RAID arrays on controller 2 are referred to as RAID Array 2 and RAID Array 3. If the test device does not support enough hard disk drives to configure the required RAID arrays, install an additional hard disk drive on an add-in controller and create RAID Array 3 on this hard disk drive.

If the test device supports these RAID levels… | … then configure RAID array 1 to use RAID level… | … and configure RAID array 2 to use RAID level… | … and configure RAID array 3 to use RAID level…
0 only | 0 | 0 | 0
1 only | 1 | 1 | 1
5 only | 5 | 5 | 5
0 and 1 only | 1 | 0 | 1
0 and 5 only | 5 | 0 | 5
1 and 5 only | 5 | 1 | 5
0, 1, and 5 | 5 | 0 | 1

2.1.3 To install the operating system with the default configuration

Use the following procedure to install the operating system. When you are finished, the RAID arrays will be configured as shown in Figure 1 for Microsoft Windows XP and as shown in Figure 2 for Windows Server 2003, Enterprise Edition.

Figure 1 RAID array default configuration for Windows XP

Figure 2 RAID array default configuration for Windows Server 2003, Enterprise Edition

  1. f the test SAS RAID controller is bootable, install the operating system onto a 14 GB NTFS partition on RAID Array 1. If the SAS RAID controller is not bootable, install the operating system onto a 14 GB NTFS partition on a hard disk drive that is connected to an alternate, non-test boot controller in the host test system.
  2. Install any software or drivers that are necessary to connect to and manage the peripheral devices.

    3. Note All drivers, except the drivers for the test device, must be signed and listed in Windows Catalog.

  3. Click Start, right click My Computer, and then click Properties.
    The System Properties dialog box appears.
  4. On the General tab, note the amount of RAM that the computer has.
  5. Click the Advanced tab, and then under Performance, click Settings.
    The Performance Options dialog box appears.
  6. Click the Advanced tab, and then under Virtual Memory, click Change.
    The Virtual Memory dialog box appears.
  7. Click Custom Size, and then type a number that is larger than the size of RAM in the Initial Size text box.

    8. Note You specify the size of the page file in megabytes (MB). If the amount of RAM on your computer was specified using gigabytes (GB) or some other measure, convert the amount of RAM to MB before choosing and entering a value for the page file size.

  8. In the Maximum Size text box, type a maximum size value that is larger than the initial size. (It is common for the maximum size to be one and a half to two times the initial size.)
  9. Click Set, and then click OK twice.
  10. On the Advanced tab of the System Properties dialog box, under Startup and Recovery, click Settings.
  11. Under Write debugging information, click the down arrow, and then select Small memory dump (64 KB). In the Small dump directory box, type X:\Minidump, where X is the drive letter of one of the RAID partitions.
  12. Click OK twice, and then restart the computer to update the page file size.
  13. Install Debugging Tools for Windows to the C:\Debuggers directory.
  14. Copy the Windows Symbols files to the C:\Symbols directory.
  15. Use Windows Disk Management to make all of the disks dynamic.

    16. Important If the test device is not bootable at this point, you are booting from an alternate boot controller. Do not add any partitions to the hard disks on the alternate boot controller.

  16. Use the Windows Disk Management utility to set up three 4-GB partitions on RAID Array 2. If you are testing with a 32-bit edition of Windows, format two of the partitions with the NTFS file system, and format the third partition with the FAT32 file system. If you are testing with a 64-bit edition of Windows, format all three partitions with NTFS.
  17. If you are testing with Windows Server 2003 , use Windows Disk Management to create a software RAID 1 mirror from one of the NTFS partitions on RAID Array 2 to the unallocated space on RAID Array 1.
  18. If you are testing with Windows Server 2003, use Windows Disk Management to create a 4-GB NTFS software RAID 5 array that uses unallocated space on RAID Array 1, RAID Array 2, and RAID Array 3.
  19. If you are testing with Windows Vista/XP, use Windows Disk Management to create a 4-GB NTFS spanned volume that uses RAID Array 1, RAID Array 2, and RAID Array 3.
  20. Install DTM Client.
  21. Configure the machine for testing in DTM Studio.
    1. Add the machine to a machine pool.
    2. Deploy the WDK\ConfigureSasRaidStorageController” dimension.


Testing SAS Hardware-based RAID Controllers

Open Device Console in DTM Studio.

Create a new submission for “Storage > Adapter or Controller > SAS-RAID”.

If the device has driver, Please select the driver INF when prompted.

Make sure to select the test SAS RAID Controller from the device list.

Select the tests which you wish to launch, choose Add Selected, and then click schedule.

Crashdump Support Test

Setup: This test requires that the machine has Operating System Symbols installed in c:\symbols. This test will automatically install the debugging tools for windows as a setup task.

Troubleshooting: If you encounter a test failure at any point before the final Logging phase of the test, please ensure that you have the correct symbols.

Note: This test will intentionally crash the system. A bugcheck during the test is normal if caused by bugcheck.sys.

Note: This test reboots the system.

More Info:

Data Verification Test

Input: This test accepts a single drive letter and a PNP ID as input. These are both provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

Note: This test reboots the system.

Ext Int13h Test

More Info:

Storage Device Stress

Input: This test accepts a string of drive letters as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

More Info:

Tape IO Test

More Info:

Driver Verifier

More Info:

Device Path Exerciser

More Info:

Device Path Exerciser

More Info:

Sleep Stress with IO

More Info:

Disable Enable with IO

More Info:

Plug and Play Driver Test

More Info:

Prefast for Drivers Test

More Info:

Static Driver Verifier Test

More Info:

Stress Test

More Info:

Stress Test with low resource simulation

More Info:

Sleep Stress Disable Enable with IO

More Info:


Troubleshooting SAS Hardware-based RAID Testing

For information about troubleshooting SAS Hardware-based RAID testing, see Troubleshooting Storage Tests.


Serial ATA Hardware-based RAID Testing Overview

The procedures presented in this section outline the process for testing your Hardware Based RAID System > SATA for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as requried for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

Hardware Based RAID System > SATA Tests

The list of test you need to run depend upon the capabilities of the device or system being tested. To see the complete list of tests that could be required for your device, see the Hardware Based RAID System > SATA Tests.

Crashdump Support Test

Storage Data Verification Filter Test

Anti-Virus/File System Filter Test Kit

SATA IO Sig Test

SCSI Compliance test

Storage Device Stress test (SDStress)

Syscache Test

Device Path Exerciser

System - Sleep Stress with IO

Disable Enable with IO

Plug and Play Driver Test

DR - Stress Test

Core Stress Test

System - Sleep Stress with IO

If your device supports MPIO and testing in Windows Vista / Longhorn Server:

Multi-Path I/O Test

If your device supports VDS in hardware / driver:

VDSHW-PCI

If your device supports VSS in hardware / driver:

VSSHW-PCI

Run time: approximately 96 hours

Hardware requirements

The following hardware is required for Hardware Based RAID System > SATA testing. Additional hardware may be required if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One computer with the following:
    • Dual-core or equivalent processor (Windows Vista / XP)
    • Quad-core or equivalent processor (Windows Longhorn Server / Server 2003)
    • 2 GB memory (Windows Vista / XP)
    • 6 GB memory (Windows Longhorn Server / Server 2003)
    • Logo-compliant ACPI BIOS, with ACPI enabled by default

  • One SATA RAID storage system. This is the test device.

    • Note: The RAID system must be either a single cabinet that consists of an array controller enclosed in an external subsystem with hard disk drives, or an external array controller that connects to a RAID JBOD. The RAID system may not consist of only a PCI-based controller and one RAID JBOD.

  • One PCI-based SATA host bus adapter (HBA). Two HBAs are required if the test system supports multi-path.

    • Note: The PCI-based HBA that is selected to test the RAID system should be supported by the manufacturer for use with the RAID system. Any drivers for the HBA that are used on the test system for this HBA must be have received a “Designed for Windows” logo, and the HBA model must be included in the Windows Catalog.

  • One bootable ATA or SATA hard disk drive is required if the RAID system does not support boot. This drive must have a minimum capacity of 18 GB.
  • One set of cables, for the appropriate bus, for each HBA.

    • Note: All hardware (except the test device, monitor, keyboard, mouse and the floppy disk drive) must be listed in the Windows Catalog.

Software requirements

The following software is required to run the Hardware Based RAID System > SATA tests:

  • One of the following operating systems:
    • Microsoft Windows Vista
    • Microsoft Windows XP Professional with Service Pack 2 (SP2)
    • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
    • Microsoft Windows Server 2003, Datacenter Edition, with SP1
    • Microsoft Windows Server XP Professional x64 Edition
    • Microsoft Windows Server 2003, Enterprise x64 Edition
    • Microsoft Windows Server 2003, Datacenter x64 Edition
    • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
    • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems

  • Any drivers that are not shipped with the operating system
  • The current release of Microsoft WDK
  • Microsoft Windows Symbol files [image] WHDC Symbols

Tester knowledge requirements

To run the Hardware Based RAID System > SATA tests, testers must know how to accomplish the following tasks:

  • Access and change system BIOS settings
  • Install SATA and ATA hard disk drives
  • Install a RAID system
  • Configure a RAID array
  • Identify the operating system version and install correct Microsoft Windows Symbol files
  • Identify the operating system version and install correct Microsoft Windows Symbol files
  • Install the operating system from the product CD
  • Read test logs
  • Report bugs in the standard format

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Preparing to Test Serial ATA Hardware-based RAID Systems

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see the Hardware Based RAID System > SATA Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, see Running with autologon enabled.

Test system configuration

  1. Configure the RAID system by using the RAID system operator panel, by using the command-line interface, or by connecting another system to the RAID system and running the configuration utility.
    1. All RAID devices are only required to support one RAID level: either RAID 5, RAID 1, or RAID 0. If your RAID system supports more than one RAID level you must test all RAID levels that the device supports.
    2. Create three 40-GB RAID arrays on the raid system. Configure the arrays according to the following table:
      3. If the test device supports these RAID levels… | … then configure RAID array 1 to use RAID level… | … and configure RAID array 2 to use RAID level… | … and configure RAID array 3 to use RAID level…
0 only | 0 | 0 | 0
1 only | 1 | 1 | 1
5 only | 5 | 5 | 5
0 and 1 only | 1 | 1 | 0
0 and 5 only | 5 | 5 | 0
1 and 5 only | 5 | 5 | 1
0, 1, and 5 | 5 | 1 | 0
    3. If the HBA you are using to test the RAID system is bootable, and the RAID system supports boot, then you must also create another 20 GB partition

  2. Turn off the test system.
  3. Install one SATA HBA in the test computer system and connect it to the RAID system by using the appropriate cables for the bus.

    4. Note: If the test RAID system supports more than one bus protocol, then you must test and submit your device for a Designed For Windows logo once with each protocol that you want to have it qualified for.

    Note: The PCI-based HBA that is selected to test the RAID system should be supported for use with the RAID system by the manufacturer of the RAID system. Any drivers that are used on the test system for this HBA must be signed by WHQL and the HBA model and firmware version must be included in the Windows Catalog.

  4. If the RAID system supports multipath drivers, install a second, identical HBA in the test system and connect it to the RAID system by using the appropriate cables for the bus.
  5. If the HBA you are using to test the RAID system is bootable, and the RAID system supports boot, then:
    1. Install any HBA drivers that are necessary to connect to or manage the test device.
    2. Format the 20 GB NTFS partition created in 1.4 and install the appropriate operating system onto this partition.

  6. If the HBA you are using to test the RAID system is not bootable, or if the RAID system does not support boot, then:
    1. Install the alternate boot controller on the test system.
    2. Connect a hard disk drive to an alternate boot controller on the test system.
    3. Install any drivers necessary for the alternate boot controller.
    4. Install the appropriate operating system onto a 20 GB NTFS partition on the hard disk drive.
    5. Install any HBA drivers that are necessary to connect to or manage the peripheral devices.

  7. At this point you should have the system installed and booting to the test OS.
  8. From the Start menu, right-click My Computer, and then select Properties.
  9. Note the amount of RAM that the computer has.
  10. If the test OS is Windows Vista or Windows Longhorn Server, click Advanced System Settings. You may be required to enter Administrative credentials and / or allow the action. Please do so.
  11. On the Advanced tab of the System Properties dialog box, click Settings in the Performance area.
  12. On the Advanced tab of the Performance Options dialog box, click Change in the Virtual Memory area.
  13. Click Custom Size, and in the Initial Size box, enter a number that is larger than the size of the RAM you noted in step 9.

    14. Note: You specify the size of the page file in megabytes (MB). If the amount of RAM on your computer was specified by using gigabytes (GB) or some other measure, convert the amount of RAM to MB before choosing and entering a value for the page file size.

  14. Enter a Maximum Size value that is larger than the initial size. (It is common for the maximum size to be 1.5 to 2 times the initial size.)
  15. Click Set.
  16. Click OK to close the Virtual Memory dialog box.
  17. Click OK to close the Performance Options dialog box.
  18. On the Advanced tab of the System Properties dialog box, click Settings in the Startup and Recovery area.
    1. If the HBA selected for testing the RAID system is bootable and the RAID system supports boot, then, in the Write debugging information area of the Startup and Recovery dialog box, select Small memory dump (64 KB), and then type X:\Minidump in the Small dump directory box, where X is the drive letter of the RAID partition.
    2. If the HBA selected for testing the RAID system is not bootable, or if the RAID system does not support boot, then, in the Write debugging information area of the Startup and Recovery dialog box, select Small memory dump (64 KB), and then type X:\Minidump in the Small dump directory box, where X is the drive letter of a hard disk drive that is connected to an alternate, non-test boot controller in the test computer system.

  19. Click OK to close the Startup and Recovery dialog box.
  20. Click OK to close the System Properties dialog box.
  21. Restart the operating system to update the page file size.
  22. Install the Microsoft Windows Symbols files to the C:\Symbols directory. WHDC Symbols
  23. From the Start menu, select Run.
  24. Type “diskmgmt.msc” and hit Enter.
    1. If the test OS is Windows Vista or Windows Longhorn Server you may be required to enter Administrative credentials and / or allow the action. Please do so.

  25. If the disks appear as inactive, activate them. Right click the disk and choose Initialize Disk.
  26. Partition and format all disks
    1. Right click each disk and choose Convert to Basic Disk if not basic already.
    2. Right click each disk and choose New Partition.
    3. Each partition should be a Primary Partition, use all of the disk space, use any drive letter, and be formatted in NTFS.

    1. Install DTM Client.
    2. Configure the machine for testing in DTM Studio.
      1. Add the machine to a machine pool.
      2. Deploy the “WDK\ConfigureFibreChannelHardwareBasedRaidSystem” dimension.


Testing Serial ATA Hardware-based RAID Systems

Open Device Console in DTM Studio.

Create a new submission for “Storage > RAID Storage > Hardware based RAID System > SATA”.

The test device should not require a driver. Please select “No Driver Files” when prompted.

Make sure to select all of the Disks contained in the array under the Disk Drive node in the device list.

If your device supports any of the following features please indicate by checking the box when prompted: MPIO, VDS, VSS.

Select the tests which you wish to launch, choose Add Selected, and then click schedule.

Crashdump Support Test

Setup: This test requires that the machine has Operating System Symbols installed in c:\symbols (see step 22 of Test System Configuration). This test will automatically install the debugging tools for windows as a setup task.

Troubleshooting: If you encounter a test failure at any point before the final Logging phase of the test, please ensure that you have the correct symbols.

Note: This test will intentionally crash the system. A bugcheck during the test is normal if caused by bugcheck.sys.

Note: This test reboots the system.

More Info:

Data Verification Test

Input: This test accepts a single drive letter and a PCI ID as input. These are both provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

Important: If the RAID system supports Multi-path I/O, then while the test is running, manually disconnect one cable from one of the identical HBAs connected to the RAID system. After the test is complete, reconnect the cable to the RAID system.
Note: This test reboots the system.

IFS Test

Input: This test accepts a single drive letter as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem. The test will reformat this partition and perform a series of operations.

WARNING: Any data saved on the test device will be lost.

Note: This test reboots the system.

More Info:

SCSI Compliance

Input: This test accepts the physical path of the test device as input. This is provided automatically by DTM.

More Info:

Storage Device Stress

Input: This test accepts a string of drive letters as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

Important: If the RAID system supports Multi-path I/O, then while the test is running, manually disconnect one cable from one of the identical HBAs connected to the RAID system. After the test is complete, reconnect the cable to the RAID system.

More Info:

SysCacheTest

Input: This test accepts a single drive letter as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

More Info:

DR - Device Path Exerciser

More Info:

DR - Sleep Stress with IO

More Info:

DR - Disable Enable with IO

More Info:

DR - Plug and Play Driver Test

More Info:

DR - Stress Test

More Info:

DR - Stress Test with low resource simulation

More Info:

DR - Sleep Stress Disable Enable with IO

More Info:

Multipath I-O Test

Note: This test will only appear if your device supports MPIO and testing in Windows Vista / Longhorn Server:

More Info:

SATA IO Sig Test

Note: This test requires the user to manually provide certification that the device has passed received SATA IO certification.

Input: This test accepts the Device Instance ID of the test device as input. This is provided automatically by DTM.

More Info:

VDSHW-PCI

Note: This test will only appear if your device supports VDS in hardware / driver.

More Info:

VSSHW-PCI

Note: This test will only appear if your device supports VSS in hardware / driver.

More Info:


Troubleshooting Serial ATA Hardware-based RAID Testing

For information about troubleshooting Serial ATA Hardware-based RAID testing, see Troubleshooting Storage Tests.


SCSI Hardware-based RAID Testing Overview

The procedures presented in this section outline the process for testing your Hardware Based RAID System > SCSI for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as requried for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

Hardware Based RAID System > SCSI Tests

The list of test you need to run depend upon the capabilities of the device or system being tested. To see the complete list of tests that could be required for your device, see the Hardware Based RAID System > SCSI Tests.

Crashdump Support Test

Storage Data Verification Filter Test

Anti-Virus/File System Filter Test Kit

SCSI Compliance test

Storage Device Stress test (SDStress)

Syscache Test

Device Path Exerciser

System - Sleep Stress with IO

Disable Enable with IO

Plug and Play Driver Test

DR - Stress Test

Core Stress Test

System - Sleep Stress with IO

If your device supports MPIO and testing in Windows Vista / Longhorn Server:

Multi-Path I/O Test

If your device supports VDS in hardware / driver:

VDSHW-PCI

If your device supports VSS in hardware / driver:

VSSHW-PCI

Run time: approximately 96 hours

Hardware requirements

The following hardware is required for Hardware Based RAID System > SCSI testing. Additional hardware may be required if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One computer with the following:
    • Dual-core or equivalent processor (Windows Vista / XP)
    • Quad-core or equivalent processor (Windows Longhorn Server / Server 2003)
    • 2 GB memory (Windows Vista / XP)
    • 6 GB memory (Windows Longhorn Server / Server 2003)
    • Logo-compliant ACPI BIOS, with ACPI enabled by default

  • One SCSI RAID storage system. This is the test device.

    • Note: The RAID system must be either a single cabinet that consists of an array controller enclosed in an external subsystem with hard disk drives, or an external array controller that connects to a RAID JBOD. The RAID system may not consist of only a PCI-based controller and one RAID JBOD.

  • One PCI-based SCSI host bus adapter (HBA). Two HBAs are required if the test system supports multi-path.

    • Note: The PCI-based HBA that is selected to test the RAID system should be supported by the manufacturer for use with the RAID system. Any drivers for the HBA that are used on the test system for this HBA must be have received a “Designed for Windows” logo, and the HBA model must be included in the Windows Catalog.

  • One bootable ATA or SCSI hard disk drive is required if the RAID system does not support boot. This drive must have a minimum capacity of 18 GB.
  • One set of cables, for the appropriate bus, for each HBA.

    • Note: All hardware (except the test device, monitor, keyboard, mouse and the floppy disk drive) must be listed in the Windows Catalog.

Software requirements

The following software is required to run the Hardware Based RAID System > SCSI tests:

  • One of the following operating systems:
    • Microsoft Windows Vista
    • Microsoft Windows XP Professional with Service Pack 2 (SP2)
    • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
    • Microsoft Windows Server 2003, Datacenter Edition, with SP1
    • Microsoft Windows Server XP Professional x64 Edition
    • Microsoft Windows Server 2003, Enterprise x64 Edition
    • Microsoft Windows Server 2003, Datacenter x64 Edition
    • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
    • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems

  • Any drivers that are not shipped with the operating system
  • The current release of Microsoft WDK
  • Microsoft Windows Symbol files [image] WHDC Symbols

Tester knowledge requirements

To run the Hardware Based RAID System > SCSI tests, testers must know how to accomplish the following tasks:

  • Access and change system BIOS settings
  • Install SCSI and ATA hard disk drives
  • Install a RAID system
  • Configure a RAID array
  • Identify the operating system version and install correct Microsoft Windows Symbol files
  • Install the operating system from the product CD
  • Read test logs
  • Report bugs in the standard format

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Preparing to test SCSI Hardware-based RAID Systems

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see the Hardware Based RAID System > SCSI Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, see Running with autologon enabled.

Test system configuration

  1. Configure the RAID system by using the RAID system operator panel, by using the command-line interface, or by connecting another system to the RAID system and running the configuration utility.
    1. All RAID devices are only required to support one RAID level: either RAID 5, RAID 1, or RAID 0. If your RAID system supports more than one RAID level you must test all RAID levels that the device supports.
    2. Create three 40-GB RAID arrays on the raid system. Configure the arrays according to the following table:
      3. If the test device supports these RAID levels… | … then configure RAID array 1 to use RAID level… | … and configure RAID array 2 to use RAID level… | … and configure RAID array 3 to use RAID level…
0 only | 0 | 0 | 0
1 only | 1 | 1 | 1
5 only | 5 | 5 | 5
0 and 1 only | 1 | 1 | 0
0 and 5 only | 5 | 5 | 0
1 and 5 only | 5 | 5 | 1
0, 1, and 5 | 5 | 1 | 0
    3. If the HBA you are using to test the RAID system is bootable, and the RAID system supports boot, then you must also create another 20 GB partition.

  2. Turn off the test system.
  3. Install one SCSI HBA in the test computer system and connect it to the RAID system by using the appropriate cables for the bus.

    4. Note: If the test RAID system supports more than one bus protocol, then you must test and submit your device for a Designed For Windows logo once with each protocol that you want to have it qualified for.

    Note: The PCI-based HBA that is selected to test the RAID system should be supported for use with the RAID system by the manufacturer of the RAID system. Any drivers that are used on the test system for this HBA must be signed by WHQL and the HBA model and firmware version must be included in the Windows Catalog.

  4. If the RAID system supports multipath drivers, install a second, identical HBA in the test system and connect it to the RAID system by using the appropriate cables for the bus.
  5. If the HBA you are using to test the RAID system is bootable, and the RAID system supports boot, then:
    1. Install any HBA drivers that are necessary to connect to or manage the test device.
    2. Format the 20 GB NTFS partition created in 1.4 and install the appropriate operating system onto this partition.

  6. If the HBA you are using to test the RAID system is not bootable, or if the RAID system does not support boot, then:
    1. Install the alternate boot controller on the test system.
    2. Connect a hard disk drive to an alternate boot controller on the test system.
    3. Install any drivers necessary for the alternate boot controller.
    4. Install the appropriate operating system onto a 20 GB NTFS partition on the hard disk drive.
    5. Install any HBA drivers that are necessary to connect to or manage the peripheral devices.

  7. At this point you should have the system installed and booting to the test OS
  8. From the Start menu, right-click My Computer, and then select Properties.
  9. Note the amount of RAM that the computer has.
  10. If the test OS is Windows Vista or Windows Longhorn Server, click Advanced System Settings. You may be required to enter Administrative credentials and / or allow the action. Please do so.
  11. On the Advanced tab of the System Properties dialog box, click Settings in the Performance area.
  12. On the Advanced tab of the Performance Options dialog box, click Change in the Virtual Memory area.
  13. Click Custom Size, and in the Initial Size box, enter a number that is larger than the size of the RAM you noted in step 9.

    14. Note: You specify the size of the page file in megabytes (MB). If the amount of RAM on your computer was specified by using gigabytes (GB) or some other measure, convert the amount of RAM to MB before choosing and entering a value for the page file size.

  14. Enter a Maximum Size value that is larger than the initial size. (It is common for the maximum size to be 1.5 to 2 times the initial size.)
  15. Click Set.
  16. Click OK to close the Virtual Memory dialog box.
  17. Click OK to close the Performance Options dialog box.
  18. On the Advanced tab of the System Properties dialog box, click Settings in the Startup and Recovery area.
    1. If the HBA selected for testing the RAID system is bootable and the RAID system supports boot, then, in the Write debugging information area of the Startup and Recovery dialog box, select Small memory dump (64 KB), and then type X:\Minidump in the Small dump directory box, where X is the drive letter of the RAID partition.
    2. If the HBA selected for testing the RAID system is not bootable, or if the RAID system does not support boot, then, in the Write debugging information area of the Startup and Recovery dialog box, select Small memory dump (64 KB), and then type X:\Minidump in the Small dump directory box, where X is the drive letter of a hard disk drive that is connected to an alternate, non-test boot controller in the test computer system.

  19. Click OK to close the Startup and Recovery dialog box.
  20. Click OK to close the System Properties dialog box.
  21. Restart the operating system to update the page file size.
  22. Install the Microsoft Windows Symbols files to the C:\Symbols directory. WHDC: Symbols
  23. From the Start menu, select Run.
  24. Type “diskmgmt.msc” and hit Enter.
    1. If the test OS is Windows Vista or Windows Longhorn Server you may be required to enter Administrative credentials and / or allow the action. Please do so.

  25. If the disks appear as inactive, activate them. Right click the disk and choose Initialize Disk.
  26. Partition and format all disks
    1. Right click each disk and choose Convert to Basic Disk if not basic already.
    2. Right click each disk and choose New Partition.
    3. Each partition should be a Primary Partition, use all of the disk space, use any drive letter, and be formatted in NTFS.

    4. Install DTM Client.
    5. Configure the machine for testing in DTM Studio.
      1. Add the machine to a machine pool.
      2. Deploy the “WDK\ConfigureFibreChannelHardwareBasedRaidSystem” dimension.


Testing SCSI Hardware-based RAID Systems

Open Device Console in DTM Studio.

Create a new submission for “Storage > RAID Storage > Hardware based RAID System > SCSI”.

The test device should not require a driver. Please select “No Driver Files” when prompted.

Make sure to select all of the Disks contained in the array under the Disk Drive node in the device list.

If your device supports any of the following features please indicate by checking the box when prompted: MPIO, VDS, VSS.

Select the tests which you wish to launch, choose Add Selected, and then click schedule.

Crashdump Support Test

Setup: This test requires that the machine has Operating System Symbols installed in c:\symbols (see step 22 of Test System Configuration). This test will automatically install the debugging tools for windows as a setup task.

Troubleshooting: If you encounter a test failure at any point before the final Logging phase of the test, please ensure that you have the correct symbols.

Note: This test will intentionally crash the system. A bugcheck during the test is normal if caused by bugcheck.sys.

Note: This test reboots the system.

More Info:

Data Verification Test

Input: This test accepts a single drive letter and a PCI ID as input. These are both provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

Important: If the RAID system supports Multi-path I/O, then while the test is running, manually disconnect one cable from one of the identical HBAs connected to the RAID system. After the test is complete, reconnect the cable to the RAID system.

Note: This test reboots the system.

IFS Test

Input: This test accepts a single drive letter as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem. The test will reformat this partition and perform a series of operations.

WARNING: Any data saved on the test device will be lost.

Note: This test reboots the system.

More Info:

SCSI Compliance

Input: This test accepts the physical path of the test device as input. This is provided automatically by DTM.

More Info:

Storage Device Stress

Input: This test accepts a string of drive letters as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

Important: If the RAID system supports Multi-path I/O, then while the test is running, manually disconnect one cable from one of the identical HBAs connected to the RAID system. After the test is complete, reconnect the cable to the RAID system.

More Info:

SysCacheTest

Input: This test accepts a single drive letter as input. This is provided automatically by DTM.

Setup: This test requires the device to have a single partition formatted in any filesystem.

More Info:

DR - Device Path Exerciser

More Info:

DR - Sleep Stress with IO

More Info:

DR - Disable Enable with IO

More Info:

DR - Plug and Play Driver Test

More Info:

DR - Stress Test

More Info:

DR - Stress Test with low resource simulation

More Info:

DR - Sleep Stress Disable Enable with IO

More Info:

Multipath I-O Test

Note: This test will only appear if your device supports MPIO and testing in Windows Vista / Longhorn Server:

More Info:

VDSHW-PCI

Note: This test will only appear if your device supports VDS in hardware / driver.

More Info:

VSSHW-PCI

Note: This test will only appear if your device supports VSS in hardware / driver.

More Info:


Troubleshooting SCSI Hardware-based RAID SystemTesting

For information about troubleshooting SCSI Hardware-based RAID System testing, see Troubleshooting Storage Tests.


Storage > Removable Media Testing Overview

The procedures in this section test your Removable Media Device for proper functionality by using the Microsoft Windows Driver Kit (WDK) and the Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as required for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

The test procedures are divided into the following types of topics:

  • Overview: The overview topics describe the hardware, software, and tester knowledge requirements.
  • Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.
  • Running: The running topics describe how to run the tests for your device or system.

Removable Media Device Tests

The tests that you need to run depend on the capabilities of the device or system that is being tested. To see the complete list of tests that could be required for your device, see Removable Media Device Tests.

The following list contains the tests that you might need for your test device:

  • Media Lock Test
  • Anti-Virus/File System Filter Test Kit
  • Syscache Test
  • Storage Device Stress test (SDStress)
  • Device Path Exerciser
  • System - Sleep Stress with IO
  • Disable Enable with IO
  • Plug and Play Driver Test
  • DR - Stress Test
  • Core Stress Test

If the device supports Media Status Notification, you might need the following test:

  • Media Status Notification test

If the device is connected through ATA/ATAPI, you might need the following test:

  • SMART test utility

If the device is connected through SATA, you might need the following test:

  • SATA IO Sig Test

If the device is connected through SCSI, you might need the following test:

  • SCSI Compliance test

If the device is connected through 1394, you might need the following test:

  • 1394 Configuration Tests

If the device is connected through Cardbus, you might need the following tests:

  • CardBus Card Configuration Space Register test
  • CardBus Card Common Silicon Guidelines test
  • CardBus Bridge Power Management Register Test

If your device is connected through USB, you might need the following tests:

  • USB Address Description
  • USB Descriptor Test
  • USB Device Control Requests
  • USB Device Framework (CV)
  • USB Enumeration Stress
  • USB HIDView (CV)
  • USB Selective Suspend
  • USB Serial Number
  • USB Specification Compliance

Run time: approximately <TBD> hours

Note The test descriptions are included in a separate section.

Hardware Requirements

The following hardware is required for Removable Media Device testing. You might need additional hardware if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One test system with the following:
    • Minimum requirements that are published for the test operating system.
    • Logo-compliant ACPI BIOS, with ACPI enabled by default.
    • One host controller with the appropriate bus interface for the test device.
    • If the host controller above is not bootable, one bootable bus controller (for example, a SCSI controller). If the controller is bootable, you do not need an additional controller.
    • One monitor, one keyboard, and one mouse (or any pointing/drawing device).

  • One removable media device (the test device).
  • One DVD/CD-ROM drive (at least 8x speed).
  • One hard disk drive of the same bus type as the bootable controller for the test system, with at least 10 GB capacity.
  • One cable to connect the test device to the host controller.
  • Two blank pieces of media, or the appropriate type for the test device, that are prepared for use.
  • One USB 2.0 high-speed hub, if device is connected through USB.

Software Requirements

The following software is required to run the Removable Media Device tests:

  • One of the following operating systems:
    • Microsoft Windows Vista
    • Microsoft Windows XP Professional with Service Pack 2 (SP2)
    • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
    • Microsoft Windows Server 2003, Datacenter Edition, with SP1
    • Microsoft Windows XP Professional x64 Edition
    • Microsoft Windows Server 2003, Enterprise x64 Edition
    • Microsoft Windows Server 2003, Datacenter x64 Edition
    • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
    • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems
  • Any drivers that are not shipped with the operating system
  • The current release of Microsoft Windows Driver KiT (WDK)

Tester Knowledge Requirements

To run the Removable Media Device tests, testers must know how to accomplish the following tasks:

  • Install the operating system from the product CD.
  • Install and operate the test device.
  • Install DTM Client.
  • Start tests from DTM Studio’s Device Console (Submission mode).

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Preparing to Test Removable Media Devices

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see Storage > Removable Media Testing.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, For more information about autologon, see [image] How to turn on automatic logon in Windows XP.

Test system configuration

  1. Install the appropriate Microsoft Windows operating system.
  2. Install the test device and any accessories. You should not need to install a device driver. If the test device is connected through USB:
    1. Connect the USB 2.0 controller to the High Speed USB 2.0 hub.
    2. Connect the test device to the downstream port of the high-speed USB 2.0 hub.

      Note Do not connect the USB test device directly to the root hub of the USB 2.0 controller.

  3. Install DTM Client.
  4. Configure the machine for testing in DTM Studio.
    1. Add the machine to a machine pool.
    2. Deploy the “WDK\ConfigureRemovableMedia” dimension.


Running the Removable Media Device Tests

To test Removable Media Devices, do the following:

  1. Open Device Console in DTM Studio.
  2. Create a new submission for “Storage > Removable Media”.
    • The test device should not require a driver. Please select “No Driver Files” when you are prompted.
    • Make sure to select your test device under the Disk Drive node in the device list.
  3. Select the tests that you want to start, choose Add Selected, and then click Schedule.

    Important The Media Lock test, the Media Status Notification test, and the SATA IO Sig test require manual user intervention. Please schedule these tests alone and proceed to the test console after scheduling.

IFS Test

Input: This test accepts a single drive letter as input. This driver letter is provided automatically by DTM.

Setup: This test requires the device to have a single partition that is formatted in any file system. The test will reformat this partition and perform a series of operations.

Warning Any data that is saved on the test device will be lost.

More Info:

Storage Device Stress

Input: This test accepts a string of drive letters as input. This string is provided automatically by DTM.

Setup: This test requires the device to have a single partition that is formatted in any file system.

More Info:

SysCacheTest

Input: This test accepts a single drive letter as input. This driver letter is provided automatically by DTM.

Setup: This test requires the device to have a single partition that is formatted in any file system.

More Info:

DR - Device Path Exerciser

More Info:

DR - Sleep Stress with IO

More Info:

DR - Disable Enable with IO

More Info:

DR - Plug and Play Driver Test

More Info:

DR - Stress Test

More Info:

DR - Stress Test with low resource simulation

More Info:

DR - Sleep Stress Disable Enable with IO

More Info:

Media Status Notification Test

Note This test will appear only if your device is connected through ATA and supports Media Status Notification. This test requires the user to manually insert and remove media in the device.

Input: This test accepts a single drive letter as input. This driver letter is provided automatically by DTM.

More Info:

SMART Test

Note This test will appear only if your device is connected through ATA.

Input: This test accepts the physical drive number of the test device as input. This driver letter is provided automatically by DTM.

More Info:

SATA IO Sig Test

Note This test will appear only if your device is connected through SATA. This test requires the user to manually provide certification that the device has passed received SATA IO certification.

Input: This test accepts the Device Instance ID of the test device as input. This ID is provided automatically by DTM.

More Info:

SCSI Compliance

Note This test will appear only if your device is connected through SCSI.

Input: This test accepts the physical path of the test device as input. This path is provided automatically by DTM.

More Info:

1394 Configuration Tests

Note This test will appear only if your device is connected through 1394.

More Info:

CardBus Card Configuration Space Register

Note: This test will appear only if your device is connected through CardBus.

Precaution: Please remove all other CardBus cards before you run this test.

More Info:

CardBus Card Common Silicon Guidelines

Note: This test will appear only if your device is connected through CardBus.

Precaution: Please remove all other CardBus cards before you run this test.

More Info:

CardBus Bridge Power Management Register

Note: This test will appear only if your device is connected through CardBus.

Precaution: Please remove all other CardBus cards before you run this test.

More Info:

USB Address Description

Note This test will appear only if your device is connected through USB.

More Info:

USB Descriptor Test

Note This test will appear only if your device is connected through USB.

More Info:

USB Device Control Requests

Note This test will appear only if your device is connected through USB.

More Info:

USB Device Framework (CV)

Note This test will appear only if your device is connected through USB.

More Info:

USB Enumeration Stress

Note This test will appear only if your device is connected through USB.

More Info:

USB HIDView (CV)

Note This test will appear only if your device is connected through USB.

More Info:

USB Selective Suspend

Note This test will appear only if your device is connected through USB.

More Info:

USB Serial Number

Note This test will appear only if your device is connected through USB.

More Info:

USB Specification Compliance

Note This test will appear only if your device is connected through USB.

More Info:


Troubleshooting Removable Media Device Testing

For more information about troubleshooting Removable Media Device testing, see Troubleshooting Storage Tests.


Storage > Tape Drive Testing Overview

The procedures presented in this section outline the process for testing your Tape Drive for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as requried for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

Tape Drive Tests

The list of test you need to run depend upon the capabilities of the device or system being tested. To see the complete list of tests that could be required for your device, see the Tape Drive Tests.

Tape I/O Test

Device Path Exerciser

System - Sleep Stress with IO

Disable Enable IO

Plug and Play Driver Test

DR - Stress Test

Core Stress Test

System - Sleep Stress with IO

If testing in Windows XP / Server 2003:

NTBackup test

If your device connects via iSCSI:

iSCSI iSNS Compliance Test

iSCSI Mutual CHAP (Target)

iSCSI Oneway CHAP (Target)

iSCSI Ping Test (Target)

iSCSI Digest - Tape (Target)

If you are submitting a driver:

Static Driver Verifier

Prefast for Drivers

Static Driver Verifier

Run Inf Test against a single INF

If your device is connected via 1394:

1394 Configuration Tests

If your device is connected via Cardbus:

CardBus Card Configuration Space Register test

CardBus Card Common Silicon Guidelines test

CardBus Bridge Power Management Register Test

If your device is connected via USB:

USB Address Description

USB Descriptor Test

USB Device Control Requests

USB Device Framework (CV)

USB Enumeration Stress

USB HIDView (CV)

USB Selective Suspend

USB Serial Number

USB Specification Compliance

Run time: approximately 4-8 hours

Hardware requirements

The following hardware is required for Tape Drive testing. Additional hardware may be required if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • One computer with the following:
    • Dual-core or equivalent processor (Windows Vista / XP)
    • Quad-core or equivalent processor (Windows Longhorn Server / Server 2003)
    • 2 GB memory (Windows Vista / XP)
    • 6 GB memory (Windows Longhorn Server / Server 2003)
    • Logo-compliant ACPI BIOS, with ACPI enabled by default
    • One host controller with the appropriate bus interface for the test device
      • If testing an iSCSI Tape Drive, this must be a Gigabit Ethernet adapter.

    • One monitor, one keyboard, and one mouse (or any pointing/drawing device)

  • One tape drive – This is the test device.
  • One DVD/CD-ROM drive, minimum 8X speed.
  • One hard disk drive, minimum capacity 10 GB.
  • One cable to connect test device to host controller.
  • Two blank tape cartridges that are prepared for use.
  • One USB 2.0 high-speed hub if device is connected via USB.

Important: All hardware (except the test device) must be included in the Windows Catalog.

Software requirements

The following software is required to run the Tape Drive tests:

  • One of the following operating systems:
    • Microsoft Windows Vista
    • Microsoft Windows XP Professional with Service Pack 2 (SP2)
    • Microsoft Windows Server 2003, Enterprise Edition, with Service Pack 1 (SP1)
    • Microsoft Windows Server 2003, Datacenter Edition, with SP1
    • Microsoft Windows Server XP Professional x64 Edition
    • Microsoft Windows Server 2003, Enterprise x64 Edition
    • Microsoft Windows Server 2003, Datacenter x64 Edition
    • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems
    • Microsoft Windows Server 2003, Datacenter Edition with SP1 for Itanium-based Systems

  • Any drivers that are not shipped with the operating system
  • The current release of Microsoft WDK
  • If testing an iSCSI Tape Drive
    • The latest version of the Microsoft iSCSI software initiator.
      To download the iSCSI software initiator, search for “iSCSI software initiator” at the [image] Microsoft Download Center.
    • The latest version of the Microsoft iSNS server.
      To download the Microsoft iSNS server, search for “iSNS” at the [image] Microsoft Download Center.
    • The Microsoft .NET Framework Version 1.1, which is available from the [image] Microsoft Download Center.

Tester knowledge requirements

To run the Tape Drive tests, testers must know how to accomplish the following tasks:

  • Read test logs and event logs.
  • Report bugs in a standard bug format.
  • Format and partition a hard disk drive.
  • Prepare a blank tape cartridge for use.
  • Install tape drive and host controller.
  • Install the appropriate Windows operating system from the product CD.
  • Install DTM Client.
  • Launch tests from DTM Studio’s Device Console (Submission mode).
  • If testing an iSCSI Tape Drive:
    • Set up an iSCSI environment and record the IP addresses and target names of the devices
    • Set the secret for oneway and mutual CHAP (if supported)
    • Configure an iSCSI tape drive to use an iSNS server
    • Log on to an iSCSI target device
    • Install the operating system from the product CD.
    • Download and install Microsoft iSCSI software initiator, Microsoft iSNS server, and Microsoft .NET Framework Version 1.1.

Related Links

Windows Marketplace Tested Products List

Windows Debugging Tools

Windows Symbol Files


Preparing to test Tape Drives

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see the Tape Drive Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, see Running with autologon enabled.

Test system configuration

  1. Install the appropriate Microsoft Windows operating system.
  2. Install the test device and any accessories
    • Set the system BIOS to support the S3 state.

    1. If your device connects via PCMCIA / CardBus set the system BIOS to support the S1 and S3 states. If your system does not support the S1 and S3 states simultaneously, set the system BIOS to support the S1 state.

    • If your drive connects via ATA / ATAPI:

    1. Install the tape drive (test device) using a standard ATA/ATAPI cable. You may install the test device as Device 1 or Cable Select Device 1 on the primary ATA/ATAPI channel, or as Device 0, Device 1, Cable Select Device 0, or Cable Select Device 1 on the secondary ATA/ATAPI channel.

    • If your drive connects via iSCSI:

    1. Connect your device to the Gigabit Ethernet Adapter.

    • If your drive connects via SCSI:

    1. Set the SCSI ID on the test device to 6 before installing the tape drive (test device) on the SCSI adapter.

    • If your drive connects via USB:

    1. Connect the USB 2.0 controller to the High Speed USB 2.0 hub.
    2. Connect the test device to the downstream port of the high-speed USB 2.0 hub.

    Note: Do not connect the USB test device directly to the root hub of the USB 2.0 controller.

  3. Install the device driver that is supplied by the manufacturer, if necessary.
    • If your drive connects via iSCSI:

    1. Configure your device through the Microsoft iSCSI Initiator.
    2. Configure the target device to use Challenge Handshake Authentication Protocol (CHAP). You must configure the device to use oneway (target authenticates initiator) CHAP. If your device supports mutual CHAP, also configure the device to use mutual CHAP.

      3. Note: When you configure the device to use CHAP, you must provide a secret that is between 12 and 16 characters long. If you are configuring the device to use both oneway CHAP and mutual CHAP, you must provide different secrets for the target and the initiator.

    3. Log on to the target medium changer.

      4. Important: You must be logged on to the iSCSI target device that is used for testing, or the Logo tests will not work properly.

    4. Install the iSNS software on the test system, and configure the target to use the iSNS server.
    5. If your device supports digest and you are required to configure it, configure the test device to support digest.

  4. Install DTM Client.
  5. Configure the machine for testing in DTM Studio.
    1. Add the machine to a machine pool.
    2. Deploy the “WDK\ConfigureTapeDrive” dimension.


Testing Tape Drives

Open Device Console in DTM Studio.

Create a new submission for “Storage > Tape Drive”.

During the submission make sure to load the same driver you installed on the system in step 3 of Test system configuration.

If you are not loading a driver, make sure to select the Tape Drive under the Tape Drives Node when prompted.

Important: All the iSCSI tests require a configuration file to setup the communication between the HBA (Initiator) and the iSCSI targets. This information includes the CHAP Username, target secret to Logon on to the target, the target name, target IP address, HBA PNPID, etc. This information must be entered in a UI at the time of scheduling the job. This UI will generate the configuration file, which is copied to the client machine during each job. The following screen shot shows the extension UI:

Tape I/O

Input:

This test requires the tape drive number as input. This is provided automatically by DTM.

Setup:

This test requires that media is inserted in the drive.

More Info:

NTBackup

Note: This test will only appear if you are testing in Windows XP / Server 2003.

Input:

This test requires the tape drive number as input. This is provided automatically by DTM.

Setup:

This test requires that media is inserted in the drive.

More Info:

DR - Device Path Exerciser

More Info:

DR - Sleep Stress with IO

More Info:

DR - Disable Enable with IO

More Info:

DR - Plug and Play Driver Test

More Info:

DR - Stress Test

More Info:

DR - Stress Test with low resource simulation

More Info:

DR - Sleep Stress Disable Enable with IO

More Info:

iSCSI Target iSNS Test

Note: This test will only appear if your device is connected via iSCSI.

More Info:

iSCSI Target Mutual CHAP Test

Note: This test will only appear if your device is connected via iSCSI.

More Info:

iSCSI Target Oneway CHAP Test

Note: This test will only appear if your device is connected via iSCSI.

More Info:

iSCSI Target Ping Test

Note: This test will only appear if your device is connected via iSCSI.

More Info:

iSCSI Target Digest Test (Tape)

Note: This test will only appear if your device is connected via iSCSI.

More Info:

DR - Driver Verifier

Note: This test will only appear if you load a driver.

More Info:

DR - Prefast for Drivers Test

Note: This test will only appear if you load a driver.

More Info:

DR - Static Driver Verifier Test

Note: This test will only appear if you load a driver.

More Info:

Run Inf Test against a single INF

Note: This test will only appear if you load a driver.

More Info:

1394 Configuration Tests

Note: This test will only appear if your device is connected via 1394.

More Info:

CardBus Card Configuration Space Register

Note: This test will only appear if your device is connected via CardBus.

Precaution: Please remove all other CardBus cards before running this test.

More Info:

CardBus Card Common Silicon Guidelines

Note: This test will only appear if your device is connected via CardBus.

Precaution: Please remove all other CardBus cards before running this test.

More Info:

CardBus Bridge Power Management Register

Note: This test will only appear if your device is connected via CardBus.

Precaution: Please remove all other CardBus cards before running this test.

More Info:

USB Address Description

Note: This test will only appear if your device is connected via USB.

More Info:

USB Descriptor Test

Note: This test will only appear if your device is connected via USB.

More Info:

USB Device Control Requests

Note: This test will only appear if your device is connected via USB.

More Info:

USB Device Framework (CV)

Note: This test will only appear if your device is connected via USB.

More Info:

USB Enumeration Stress

Note: This test will only appear if your device is connected via USB.

More Info:

USB HIDView (CV)

Note: This test will only appear if your device is connected via USB.

More Info:

USB Selective Suspend

Note: This test will only appear if your device is connected via USB.

More Info:

USB Serial Number

Note: This test will only appear if your device is connected via USB.

More Info:

USB Specification Compliance

Note: This test will only appear if your device is connected via USB.

More Info:


Troubleshooting Tape Drive Testing

For information about troubleshooting tape drive testing, see Troubleshooting Storage Tests.


Troubleshooting Storage Tests

  • Before you create a submission make sure your client is in Ready () Mode. If it is not, right click the machine and choose Change Status > Reset.
  • If you plug in your device and it does not appear in DTM Studio try clicking the refresh button in Device Console before creating a submission. If the device still does not appear, try restarting the client machine.
  • If a job is failing verify the jobs results, and check if the job parameters are getting populated properly.
    • Verify the results.
      1. Select the job in Job Monitor.
      2. Locate the failed entry in Task Execution Status.
      3. If this entry has the Task Type “Run Job”, right-click this entry and choose “Child Job Results”. And continue from step 2.
      4. Right-click the failed entry and choose “View Task Log” to view the test’s log.
      5. If “View Task Log” is not available, try “View Errors”. This is likely due to a failure in launching the test.

    • If the above does not help, ensure that the test is receiving the proper parameters.
      1. Right click on your device and choose View Device XML.
      2. Look for a section at the bottom with the name StorageDevice or StorageHBA.
      3. If this is missing please ensure that you have followed the steps to configure the machine for testing.
      4. If the StorageDevice or StorageHBA section appears, check that the job is getting the correct parameters:
        1. Right click on the job in Job Monitor’s Job Execution Status pane.
        2. Choose View Result Report.
        3. Check the Effective Parameters section at the bottom of the report.
        4. If the parameters are incorrect you may have associated the wrong device with the submission, the device may be installed incorrectly, or the installed driver may be wrong.
        5. If this is empty your submission may be invalid.
        6. Create a new submission and launch the test again.
        7. If the parameters are still empty your client installation may be corrupt.
        8. Delete the machine from the machine pool, uninstall the client
        9. Reinstall the client and configure the machine for testing.

  • If jobs are appearing incorrectly, verify that the logo program dimension is properly deployed to the test machine.
    • Ensure that the “Master Config Job” for your logo program ran and passed.

    • Ensure that the device identification data is correct.
      1. Right click on your device and choose View Device XML.
      2. Look for a section at the bottom with the name StorageDevice.
      3. If this is missing please ensure that you have followed the steps to configure the machine for testing
      4. If the information inside this section appears incorrect, please insure that your device is properly installed with the correct driver.


Storage Tests

Test name Target operating system Test description
Anti-Virus/File System Filter Test Kit Windows Vista
The Installable File System test, IFS test, was designed to test that installable file systems comply with 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 returns 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:

Subsystem Independence

The software layer where the tests take place is at the NT Native Call API (user-mode ntdll.dll), which 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 on the private Microsoft native call interface. The NT Native Call API interface sits below all subsystems in the operating system. 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

Several WIN32 File System Operations 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 of tests) exercises these operations. Some examples of this approach 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 that 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, no easily described failure analysis is available to the developer without also describing WIN32 or NT internal calls. In addition, if unexpected results do occur in the core operating system components, the file system developer would not be able to trace them easily.

Separate Test Groups

A file system driver is usually written by modifying an existing file system or IFS Kit skeleton. Developers can use the IFS test to test portions of their driver before the entire file system driver (FSD) is complete. Testing portions of a driver under development is accomplished by separating the IFS test into groups, which include the relevant set of individual tests. This independence permits specific portions of the new FSD to be tested 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 finish. 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 an 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 returns 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 (for example, 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, results 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

The IFS test helps establish a minimum set of capabilities that a file system driver should support. The tests can be used as a designers’ guide by demonstrating the expected capabilities of their systems. Notes in the documentation of the test help describe what is expected and what capabilities the FSD must have to comply.

Filter Testing

The IFS test can be used to diagnose filter problems. Appendix A in this Help file describes two properties of filters: transparency and coexistence. It details how the IFS test can be used to verify these properties and determine if a filter is negatively affecting a Windows NT system .
Storage Data Verification Filter Test Windows Vista
Windows XP
         The Storage Data Verification Filter test checks the hard disk drive and/or storage controller to ensure that no data corruption occurs.
Storage Data Verification Filter Test Windows Vista
Windows XP
         The Storage Data Verification Filter test checks the hard disk drive and/or storage controller to ensure that no data corruption occurs.
iSCSI Digest - Tape (Target) Windows Vista
         This test verifies that an iSCSI tape/media changer target supports header and data digests as negotiated during the logon phase.
iSCSI Ping Test (Target) Windows Vista
         The iSCSI Ping (Target) test verifies that iSCSI targets can send and receive ping requests.
iSCSI Redirection Test Windows Vista
         The iSCSI Redirection test verifies that a host-bus adapter (HBA) properly handles the target device’s capability to redirect the connection to a different IP address and/or port.
CardBus Bridge Power Management Register Test Windows Vista
Windows XP
         The CardBus Bridge Power Management Register test searches the CardBus Bridge/Card configuration space for each of the CardBus device functions and verifies that the power management registers are correctly implemented.
CardBus Bridge Power Management Register Test Windows Vista
Windows XP
         The CardBus Bridge Power Management Register test searches the CardBus Bridge/Card configuration space for each of the CardBus device functions and verifies that the power management registers are correctly implemented.
iSCSI Boot Firmware Table Test The iSCSI Boot Firmware Table (iBFT) is a block of information residing in memory that contains different entries that are required by the iSCSI Boot process.

iSCSI Boot Firmware Table test (iBFTest) verifies the presence of iBFT on the system. It also ensures that the various entries of the table are compliant with the iBFT specification.
Multi-Path I/O Test Windows Vista
Windows 2000
Customers of enterprise storage solutions rely heavily on the high-availability of its components. In storage, high-availability is often implemented by redundancy. Multi-path I/O is one such implementation for the fabric layer of an enterprise storage solution. Microsoft supports multi-path I/O with inbox Multi-Path driver (mpio.sys) and Device Specific Module (msdsm.sys) on Microsoft Windows Advanced Server operating system in the Windows Vista timeframe.
The tool provides multi-path I/O testing for the compatibility of vendor's storage solution with Microsoft driver solutions. These features include:
  1. Failover
  2. Failback
  3. Load balance policy
Multi-Path I/O Test Windows Vista
Windows 2000
Customers of enterprise storage solutions rely heavily on the high-availability of its components. In storage, high-availability is often implemented by redundancy. Multi-path I/O is one such implementation for the fabric layer of an enterprise storage solution. Microsoft supports multi-path I/O with inbox Multi-Path driver (mpio.sys) and Device Specific Module (msdsm.sys) on Microsoft Windows Advanced Server operating system in the Windows Vista timeframe.
The tool provides multi-path I/O testing for the compatibility of vendor's storage solution with Microsoft driver solutions. These features include:
  1. Failover
  2. Failback
  3. Load balance policy
iSCSI Digest - Disk (Target) Windows Vista
         This test verifies that an iSCSI disk storage system supports header and data digests as negotiated during the logon phase.
iSCSI Mutual CHAP (Target) Windows Vista
         The iSCSI Mutual CHAP (Target) test verifies that the target device (disk, tape, or optical storage device) can use the Challenge Handshake Authentication Protocol (CHAP) authentication mechanism.
Media Lock Test Windows Vista
Windows XP
         This user mode application will test the functionality of locking mechanisms on SCSI removable devices of type CD-ROM and direct access (e.g. Iomega Jaz, Zip drive) by issuing SCSI passthrough commands Prevent/Allow medium removal.
MMC Test Windows Vista
Windows XP
This test validates a device's compliance with the MMC-1, MMC-2, MMC-3 and SFF-8090i (Mt. Fuji) standards as the basis for supporting CD-ROM, DVD-ROM, CD-RW, CD-R, and DVD-RAM devices.
Hybrid Disk Logo test Windows Vista
         This test validates and verifies if the hybrid disk drive is in compliance with the standards and achieve the performance and power management requirements
SMART test utility Windows Vista
Windows XP
1) Verify each S.M.A.R.T. command by issuing the commands to the drive
2) issue SMART commands in random order and random number of times
Symlink Regressions Windows Vista
         This test will run several variations containing symbolic links. It will require the input of a source path and a target path. The source path must be on an NTFS volume.
iSCSI WMI Verification Windows Vista
         This test verifies that an iSCSI host-bus adapter (HBA) driver implements the required Microsoft Windows Management Instrumentation (WMI) interfaces. To qualify for the "Designed for Windows" logo, iSCSI HBA drivers must support the WMI classes documented in the iSCSI Driver Development Kit (DDK) version 1.0.
NTFS File Security Test Windows Vista
         This test performs basic NTFS security variations to ensure that there are no regressions in this area.
iSCSI Persistent Login Test Windows Vista
         The iSCSI Persistent Login test verifies the basic functionality of persistent logons, and verifies that targets are logged on every time the operating system restarts.
Medium changer stress Windows Vista
Windows XP
         The target component for this test utility is the medium changer device and driver and its interoperation with Removable Storage Management (RSM). This test stresses various RSM calls and verifies that the device responds as expected.
DMA Test Windows Vista
Windows XP
         The DMA test checks the ability of a driver to set a specified DMA (Direct Memory Access) timing mode for a device. The test checks that the driver can do so while I/O is pending without corrupting the transfer.
iSCSI Ping Test (HBA) Windows Vista
         The iSCSI Ping (HBA) test verifies that iSCSI initiators (HBA) can send and receive ping requests.
Crashdump Support Test Windows Vista
Windows XP
The OS supports the creation of memory dump file after a system stop error through the underlying storage miniport driver. The target component for this test utility is the storage miniport driver. During a system crash, the storage miniport will be called by the OS crash dump components to write memory contents to the physical disk.
The goal of the test is to verify that the storage miniport writes data to the disk correctly and that a valid memory dump file gets generated after a system crash. The Windows OS allows three different types of memory dump files to be generated: full, kernel, and mini. The test will test all three dump file types. For further information about these dump file types, please refer to the Microsoft Kernel Debugger documentation.
SCSI Compliance test Windows Vista
Windows XP
Windows 2000
This test verifies that a SCSI device supported by the operating system fully complies with the SCSI standards described in the SCSI-3 Primary Commands (SPC), SPC-2, and SCSI Block Commands (SBC) specifications (to obtain these specifications, see the T10 Technical Committee Web site at www.t10.org ). Ensuring that the SCSI device and the operating system maintain compliance with these standards makes for a more robust and reliable system.
The test uses SCSI pass-through requests (IOCTL_SCSI_PASS_THROUGH) to construct and send SCSI command descriptor blocks (CDB) to the device. The test evaluates the results of the commands to verify compliance.
Storage Device Stress test (SDStress) Windows Vista
Windows XP
         This test stresses the hard disk drives and CD-ROM drives in a system and validates storage API commands.
Storage Device Stress test (SDStress) Windows Vista
Windows XP
         This test stresses the hard disk drives and CD-ROM drives in a system and validates storage API commands.
HBA API Test Windows Vista
Windows XP
         The HBA API Compliance test verifies the Windows Management Instrumentation (WMI) interfaces that are implemented by a host bus adapter (HBA) driver for support of the Storage Networking Industry Association's Common HBA API. To qualify for the “Designed for Windows” logo, Fibre Channel and SAS Storport miniport drivers and SCSI miniport drivers must support the HBA API.
CardBus Card Configuration Space Register test Windows Vista
Windows XP
         This test determines the correct implementation of the CardBus card’s configuration space support registers.
CardBus Card Configuration Space Register test Windows Vista
Windows XP
         This test determines the correct implementation of the CardBus card’s configuration space support registers.
SCSI Initiator Client Server Windows Vista
Windows XP
Windows 2000
         This test verifies the functionality necessary for Microsoft Cluster Server (MSCS) to change and maintain ownership of the RAID storage disks in the cluster client node. It also verifies the functionality

necessary for multi-initiator host bus adapter (HBA) implementations.
Medium Changer Test Windows Vista
Windows XP
         This test verifies that a media changer meets performance standards by passing various packet commands to the media changer.
Media Status Notification test Windows Vista
Windows XP
         This is the Media Status Notification specification v1.03 test. This test contains two scenarios, one to test the ejectability of a device, the second to test the media status bits.
iSCSI Oneway CHAP (Target) Windows Vista
         The iSCSI Oneway CHAP (Target) test verifies that the target device (disk, tape, or optical storage device) can use the Challenge Handshake Authentication Protocol (CHAP) authentication mechanism.
Tape I/O Test Windows Vista
Windows XP
         The target component for this test utility is the tape drive and driver. This test writes to and reads from the tape to verify that the tape drive is operating properly.
SATA IO Sig Test Windows Vista
Windows XP
         This test is designed to collect the SATA IO Signature certification from the user.
SATA IO Sig Test Windows Vista
Windows XP
         This test is designed to collect the SATA IO Signature certification from the user.
NTBackup test Windows XP
The target component for this test utility is the tape drive and driver and its interoperation with the NTBackup application. This test backs up and restores generated data and verifies that the copies match.
iSCSI iSNS Compliance Test Windows Vista
         The iSCSI iSNS Compliance test verifies that target devices (for example, disk, tape, and media changer devices) can properly register with and be discovered by an Internet Storage Name Service (iSNS) server.
iSCSI Digest - Tape (HBA) Windows Vista
         This test verifies that the host-bus adapter (HBA) supports header and data digests as negotiated during the logon phase.
iSCSI HBA Oneway CHAP Windows Vista
         The iSCSI HBA Oneway CHAP test verifies that the initiator, that is, the host system that initiates the block storage transfer, can use the Challenge Handshake Authentication Protocol (CHAP) authentication mechanism. The test verifies one-way CHAP.
iSCSI HBA Mutual CHAP Windows Vista
         The iSCSI HBA Mutual CHAP test verifies that the initiator, that is, the host system that initiates the block storage transfer, can use the Challenge Handshake Authentication Protocol (CHAP) authentication mechanism. The test verifies mutual CHAP.
iSCSI Boot Windows Vista
         The test verifies that the host-bus adapter (HBA) properly reports the presence of a boot session to the Microsoft iSCSI initiator service.
UDF Formatter Tests Windows Vista
The UDF Formatter Tests are used to verify that a device can format all of its supported media types as a UDF volume.
WMDM Content Transfer Test Windows Vista
         This test verifies that WMA content can be transferred to the device you are testing by using WMDM API.
CardBus Card Common Silicon Guidelines test Windows Vista
Windows XP
This test determines whether the CardBus card’s configuration space supports the Common Silicon Guidelines as described in PC Card Standard Guidelines, Volume 10.
CardBus Card Common Silicon Guidelines test Windows Vista
Windows XP
This test determines whether the CardBus card’s configuration space supports the Common Silicon Guidelines as described in PC Card Standard Guidelines, Volume 10.
Int 13h Extensions test Windows Vista
Windows XP
Windows 2000
The Int 13h Extensions test verifies proper implementation of the Phoenix Int 13h extensions.
iSCSI Digest - Disk (HBA) Windows Vista
         This test verifies that the host-bus adapter (HBA) supports header and data digests as negotiated during the logon phase.


Anti-Virus/File System Filter Test Kit

Overview

The Installable File System test, IFS test, was designed to test that installable file systems comply with 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 returns 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:

Subsystem Independence

The software layer where the tests take place is at the NT Native Call API (user-mode ntdll.dll), which 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 on the private Microsoft native call interface. The NT Native Call API interface sits below all subsystems in the operating system. 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

Several WIN32 File System Operations 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 of tests) exercises these operations. Some examples of this approach 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 that 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, no easily described failure analysis is available to the developer without also describing WIN32 or NT internal calls. In addition, if unexpected results do occur in the core operating system components, the file system developer would not be able to trace them easily.

Separate Test Groups

A file system driver is usually written by modifying an existing file system or IFS Kit skeleton. Developers can use the IFS test to test portions of their driver before the entire file system driver (FSD) is complete. Testing portions of a driver under development is accomplished by separating the IFS test into groups, which include the relevant set of individual tests. This independence permits specific portions of the new FSD to be tested 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 finish. 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 an 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 returns 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 (for example, 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, results 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

The IFS test helps establish a minimum set of capabilities that a file system driver should support. The tests can be used as a designers’ guide by demonstrating the expected capabilities of their systems. Notes in the documentation of the test help describe what is expected and what capabilities the FSD must have to comply.

Filter Testing

The IFS test can be used to diagnose filter problems. Appendix A in this Help file describes two properties of filters: transparency and coexistence. It details how the IFS test can be used to verify these properties and determine if a filter is negatively affecting a Windows NT system .

Details

Below is a description of what each test does in detail.

OpenCreateGeneral File System Test Group

The tests in this group include:

CreatePagingFileTest

The CreatePagingFile test creates a paging file and uses 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 minimal access.

FileNameLengthTest

Each file system supports different lengths of file names. File-name length is determined by internal representations. The maximum component name length obtained from the AttributeInformationTest is used to determine the longest file name that the file system supports. This value is used to form file names that are less than, equal to, and greater than the maximum. The create file function tests the different file names. When the file names 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

HFHTest tests the parsing of the double backslash when it is used as a prefix for a file name 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 being tested. 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 being tested. 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 by using the query volume information function. This flag indicates that the file system will store the Unicode representation of the file name on the disk. Several files are created using the create file function call. These file names contain Unicode characters. Several valid and invalid Unicode characters are used in the file name. 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 file names are checked to see if the Unicode representation has been stored. All invalid Unicode characters in the code page should be returned as question marks (?).

CaseSensitiveTest

The case sensitive search volume attribute flag can be obtained by using the query volume information function. This flag indicates that the file system differentiates between file names that differ only in case. That is, when two file names are identical except for case, they are considered different files. This is verified by using the create file function with several file names that differ only in case. Each file is filled with different data. The files are then opened with the file names, 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 file names differ only by case.

PreserveCaseTest

The case preserved names volume attribute flag can be obtained by using the query volume information function. This flag indicates that the file system preserves the case of different file names. That is, when a file is created with a mixed-case file name, the directory contents, when queried, return file names that reflect the original mixed case. This is verified by using the create file function call with several file names that have mixed case. The directory is then queried. The returned file names 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 MS-DOS-compatible 8.3 format (an eight-character name with a three-character file extension). Long names are defined as any file names 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 file name. The 8.3 representation may be created when extended characters are used in the file name. This short name representation can be used to access the file with the same way that the long file name does. This capability is verified by using the create file function with several long file names and several file names that use extended characters. The directory is then queried. The returned short and long file names are checked to see if the short names have been properly created for the files. The file is then accessed with the short name. This access should be successful.

ShareAccessTest

The share access of a handle can be specified at the time a file is created. This access determines if subsequent attempt to open the same file are allowed to succeed. A file is first created with read attributes desired access and no share parameters set. Creating a file in this way allows only query operations.
The file is created with the create file function. Four subsequent attempts to open the file are made 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 calls should both fail because sharing is not allowed for these options. A third call specifies zero for the access parameters, but it specifies the delete-on-close create option; this call should also fail with an access-denied error. The last call is made with a zero for the access parameters and read attributes for the create options. This call should succeed because queries are allowed. This test is verified by specifying the share parameters separately. The pass/fail result of the create file function verifies that the share control operates correctly. These tests are repeated for directories and DASD handles, the same results apply.

AlternateStreamTest

NTFS supports alternate data streams. The alternate streams can be opened/created by specifying the file name as in the normal open/create tests but following the name with a colon (:) and the name of the alternate stream. A test file is created by using the create file function, and data is written to the file. The test file name is appended with the string :stream1 and the alternate data stream is opened by 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 are open for reading. The data is verified. An attempt is then made to open data streams that 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 opening another handle on the same file. A single stream in a file that contains multiple streams is first opened with the read attributes desired access and no share parameters set. This allows only 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 calls should both fail since sharing is not allowed. A third call specifies zero for the access parameters, but it specifies the delete-on-close create option. This call should also fail. The last call is made with a zero for the access parameters and read attributes for the create options. This call 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 that the share control operates correctly.

FileSystemDeviceOpenTest

The FSD test creates a device object in the root directory of the Windows NT object namespace (for example, \Fat, \Ntfs). This action tests that the device object can be opened and, therefore, it verifies that the device object exists. 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 in order to pass the test.

FileFullPathCreationTest

A fully qualified file name 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 file name. The file name that is appended to this path is formed within the upper bound of the maximum component name length. The file is verified to be nonexistent by a call to the create file function with the file open disposition. This call 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 call 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 directory is verified to be nonexistent 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. Creation of the directory is also tested with the temporary attribute set in the call to the create file function. This call 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 file name. 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 file name 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 path should fail since faketestdir does not exist. The above directory creation is tested with a path that does exist (realtestdir instead of faketestdir). This path should succeed.

FileRelativePathCreationTest

Files can be accessed by going through the handle of an open directory. This is considered a relative path access because 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 file name is created within the upper bound of the maximum component length. Only the file name is passed into the create file function because no qualifying path is necessary.
A handle to a test directory is opened. The file is verified to be nonexistent by a call to the create file function with the file open disposition; this call 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 include 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 directory is verified to be nonexistent 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 instruction should fail because 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 call 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 attempt to create a test directory is repeated, but the directory name specified is modified to include a leading backslash. This operation should fail with an 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 eight bytes are passed into a call to the create file function in place of the file name. 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 nondirectory 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 Direct Access to Storage Device (DASD) opening. This allows for opening the “\DosDevices\?: volume device; where ?: is the name of the drive letter mapped to the volume being tested. When 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 a new file is created on the volume. The desired access is not a concern. This test is intended to maintain an open handle. Next an attempt is made to open the volume. Since the share access is 0, no open handles can exist on the volume. The test checks to see that the sharing violation error came back. Next the test tries to open the volume for reading. Even though there is only one handle open and that is a read-only handle, the operation should fail with a sharing violation error. Next, the test tries to open the volume with the file share read disposition on the share access. Because only one, read-only handle is open, this operation should succeed. Next, two DASD opens are attempted, the first should succeed and the second should fail with an access-denied error.

OpenCreateParameters File System Test Group

The tests in this group include:

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 that are currently set on the existing file. New attributes are joined with the OR operator 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 file name that does not exist. This operation should succeed. Next, the file create function is used with the file overwrite function on a file name that does exist. This operation should return a file-overwritten status. The file is then read and should 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 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 that are currently set on the existing file. New attributes are joined with the OR operator 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 file name that does not exist; this operation should succeed. Next the file create function is used with the file overwrite function on a file name that does exist; this operation should return a file overwritten status. The file is then read and should 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 on a read-only file; now when the file create function is called, the test should fail with an 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 file name that does not exist; this call should succeed. Next the file create function is called with the file supersede disposition on a file name that does exist; this call 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 succeed since it is overwriting the file anyway.

ReadOnlyAttributeTest

The attributes of a file can be set when the file is created. 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 write attempt should fail with an invalid-user-buffer error. Next a read is attempted on the test file; this read attempt 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 when the file was created; this test should fail with an access-denied error.

SystemAttributeTest

The attributes of a file can be set when the file is created. If the system attribute is set on a file, the file reflects 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 operation should 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 operation should succeed.

CreateFileTest

The file create disposition does not allow an existing file to be opened. This disposition creates 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 file 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 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 file name 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 file name 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 file name 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 file name that exists and contains data, this should return a success message and a file overwritten status. The file is read and no data should be found 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 file 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 file 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 file name 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 file name that exists and contains data; this should return a success message and a file overwritten status. The file is read 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. The allocation size 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 based on the file system and volume. 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 allowed for the volume. Then a file is created with no allocation size specified. The default allocation size should be zero, and this result 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 file 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 reflects 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 when the file is created. If the normal attribute is set on a file, the file reflects 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 reflects this attribute information with the query directory file. A test directory is created and the query directory function is called on the directory that contains 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 it returns an error if the directory already exists.
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 when the file is created. 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 any time 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 called again to verify that the archive bit is set.

CloseCleanupDelete File System Test Group

The following tests are included in this group:

VolumeUnlockOnCloseTest

The volume can be opened directly for Direct Access to Storage Device (DASD) access.Input/output (I/O) buffers must subsequently be 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 the 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 open a file. The operation is verified to fail as a result of the locked volume. The handle to the open volume is then closed. When the DASD handle is closed, the volume should release the volume lock. This result is tested by attempting to open a file again. 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 handles on the file are open, changes that have been made to the file time, attribute, end-of-file pointer, and allocation size information may differ from 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 action sends out an IRP_MJ_CLEANUP.
This test first creates a number of files, verifies the file information by using 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 by using an IRP_MJ_SET_INFORMATION. The information that was updated by using the set information IRP is verified when the file handles are closed. The test verified that 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 subdirectory contained in that directory and obtain the File times, attributes, end-of-file pointer, and allocation size of the subdirectory. The end-of-file pointer and allocation size should be returned as zero. If handles are open on the subdirectory, there may be a difference between changes that have been made to the subdirectory, 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 subdirectories). The information is updated when the last open handle to the file object (for the subdirectory) is closed. This sends out an IRP_MJ_CLEANUP.
This test first creates a number of subdirectories, verifies the file information by way of a container directory handle and queries. The subdirectories are then opened, access by listing, and modified by creating files inside of those test subdirectories. The file information is again queried and checked to see that it has not been updated. The subdirectory 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. The allocation size is reduced when IRP_MJ_CLEANUP is sent to the file system. This corresponds to close of the last open handle to a file object.
This allocation size reduction is tested with a file whose allocation size is set at creation time. The file is then written with a much smaller amount of data than 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 8.3 format. Both FAT and NTFS file systems have two 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-specific and directory-specific. When a file is deleted and created again using its short name only, the long name is re-applied to the file.
This test first opens a test directory. The directory handle is then used to create several files with long names 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 by 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. There are two mechanisms for marking a file for deletion. 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 to be deleted on close. These two mechanisms have different semantics.
The following rules describe 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 (that is, 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 returns 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 again becomes 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.

VolumeInformation File System Test Group

The tests in this group include:

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 was changed, then the original volume label is restored and the test is complete. The test is run three more times to test certain error conditions. First, an attempt is made to change the volume label with a directory or file handle. This attempt should return an access-denied error. Second, an attempt is made to set the volume label to a string that is more than 32 Unicode characters long. This attempt should return a invalid volume label error. Third, an attempt is made 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 three 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.

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 one byte allocates the allocation unit size on the volume. This information is verified here and is used in other tests. This test is run three times, opening up a volume handle, directory handle, and 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 three times, opening up a volume handle, directory handle, and file handle. Each handle is then queried for volume device information and the following fields are 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 three 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.

FileInformation File System Test Group

The tests in this group include:

AllInformationTest

The basic information, standard information, internal information, extended attribute (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 file name, long file name length, and current byte offset. All these values are compared to the known values obtained when the file or directory is created. 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, but 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 when the file was created. Then the allocation size is reduced, which should truncate the file. A query is performed to make sure the allocation size was reduced. If the size was reduced, then the allocation size is even further reduced and another query is performed to make sure the size decreased. 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 is passed.

ZeroAllocationInformationTest

A test file that has an allocation size of zero is opened. Then 1000 bytes of data are written to this. A query is then performed to obtain the allocation size, which 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. A file is deleted when a flag is set in the file object. The file can also be flagged to be deleted on close when the file is created. 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, and then the file handle is closed. Next an attempt is made to open the deleted file. If this action fails, it has verified that the file was deleted.

EndOfFileInformationTest

The end-of-file position can be changed. The end-of-file position 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 because the granularity of allocation in the file system is usually a power of 2 sectors. In this test, the original size of the file when it was created is checked, and then the end is moved towards the beginning of the file. The allocation size is checked to make sure it was 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

This test checks that hard links to an open file can be created. When the file is opened with the linked file name, the data and queried information in the file should look identical to the original file. 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 by using the link. The data in the file is read and compared with 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 or 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 nonexistent file name. The same is done with a directory. Next, an attempt is made to rename 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 test file is opened and an attempt is made to rename the file to an existing file name. If the file attribute, Replace If Exists, is set, then a file can be renamed to an existing file name; otherwise, an error is recorded. When the test file or directory is renamed to an existing file name (Replace If Exists not set) an invalid parameter error occurs. This rename process is attempted again but with the Replace If Exists flag set. This operation should succeed. Next, a second test file is opened twice (two handles are opened to the same file). A file rename is attempted on both handles, and both attempts should return an access-denied error.

AlternateNameInformationTest

The long name can be used to obtain the 8.3 file name with a query call. A file name that is more than 15 characters is opened, and data is written to the file. The file is queried to obtain its 8.3 name. The handle to the file is then closed. The file is reopened using the 8.3 name from the query. The data from the file is read and verified to ensure 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 when the file is created. It also includes all the time stamps 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 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. Verification is done to make sure that the two index numbers match. If they match, the test is successful.

EaInformationTest

The extended attribute size on the file can be queried. This is the size of the extended attribute information stored 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 file name and the length of the file name. A file handle or directory handle is opened and a query is performed to obtain the long file name and the file name length. The long file name is compared to the file name 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 file name data; this is done to see if a buffer overflow error is returned by the query.

EaInformation File System Test Group

The tests in this group include:

FullEaInformationTest

All of the extended attribute (EA) information for a file can be accessed at once. The test file used for this test has three extended attributes each with four bytes of data. This file is opened with access privileges that permits its EA data to be read. The file is queried to read out all the EA entries associated with this file at once. The data and labels that are returned are verified.

ListEaInformationTest

The EA information can be selectively queried based on a list of EA names. The test file used for this test has three EAs, each with four 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 is created with a label to just the third entry, 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 EA information can be selectively queried based on an index value. The test file used for this test has three Extended Attributes each with four bytes of data. The file is opened with access privileges that permit its EA data to be read. A query is performed that specifically indexes 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 query is done for the first EA entry.

CreateEaInformationTest

The EA information for a file can be specified at creation time. The test file used for this test has one Extended Attribute with four 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 is passed.

SetEaInformationTest

The EA information for a file can be set after the file is created. The first part of the test uses a file that has no EAs associated with it. This file is opened with access privileges that permit 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 four bytes of data. Next the existing EA is replaced with new data values, but the label is still the same. The file is queried again to check to see 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 EA with four bytes of data associated with it.

SingleEaEntryTest

The EA information for a file can be read back one entry at a time. The test file used for this test has three EAs, each with four bytes of data associated with it. This file is opened with access privileges that permit 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 operation is done two more times to verify the second and third EA entries, but these scans are not done from the start of the EA entries block for these two iterations. The scans are done from after the last EA entry that was queried.

DirectoryInformation File System Test Group

The tests in this group include:

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 operation should update the last access time, last write time, and change time of the file after the file is closed. 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 file names and file name 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 the file is closed. 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.

FileLocking File System Test Group

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 obtains 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 two 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.

OpLocks File System Test Group

The tests in this group include:

BatchOplocksTest

The batch oplock is operationally equivalent to a level 1 op lock (that is, 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 expectation that a client will need it again. But if there is a reason for the file system to close the file, the system will close it.
  1. C opens a test file for reading.
  2. C requests a batch oplock on the file by using the FSCTL_REQUEST_BATCH_OPLOCK file control.
  3. C should succeed at reading the file.
  4. D opens the test file for reading and writing, but this action should be blocked because a break is pending.
  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.
  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.
  1. C opens a test file for reading and writing.
  2. C requests a Level I oplock on the file using the FSCTL_REQUEST_OPLOCK_LEVEL_I file control.
  3. The file should be written to and read from by C, this should succeed
  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.
  5. The IRP from step 2 should complete.
  6. The FSCTL_OPLOCK_BREAK_NOTIFY control should be sent. This IRP should be queued since there is a break in progress.
  7. C issues the FSCTL_OPLOCK_BREAK_ACKNOWLEDGE control. This will acknowledge the break to a level II lock.
  8. The IRP from step 6 should now complete indicating that there is now no break in progress.
  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.
  1. A opens a file and requests a Level I oplock.
  2. B opens the same file with the FILE_COMPLETE_IF_OPLOCKED option set.
  3. The call should complete normally with FILE_OPLOCK_BREAK_UNDERWAY in the Information field regardless of the final Status of the create operation.
  4. The Oplock IRP from Step 1 should complete.
  5. The same open should be attempted without the option.
  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.
  1. C opens a test file for reading and writing.
  2. D opens the same test file for reading and writing.
  3. C requests a Level II oplock on the file with the FSCTL_REQUEST_OPLOCK_LEVEL_II file control.
  4. The file should be read by C, this should succeed.
  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.
  6. The IRP from step 3 should complete.

OplockLevel1Test

This tests that Level I oplocks are exclusive.
  1. C opens a test file for reading and writing.
  2. D opens the same test file for reading and writing.
  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.
  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:
  1. C opens a test file for reading and writing.
  2. D opens the same test file for reading and writing.
  3. C requests a Level II oplock on the file with the FSCTL_REQUEST_OPLOCK_LEVEL2 file control.
  4. The file should be read from by C, this should succeed.
  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.
  6. The IRP from step 3 should complete.
  7. The set information operation from step 5 should now become unblocked and complete successfully.
  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:
  1. Process C requests a Level II oplock on the file and receives back STATUS_PENDING indicating that the oplock has been granted.
  2. The file should read from by C, this should succeed.
  3. Process D attempts to lock a range of the file using NtLockFile(). This thread (of Process D) should block.
  4. The IRP obtained in step 1 should complete with FILE_OPLOCK_BROKEN_TO_NONE.
  5. The NtLockFile() call from step 3 should now complete.
  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.
  1. C opens an asynchronous handle to a test file for reading and writing.
  2. C requests a Level I oplock on the file and receives STATUS_PENDING
  3. The file should be written to and read from by C, this should succeed.
  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.
  5. The IRP from step 2 should complete with FILE_OPLOCK_BROKEN_TO_LEVEL_2.
  6. C issues the FSCTL_OPLOCK_BREAK_ACKNOWLEDGE control. This will acknowledge the break to a level II lock.
  7. The blocked open from step 4 should now become unblocked.
  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.
  9. C should be able to read from the test file without the level II oplock breaking.
  10. D should 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.
  11. The IRP from step 6 should complete.

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.
  1. C opens a test file for reading and writing.
  2. C requests a Level I oplock on the file.
  3. The file should be written to and read from by C, this should succeed.
  4. C closes the file.
  5. The IRP from step 2 should complete indicating the Level I oplock is broken. The Information will show FILE_OPLOCK_BROKEN_TO_NONE.
  6. D opens the same test file for reading and writing. This should not block since the oplock has been deleted from the system.
  7. D requests and receives a Level II oplock on the file.
  8. The file should be read from by D. This should succeed.
  9. D closes the file.
  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.
  1. C opens a test file for reading and writing.
  2. C requests a Level II oplock on the file using the FSCTL_REQUEST_OPLOCK_LEVEL_II control operation.
  3. The file should be read from by C, this should succeed.
  4. D opens a test file for reading and writing.
  5. D requests a Level II oplock on the file using the FSCTL_REQUEST_OPLOCK_LEVEL_II control operation.
  6. C should be able to do cached reads from the file.
  7. D should be able to do cached reads from the file.
  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.
  1. C opens a test file for reading and writing.
  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 should block since the file has an open oplock.
  5. The level II oplock obtained in step 2 will be broken.
  6. The blocked open from step 4 should now become unblocked.
  7. C and D close the file.

ChangeNotification File System Test Group

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

This tests the original DACL is reset to allow the test file to be deleted during cleanup. All notification events should complete.

NotificationCleanupFileSizeTest

This tests the original DACL is reset to allow the test file to be file size returned during cleanup. All notification events should complete.

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 file names 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

This tests the flushing of the cache before the volume is locked.

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.

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 being tested. 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.

FileSystemControlVolume File System Test Group

The tests in this group include:

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 file open operation 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

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

The file system control checks that 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 attempt should fail because a file handle is open. If this attempt succeeds, the volume handle and file handles are closed. See the steps in the ControlLockVolumetest

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

Tests the flushing of the cache before the volume is locked. Data is written to the file. Statistics on the volume are obtained. 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.

FileSystemControlGeneral File System Test Group

The tests in this group include:

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 file system 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 (1 Mbyte) 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 an 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.

ReadWrite File System Test Group

Note In the HCT kit, this test is called the SysCache test.

The tests in this group include:

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, an 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

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.

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.

SectionsCaching File System Test Group

The tests in this group include:

ExtendingWithUserMappingTest

A file can be extended when a user mapping exists. The new extended region should be initialized with 0's.
  1. A test file is opened, a user mapped section is created, and a view created.
  2. The file handle is closed.
  3. The test file is again opened with a call to NtCreateFile() with the FILE_WRITE_DATA and FILE_READ_DATA desired access specified.
  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.
  5. The Set Information File call should succeed.
  6. Another view is created on the extended region.
  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 test 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.
  1. A test file is opened.
  2. A user mapped section/mapped view are created with the open handle.
  3. The handle is closed.
  4. A view on the section is used to verify the file contents are still accessible.
  5. Another attempt is made at opening the test file with 0 share access (nothing is shared).
  6. Write some data to the opened test file.
  7. Verify the written data is present in the mapped section.
  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.
  1. A known working executable is opened for reading.
  2. A new file is created with write access (file name = temp.exe).
  3. The contents of the first file are copied into the new file with NtReadFile() and NtWriteFile().
  4. The handles to the files are closed.
  5. The temp.exe executable file is run as in the WIN32 CreateProcess call.
  6. Proper execution of the file is verified, as well as the flush of dirty data to the disk.

ExistingUserMappingTest

A file cannot be superseded or overwritten when a view on a user mapping exists.
  1. A test file is opened, a user mapped section is created, and a view mapped.
  2. The handle to the test file is closed.
  3. The test file is again opened with a call to NtCreateFile(). The FILE_OVERWRITE disposition is specified.
  4. The open should fail with STATUS_USER_MAPPED_FILE.
  5. The test file is again opened with a call to NtCreateFile(). The FILE_SUPERSEDE disposition is specified.
  6. The open should also fail with STATUS_USER_MAPPED_FILE.

TruncateWithUserMappingTest

A file cannot be truncated when a user mapping exists.
  1. A test file is opened; a user mapped section is created, and a view is created.
  2. The handle to the test file is closed.
  3. The test file is again opened with a call to NtCreateFile() with the FILE_WRITE_DATA access right specified.
  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.
  5. The Set Information File call should return the error STATUS_USER_MAPPED_FILE.
  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.

Security File System Test Group

The tests in this group include:

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.

ObjectID File System Test Group

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:

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
FILE_ACTION_REMOVED
FILE_ACTION_REMOVED_BY_DELETE
FILE_ACTION_ID_NOT_TUNNELLED
FILE_ACTION_TUNNELLED_ID_COLLISION
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 tunneled (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
FILE_ACTION_REMOVED
FILE_ACTION_REMOVED_BY_DELETE
FILE_ACTION_ID_NOT_TUNNELLED
FILE_ACTION_TUNNELLED_ID_COLLISION
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
FILE_ACTION_REMOVED
FILE_ACTION_REMOVED_BY_DELETE
FILE_ACTION_ID_NOT_TUNNELLED
FILE_ACTION_TUNNELLED_ID_COLLISION
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
FILE_ACTION_REMOVED
FILE_ACTION_REMOVED_BY_DELETE
FILE_ACTION_ID_NOT_TUNNELLED
FILE_ACTION_TUNNELLED_ID_COLLISION
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
FILE_ACTION_REMOVED
FILE_ACTION_REMOVED_BY_DELETE
FILE_ACTION_ID_NOT_TUNNELLED
FILE_ACTION_TUNNELLED_ID_COLLISION
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.

MountPoints File System Test Group

The tests in this group include:

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.

ReparsePoints File System Test Group

The tests in this group include:

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 no prior 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 systems 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 the FileAttributeTagInformation 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 directory 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.
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 the status code 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 directory 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 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 that 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 is expected to fail with STATUS_EAS_NOT_SUPPORTED on NTFS5-compatible file systems because reparse points and extended attributes are mutually exclusive.

SetPointAccessDeniedTest

This test validates that the File System is not be able to set reparse points on files and directories with no WRITE access.

SetPointAttributeConflictTest

This test validates that the File System must not be able to set reparse points from files and directories with mismatched GUID.

SparseFiles File System Test Group

The tests in this group include:

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 nonsparse 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 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.

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.

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.

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, that is, with opened file handles. This operation is expected to succeed, except in the following two cases:
  • The volume is the system drive, which cannot be dismounted. The operation fails with STATUS_ACCESS_DENIED.
  • 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.

Encryption File System Test Group

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 can be 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

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 APIs. 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 encryption 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, and 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 encryption 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 of directory attributes are read back, the encryption flag should be set.

AddUsersEncryptionTest

The AddUsersToEncryptedFile function can be used to share encrypted files, that is,, 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 users are allowed access to the encrypted file.

Quotas File System Test Group

Quotas are used to limit the amount of data a user is allowed to save on a volume. The tests in this group are:

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 file system 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.

LinkTracking File System 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

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.

ChangeJournal File System Test Group

The tests in this group are:

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
WRITE
SET_INFORMATION
SET_EA
FSCTL

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 specifying 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.

StreamEnhancements File System Test Group

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:

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.

DefragEnhancements File System Test Group

Tests in this group are:

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.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Partitions 1 or all of the following:

Running Anti-Virus/File System Filter Test Kit

Volumes must be created as described in the Manual Test Steps. In order to run the test select the "Installable File System Filter Tests" job and schedule it. Modify the parameters to include the appropriate drive letters for each file system type. If NONE is specified for a drive letter the test will not run for that particular drive type.

Command Syntax

Command option | Description

Code Tour

File Manifest

File | Location
* | [testbinroot]\nttest\basetest\core_file_services\ifstestkit

Click to show or hide information. Test Assertions

Test Assertions

Anti Virus filter driver does not alter file system behavior.
Test Assertion GUID: A72C4D26-977B-19CB-2E11-D6F93917D718


Storage Data Verification Filter Test

Type: Automated Test

Overview

The Storage Data Verification Filter test checks the hard disk drive and/or storage controller to ensure that no data corruption occurs.

Details

The Storage Data Verification Filter test checks the hard disk drive to ensure that no data corruption occurs. The test verifies data by generating a checksum on each disk write, and then verifies the checksum on each disk read. It provides the ability to detect any error reported by lower-level driver-hardware tests to locate the root cause of the data corruption.
The test will install a filter driver and setup AutoLogon for the DTM-created Administrator on the machine. It will then reboot the machine. Upon return from reboot the test will stress the storage device by simulating heavy database activity. If at any time data corruption occurs on the storage device, the machine will bugcheck. Upon completion of the stress portion of the test, the filter driver will be removed and the machine will again reboot.

Run Time: 72 hours
Log File:
System Restart Required: Yes
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running Storage Data Verification Filter Test

The test accepts 2 parameters for input: a device instance ID of the storage controller or disk, and a volume letter to target with stress. These are provided automatically by DTM when scheduling against a device in device console.

Command Syntax

Command option | Description
Dataver /dev <device name> /install 1 |
dtc_sqlio.exe <StorageDriveLetter> /c /z [FileSize] /h [RunTime] /fu /l 3600 /r 64k /w 64k /t 8 | Logo Test -> FileSize = 800m (MB), Runtime = 48 (hours)

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location
dataver.exe | …\tests\%ARCHITECTURE\nttest\driverstest\storage\wdk
dtc_sqlio.exe | …\tests\%ARCHITECTURE\nttest\driverstest\storage\wdk
dtc_rapidfile.exe | …\tests\%ARCHITECTURE\nttest\driverstest\storage\wdk

Click to show or hide information. Test Assertions

Test Assertions

dataver Storage Data Verification Filter
Test Assertion GUID: 0405c6da-e689-461c-a41f-6ea9f084bc90

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test case installs CRC Disk Filter.

DTC_SQLIO Data corruption must not occur on any disk read or write.
Test Assertion GUID: 096c7147-0dd5-4010-9b82-ddc9d397695d

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test performs intensive disk stress by simulating database activity. This test case can fail in two ways. The test itself can detect driver data corruption. This will cause the test to log a failure. The installed filter driver can detect hardware data corruption. This will cause the machine to bugcheck.


iSCSI Digest - Tape (Target)

Type: Automated Test

Overview

This test verifies that an iSCSI tape/media changer target supports header and data digests as negotiated during the logon phase.

Details

The iSCSI Digest - Tape (Target) test follows this algorithm:
  1. Prepares the system for iSCSI operations
    • If the target used for testing is already logged on, the session information is saved so the session can be restored later.
    • The target tape device is added as a static iSCSI target.
  2. Performs iSCSI operations
    • If target under test is already logged on, the current session to the target is logged out.
    • The target is logged on using the Microsoft iSCSI Initiator with header digests enabled.
    • After logging on to the target, the test waits for the tape device to be enumerated by the test system.
    • The test will perform tape I/O operations using the current target session.
    • The test repeats the above steps with data digests only enabled and header and data digests enabled.
    • The target under test must permit logon using all three digest combinations and no I/O failures can be detected during I/O operations.
  3. Restores any previous iSCSI target sessions.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running iSCSI Digest - Tape (Target)

Logon to the tape target and format the target.
Run the test as a DTM job

Fill the required data in the configuration UI that pops up when this job is scheduled

Command Syntax

Command option | Description
iscsi_digest -hct -l tape -a -c target |

Cautions

Troubleshooting

  1. Look at the job results log file for test failures
  2. Verify the iSCSI configuration information is entered correctly in the configuration dialog (Popup Dialog box when the job is scheduled from device console)

Reference Documentation

Code Tour

File Manifest

File | Location
iscsi_digest.exe | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\iscsi

Click to show or hide information. Test Assertions

Test Assertions

1.1 Setting up test, and saving open sessions.
Test Assertion GUID: 0df19e9d-c42e-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: The setup stage is responsible for getting the current sessions to the target and then persistenting that information so it can be used to reestablish these sessions during the cleanup stage.

2.1 The MS Initiator must be able to log into the target successfully with digests enabled
Test Assertion GUID: 7f102025-c42e-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

3.1 The MS Initiator must be able to successfully logout from target.
Test Assertion GUID: 7f102027-c42e-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4.1 Cleaning up test, restoring sessions.
Test Assertion GUID: 7f102028-c42e-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: The cleanup stage is responsible for restoring the sessions that were persisted during the setup stage.


iSCSI Ping Test (Target)

Type: Automated Test

Overview

The iSCSI Ping (Target) test verifies that iSCSI targets can send and receive ping requests.

Details

This test operates in two phases. The first phase verifies that iSCSI targets respond to ping requests by sending a ICMP echo packets to the target using a network card in the test system. The second phase verifies the target can send ICMP echo packets to another address, which in this case is the network card in the test system.
Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running iSCSI Ping Test (Target)

Run the test as a DTM job.
Fill the required data in the configuration UI that pops up when this job is scheduled

Command Syntax

Command option | Description
iscsi_pingtest -target -hct |

Cautions

Troubleshooting

  1. Look at the job results log file for test failures
  2. Verify the data entered in the configuration dialog (Popup Dialog box when the job is scheduled from device console)

Reference Documentation

Code Tour

File Manifest

File | Location
iscsi_pingtest.exe | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\iscsi

Click to show or hide information. Test Assertions

Test Assertions

1 The device being tested must return an Internet Control Message Protocol (ICMP) Echo Reply packet with the same 32 bytes of data issued in the original request.
Test Assertion GUID: f0e221bd-c4da-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test checks an iSCSI target or initiator’s ability to respond to an echo request initiated by the host to the device being tested. This test is run five times against the device being tested. Apply: Sends ICMP Echo packets with a request buffer size of 32 bytes. Expect: The device being tested returns an ICMP Echo Reply packet with the same 32 bytes of data issued in the original request.

2 The device being tested must be able to send multiple ICMP Echo Reply packets to the host.
Test Assertion GUID: f0e221be-c4da-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Ping (HBA/Target) test checks an iSCSI target or initiator’s ability to send an ICMP Echo Reply packet to the host. This test is run five times against the device being tested. Apply: Listens for ICMP Echo packets with a request buffer size of up to 64 KB. Expect: The device being tested can send multiple ICMP Echo Reply packets to the host.


iSCSI Redirection Test

Type: Automated Test

Overview

The iSCSI Redirection test verifies that a host-bus adapter (HBA) properly handles the target device’s capability to redirect the connection to a different IP address and/or port.

Details

This test implements a simple iSCSI target. The test performs a login to this target using the HBA under test. The target, upon receiving the first login packet, will redirect the HBA to connect to the target using a different location.
The test has three different variations each of which uses a different redirection mechanism:
  • Redirection to a new IP address
  • Redirection to a new IP address and new port
  • Redirection to the same IP address with a new port

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running iSCSI Redirection Test

Run the test as a DTM job

Fill the required data in the configuration UI that pops up when this job is scheduled

Command Syntax

Command option | Description
iscsi_redirect -hct |

Cautions

Troubleshooting

  1. Look at the job results log file for test failures
  2. Verify the data entered in the configuration dialog (Popup Dialog box when the job is scheduled from device console)

Reference Documentation

Code Tour

File Manifest

File | Location
iscsi_redirect.exe | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\iscsi

Click to show or hide information. Test Assertions

Test Assertions

1 The HBA must establish a connection to the test socket.
Test Assertion GUID: 3c74e21f-c4ef-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Redirection test checks that the HBA establishes a connection with the test target. Apply: The test uses the iSCSI Discovery Library routine LoginIScsiTarget to connect to the test target. Expect: The HBA establishes a TCP/IP connection with the test target.

2 The HBA must sent an initial login request PDU.
Test Assertion GUID: 3c74e220-c4ef-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Redirection test verifies that the HBA sends an initial logon request protocol data unit (PDU) to the test target. Apply: The test uses the LoginIScsiTarget routine to connect to the test target. Expect: The HBA sends an iSCSI logon request PDU to the test.

3 The HBA must not send any additional PDU requests to a connection that has been redirected.
Test Assertion GUID: 3c74e221-c4ef-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Redirection test expects that no data is sent on a connection after the test target has redirected the HBA to a new address. Apply: The test issues a logon response PDU that redirects the HBA to connect at a new IP address. Expect: The test expects the target to honor the response packet and not issue iSCSI request packets on the nonredirected connection.

4 The HBA must disconnect from the TCP/IP connection that has been redirected.
Test Assertion GUID: 3c74e222-c4ef-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Redirection test waits for a TCP/IP disconnection from the original connection after the test target has redirected the HBA to a new address. Apply: The test issues a logon response PDU that redirects the HBA to connect at a new IP address. Expect: The HBA disconnects from the original TCP/IP connection address.

5 The HBA must connect to the redirected TCP/IP address.
Test Assertion GUID: 3c74e223-c4ef-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Redirection test waits for a connection at the redirected TCP/IP address. Apply: The test issues a logon response PDU that redirects the HBA to connect at a new IP address. Expect: The HBA connects to the new TCP/IP address that the test specifies when redirecting the HBA to a new address.

6 The HBA must send an initial login request PDU to the redirected TCP/IP address.
Test Assertion GUID: 3c74e224-c4ef-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Redirection test checks that the HBA sends an initial logon request PDU to the test target at the redirection address. Apply: The test uses the LoginIScsiTarget routine to connect to the test target. Expect: The HBA sends an iSCSI logon request PDU to the test target address specified in the initial logon request PDU.

100 The initial PDU received from the iSCSI HBA must be a login request PDU.
Test Assertion GUID: 3c74e225-c4ef-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Redirection test checks that the HBA sends an initial logon request PDU to the test target at the redirection address. Apply: The test uses the LoginIScsiTarget routine to connect to the test target. Expect: The HBA sends an iSCSI logon request PDU to the test target address specified in the initial logon request PDU.

101 Bit one of the first byte in a login request PDU must be set to one.
Test Assertion GUID: 3c74e226-c4ef-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Redirection test checks that the HBA sets bit one in the first byte of the logon request PDU. Apply: The test uses the LoginIScsiTarget routine to connect to the test target. Expect: The HBA sends an iSCSI logon request PDU to the test target address. Bit one of the first byte must be set to one.

102 The current stage field of the initial login PDU must be set to indicate either the security negotiation phase or the operational negotiation stage.
Test Assertion GUID: 3c74e227-c4ef-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Redirection test checks that the HBA sets the current stage field of the initial logon request PDU correctly. Apply: The test uses the LoginIScsiTarget routine to connect to the test target. Expect: The HBA sends an iSCSI logon request PDU to the test target. The current stage field must be set to either 0 or 1.

103 The next stage field of the initial login request PDU must be greater than the current stage field if the Transit bit is set.
Test Assertion GUID: 3c74e228-c4ef-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Redirection test checks whether the transit bit is set in the initial logon request. If the bit is set in the initial request, the next stage field of the PDU must be valid and greater than the current stage field. This check is not made if the T (transit) bit is not set because the next stage field is irrelevant under this circumstance. Apply: The test uses the LoginIScsiTarget routine to connect to the test target. Expect: The HBA sends an iSCSI logon request PDU to the test target address. If the T bit is set, the next stage field must be valid and greater than the current stage. If the current stage is set to security negotiation (0x00), then the next stage must be set to either logon operation negotiation (0x01), or full feature phase (0x03). If the current stage is set to logon operation negotiation, then the only valid value is the full feature phase.

104 The Version-min field of the initial login request PDU must be set to 0x00.
Test Assertion GUID: 3c74e229-c4ef-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Redirection test checks whether the Version-min field of the logon request PDU is set to 0x00. Apply: The test uses the LoginIScsiTarget routine to connect to the test target. Expect: The HBA sends an iSCSI logon request PDU to the test target address specified. The Version-min field must be set to 0x00.

105 The Version-max field of the initial login request PDU must be set to 0x00.
Test Assertion GUID: 3c74e22a-c4ef-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Redirection test checks whether the Version-max field of the logon request PDU is set to 0x00. Apply: The test uses the LoginIScsiTarget routine to connect to the test target. Expect: The HBA sends an iSCSI logon request PDU to the test target address. The Version-max field must be set to 0x00.

106 The TSIH field of the initial login request PDU must be set to 0x00.
Test Assertion GUID: 3c74e22b-c4ef-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test checks whether the TSIH field of the logon request PDU is set to 0x00. Apply: The test uses the LoginIScsiTarget routine to connect to the test target. Expect: The HBA sends an iSCSI logon request PDU to the test target address. The TSIH field must be set to 0x00.

107 The length of the data segment in the initial login request PDU must be greater than zero.
Test Assertion GUID: 3c74e22c-c4ef-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Redirection test validates that the length of the data segment in the initial logon request PDU is nonzero. Apply: The test uses the LoginIScsiTarget routine to connect to the test target. Expect: The HBA sends an iSCSI logon request PDU to the test target address. The data segment of this request must contain a data segment because key = value pairs are required for the initial logon request.

108 The data segment in the initial login request PDU must be NULL-terminated.
Test Assertion GUID: 3c74e22d-c4ef-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Redirection test validates that the last byte (not including padding bytes) in the data segment in the initial logon request PDU is zero. Apply: The test uses the LoginIScsiTarget routine to connect to the test target. Expect: The HBA sends an iSCSI logon request PDU to the test target address. The last byte in the data segment of this request must contain a NULL separator character (0x00) because key = value pairs are required for the initial logon request. All key = value pairs must be terminated with a NULL delimiter.

109 The initial login request PDU must contain one and only one InitiatorName key.
Test Assertion GUID: 3c74e22e-c4ef-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Redirection test validates the initial logon packet that contains the required InitiatorName key. Apply: The test uses the LoginIScsiTarget routine to connect to the test target. Expect: The HBA sends an iSCSI logon request PDU to the test target address. The data segment contains a InitiatorName = key. There must be only one InitiatorName key.

111 The initial login request PDU must contain one and only one TargetName key.
Test Assertion GUID: 3c74e22f-c4ef-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Redirection test validates that the initial logon packet contains the required TargetName key. Apply: The test uses the LoginIScsiTarget routine to connect to the test target. Expect: The HBA sends an iSCSI logon request PDU to the test target address. The data segment contains a TargetName = key. There must be only one TargetName key.

112 The TargetName key value must equal the target name specified using the LoginIScsiTarget API.
Test Assertion GUID: 3c74e230-c4ef-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Redirection test validates that the HBA connects to the target that the test specifies when it initiates logon. Apply: The test uses the LoginIScsiTarget routine to connect to the test target. Expect: The HBA sends an iSCSI logon request PDU to the test target address. The value of the TargetName key equals the target name that was specified when the test called the LoginIScsiTarget routine.


iSCSI Boot Firmware Table Test

Overview

The iSCSI Boot Firmware Table (iBFT) is a block of information residing in memory that contains different entries that are required by the iSCSI Boot process.

iSCSI Boot Firmware Table test (iBFTest) verifies the presence of iBFT on the system. It also ensures that the various entries of the table are compliant with the iBFT specification.

Details

iSCSI Boot Firmware Table test (iBFTest) consists of two binaries. A user-mode binary (ibftest.exe) and a kernel-mode binary (ibftest.sys). Both binaries are required for the test to run successfully.

- ibftest.exe loads ibftest.sys into kernel mode.
- ibftest.sys checks if iBFT exists in memory.
- If iBFT exists in memory, ibftest.sys will get a copy of the table.
- ibftest.sys validates the table and returns results to ibftest.exe.
- ibftest.exe in turn provides a friendly log.
- The log contains either the table if it is available and valid or a detailed error information if the table is unavailable or invalid.

iBFTest ensures that the iBFT is present and available to the operating system for a consistent flow of the boot process. It also validates the various entries within the table and ensures that the table is intact. It ensures that all the information is compliant with the specification.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows 2003
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • A system that supports iSCSI boot.

Running iSCSI Boot Firmware Table Test

  • Copy iBFTest binaries: (Or make sure iBFTest is available within DTM)
    • copy ibftest.exe to test working directory.
    • copy ibftest.sys to test working directory.
  • Run ibftest.exe

Command Syntax

Command option | Description
ibftest.exe | None

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location
ibftest.exe | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\ibftest
ibftest.sys | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\ibftest

Click to show or hide information. Test Assertions

Test Assertions

LoadDriver System must load iSCSI Boot Firmware table driver.
Test Assertion GUID: 1d22e647-c438-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

UnLoadDriver System must unload iSCSI Boot Firmware table driver.
Test Assertion GUID: 1d22e648-c438-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

GetIBFInfo System must implement a iSCSI Boot Firmware table.
Test Assertion GUID: 1d22e649-c438-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

System must expose iSCSI Boot Firmware Table.
Test Assertion GUID: 1d22e64a-c438-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:


Multi-Path I/O Test

Type: Automated Test

Overview

Customers of enterprise storage solutions rely heavily on the high-availability of its components. In storage, high-availability is often implemented by redundancy. Multi-path I/O is one such implementation for the fabric layer of an enterprise storage solution. Microsoft supports multi-path I/O with inbox Multi-Path driver (mpio.sys) and Device Specific Module (msdsm.sys) on Microsoft Windows Advanced Server operating system in the Windows Vista timeframe.
The tool provides multi-path I/O testing for the compatibility of vendor's storage solution with Microsoft driver solutions. These features include:
  1. Failover
  2. Failback
  3. Load balance policy

Details

The test components include a stand-alone test application, fault injection filter, and the test manager (DTM). The steps of operation are:
  1. DTM installs fault-injection filter through a DTM job.
  2. DTM starts Stand-alone test application, simulates failover scenario, and does testing - all as part of the same DTM job.
  3. Test tool will log to WTTLogger.

Run Time: 10 minutes
Log File: mpiotest.log
System Restart Required: Yes
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows 2000
  • Software components included with the device that is being tested.
    • Unsupported Software:
  • Third Party MPIO Solution that does not use a Microsoft MPIO DSM.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Multi-Path I/O Setup

Running Multi-Path I/O Test

Command Syntax

Command option | Description
mpiotest.exe -s mpiotest_script_fvt.txt |

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location
mpiotest.exe | …\Tests\%PROCESSOR_ARCHITECTURE%\nttest\DriversTest\storage\wdk\
install.exe | …\Tests\%PROCESSOR_ARCHITECTURE%\nttest\DriversTest\storage\wdk\
mpfifltr.sys | …\Tests\%PROCESSOR_ARCHITECTURE%\nttest\DriversTest\storage\wdk\
mpfifltr.inf | …\Tests\%PROCESSOR_ARCHITECTURE%\nttest\DriversTest\storage\wdk\
mpiotest_script_fvt.txt | …\Tests\%PROCESSOR_ARCHITECTURE%\nttest\DriversTest\storage\wdk\

Click to show or hide information. Test Assertions

Test Assertions

DSM must support required MSDSM WMI functions.
Test Assertion GUID: 7682274a-c6a1-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

DSM must support failover functionality.
Test Assertion GUID: 7682274b-c6a1-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

DSM must support round-robin data access.
Test Assertion GUID: 7682274c-c6a1-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

DSM must support failover functionality.
Test Assertion GUID: 7682274d-c6a1-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:


iSCSI Digest - Disk (Target)

Type: Automated Test

Overview

This test verifies that an iSCSI disk storage system supports header and data digests as negotiated during the logon phase.

Details

The iSCSI Digest - Disk (Target) test follows this algorithm:
  1. Prepares the system for iSCSI operations
    • If the target under test is already logged on, the session information is saved so the session can be restored later.
    • The target disk device is added as a static iSCSI target.
  2. Performs iSCSI operations
    • If the target under test is already logged on, the current session to the target is logged out.
    • The target is logged on with header digests enabled.
    • After logging on to the target, the test waits for all disk devices to be enumerated on the test system.
    • The test will perform I/O read and write operations with the current target session.
    • The test repeats the above steps with data digest only enabled and header and data digests enabled.
    • The target under test must permit logon using all three digest combinations and no I/O failures can be detected during I/O operations.
  3. Restores any previous iSCSI target sessions.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running iSCSI Digest - Disk (Target)

Logon to the disk target and format the target. The disk target should have the drive letter before running the test
Run the test as a DTM job from device console
Fill the required data in the configuration UI that pops up when this job is scheduled

Command Syntax

Command option | Description
iscsi_digest -hct -l disk -a -c target |

Cautions

Troubleshooting

  1. Look at the job results log file for test failures
  2. Verify the target has been formatted and assigned a drive letter.
  3. Verify the iSCSI configuration information is entered correctly in the configuration dialog (Popup Dialog box when the job is scheduled from device console)

Reference Documentation

Code Tour

File Manifest

File | Location
iscsi_digest.exe | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\iscsi

Click to show or hide information. Test Assertions

Test Assertions

1.1 Setting up test, and saving open sessions.
Test Assertion GUID: 0df19e9d-c42e-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: The setup stage is responsible for getting the current sessions to the target and then persistenting that information so it can be used to reestablish these sessions during the cleanup stage.

2.1 The MS Initiator must be able to log into the target successfully with digests enabled
Test Assertion GUID: 7f102025-c42e-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

3.1 The MS Initiator must be able to successfully logout from target
Test Assertion GUID: 7f102027-c42e-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4.1 Cleaning up test, restoring sessions.
Test Assertion GUID: 7f102028-c42e-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: The cleanup stage is responsible for restoring the sessions that were persisted during the setup stage.


iSCSI Mutual CHAP (Target)

Type: Automated Test

Overview

The iSCSI Mutual CHAP (Target) test verifies that the target device (disk, tape, or optical storage device) can use the Challenge Handshake Authentication Protocol (CHAP) authentication mechanism.

Details

The test uses multiple variations to verify that a target properly supports mutual CHAP. The first variation performs a login similar to the user logging in through iSCSI Initiator Control Panel Applet. The rest of the variations perform login outside of the MS initiator using the iSCSI protocol. Each variation challenges the target using different challenge sizes with different encodings. The target is expected to calculate the proper response. The four different variations are as follows:
  • Challenge size of 1 byte using Hex Encoding
  • Challenge size of 1 byte using Base64 Encoding
  • Challenge size of 1024 bytes using Hex Encoding
  • Challenge size of 1024 bytes using Base64 Encoding

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running iSCSI Mutual CHAP (Target)

Setup up the initiator and the target with CHAP secrets
Run the test as a DTM job.
Fill the required data in the configuration UI that pops up when this job is scheduled

Command Syntax

Command option | Description
iscsi_targetchap -mutual -hct |

Cautions

Troubleshooting

  1. Look at the job results log file for test failures
  2. Verify the data entered in the configuration dialog (Popup Dialog box when the job is scheduled from device console)

Reference Documentation

Code Tour

File Manifest

File | Location
iscsi_targetchap.exe | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\iscsi

Click to show or hide information. Test Assertions

Test Assertions

0 Login using CHAP must succeed.
Test Assertion GUID: 5cfdfc45-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

1 The target must only return iSCSI logon response protocol data units (PDUs).
Test Assertion GUID: 5cfdfc1d-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The target can only use logon response PDUs during iSCSI logon. Apply: iSCSI logon request PDUs are sent to the target. Expect: Each PDU received by the test has the opcode field set to 0x23.

2 iSCSI logon response packets must have NULL-terminated data segments.
Test Assertion GUID: 5cfdfc1e-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: Any response PDU returned by the target, with the data segment length greater than 0, must have a NULL terminator in the last valid byte (non-pad byte) of the data segment. Only key = value pairs are allowed in the response PDU, and the last byte must indicate the end of the last key = value pair. Apply: iSCSI logon request PDUs are sent to the target. Expect: Each PDU, received by the target, has the last non-padding byte of the PDU set to 0.

3 The target must return successful status in response to the initial logon request.
Test Assertion GUID: 5cfdfc21-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test checks that the iSCSI target accepts the initial logon request by returning successful status to the initiator. Apply: An initial iSCSI logon PDU is sent with AuthMethod = CHAP. Expect: The returned logon response PDU must have the status code and status detail fields set to 0.

4 The target must remain in the security negotiation phase during CHAP authentication.
Test Assertion GUID: 5cfdfc22-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test checks that an iSCSI target does not request transition out of the security negotiation stage during authentication. Apply: Two iSCSI logon request PDUs are sent to the target as part of the security negotiation stage. Expect: The target’s response to the first two PDUs has the CSG and NSG fields of the response PDU set to 0 and the T (transit) bit set to 0.

5 The response PDU to the first logon request PDU must not have an empty data segment.
Test Assertion GUID: 5cfdfc23-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that the response PDU that is returned in response to the initial logon does not have an empty data segment. Apply: An initial iSCSI logon PDU is sent with AuthMethod = CHAP. Expect: The target’s response PDU Data Segment Length field must not be 0.

6 The initial logon response PDU must contain at least one TargetPortalGroupTag key.
Test Assertion GUID: 5cfdfc30-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test verifies that the initial response PDU returned to the initiator contains at least one TargetPortalGroupTag key. For more information, see section 5.3 of the iSCSI specification. Apply: An initial iSCSI logon PDU is sent with AuthMethod = CHAP. Expect: The target’s response PDU includes a TargetPortalGroupTag key.

7 The target must return only one AuthMethod key in the initial logon response PDU.
Test Assertion GUID: 5cfdfc31-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test verifies that the target returns one AuthMethod key in response to the initial logon request. Apply: An initial iSCSI logon PDU is sent with AuthMethod = CHAP. Expect: The target’s response PDU has one AuthMethod key.

8 The target must return only one value for the AuthMethod key in the initial logon response PDU.
Test Assertion GUID: 5cfdfc32-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test verifies that the target does not return a list of values for the AuthMethod key. Apply: An initial iSCSI logon PDU is sent with AuthMethod = CHAP. Expect: The target’s response PDU AuthMethod key does not contain a comma-delimited value list.

9 The target must accept CHAP when proposed by the initiator.
Test Assertion GUID: 5cfdfc33-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test checks that an iSCSI target accepts a proposal to use CHAP as an authentication method. Apply: An initial iSCSI logon PDU is sent with AuthMethod = CHAP. Expect: The target’s response to the initial logon request returns AuthMethod = CHAP.

10 The target must not return any invalid keys in the initial logon response.
Test Assertion GUID: 5cfdfc24-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test checks that only the AuthMethod and TargetPortalGroupTag keys are returned in the initial logon response. Apply: An initial iSCSI logon PDU is sent with AuthMethod = CHAP. Expect: The target’s response contains only the AuthMethod or TargetPortalGroupTag key.

11 The target must return successful status in response to the initiator CHAP_A proposal.
Test Assertion GUID: 5cfdfc25-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test checks that the iSCSI target accepts the CHAP_A proposal and returns a successful status to the initiator. Apply: The second iSCSI logon PDU that the initiator sends contains the CHAP_A = 5 key. Expect: The returned logon response PDU must have the status code and status detail fields set to zero (0).

12 The response PDU to the second logon request PDU must not have an empty data segment.
Test Assertion GUID: 5cfdfc27-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test verifies that the response PDU, returned in response to the second logon, does not have an empty data segment. Apply: The second iSCSI logon PDU that the initiator sends contains the CHAP_A = 5 key. Expect: The target’s response PDU Data Segment Length field must not be 0.

13 The target must return only one CHAP_A key in the second logon response PDU.
Test Assertion GUID: 5cfdfc34-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test verifies that the target returns one CHAP_A = key in response to the second logon request. Apply: The second iSCSI logon PDU that the initiator sends contains the CHAP_A = 5 key. Expect: The target’s response PDU has one CHAP_A = key.

14 The target must return only one value for the CHAP_A key in the second logon response PDU.
Test Assertion GUID: 5cfdfc35-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test verifies that the target does not return a list of values in the CHAP_A= key. Apply: The second iSCSI logon PDU sent by the initiator contains the CHAP_A = 5 key. Expect: The target’s response PDU CHAP_A does not contain a comma-delimited value list.

15 The CHAP_A key returned in the second logon response must be a valid numeric value.
Test Assertion GUID: 5cfdfc36-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that the value returned in the CHAP_A = key is a properly encoded numeric value. Apply: The second iSCSI logon PDU sent by the initiator contains the CHAP_A = 5 key. Expect: The value of the target’s response PDU CHAP_A key is properly encoded as a numerical value as defined in section 5.1 of the iSCSI specification (For more information, see the IETF IP Storage Working Group Internet Draft: draft-ietf-ips-iscsi-20.txt). The value may be encoded as a decimal or hexadecimal value.

16 The target must accept the MD5 hash algorithm.
Test Assertion GUID: 5cfdfc37-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test checks that an iSCSI target accepts the MD5 algorithm when proposed by the initiator. Apply: The second iSCSI logon PDU sent by the initiator contains the CHAP_A = 5 key. Expect: The target logon response returns the iSCSI logon response PDU with the CHAP_A value equivalent to 5.

17 The target must return only one CHAP_I key in the second logon response PDU.
Test Assertion GUID: 5cfdfc38-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that the target returns one CHAP_I key in response to the second logon request. Apply: The second iSCSI logon PDU sent by the initiator contains the CHAP_A=5 key. Expect: The target’s response PDU has one CHAP_I key.

18 The target must return only one value for the CHAP_I key in the second logon response PDU.
Test Assertion GUID: 5cfdfc39-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that the target does not return a list of values in the CHAP_I= key. Apply: The second iSCSI logon PDU sent by the initiator contains the CHAP_A=5 key. Expect: The target’s response PDU CHAP_I = does not contain a comma-delimited value list.

19 The CHAP_I key returned in the second logon response must be a valid numeric value.
Test Assertion GUID: 5cfdfc3a-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: The target must return a valid numeric value for the CHAP_I key in the second logon response PDU. Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that the value returned in the CHAP_I= key is a properly encoded numeric value. Apply: The second iSCSI logon PDU sent by the initiator contains the CHAP_A=5 key. 4/14/04 crobbins: In theory, should say "by the test" not specific to our initiator. Expect: The value of the target’s response PDU CHAP_I must be properly encoded as a numerical value as defined in section 5.1 of the iSCSI Specification. The value may be encoded as a decimal or hexadecimal value.

20 The value of the CHAP_I key must be less than or equal to 255.
Test Assertion GUID: 5cfdfc3b-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test checks that the CHAP_I key value is only one byte in its unencoded form. Apply: The second iSCSI logon PDU sent by the initiator contains the CHAP_A = 5 key. Expect: The target logon response returns an iSCSI logon response PDU with a CHAP_i value less than or equal to 255 after it is decoded.

21 The target must return only one CHAP_C key in the second logon response PDU.
Test Assertion GUID: 5cfdfc3c-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that the target returns one CHAP_C = key in response to the second logon request. Apply: The second iSCSI logon PDU sent by the initiator contains the CHAP_A = 5 key. Expect: The target’s response PDU has one CHAP_C key.

22 The target must return only one value for the CHAP_C key in the second logon response PDU.
Test Assertion GUID: 5cfdfc3d-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that the target does not return a list of values in the CHAP_C key. Apply: The second iSCSI logon PDU sent by the initiator contains the CHAP_A=5 key. Expect: The target’s response PDU CHAP_C= does not contain a comma-delimited value list.

23 The CHAP_C key returned in the second login response must be a valid binary value.
Test Assertion GUID: 5cfdfc3e-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that the value returned in the CHAP_C = key is a properly encoded binary value. Apply: The second iSCSI logon PDU sent by the initiator contains the CHAP_A=5 key. Expect: The value of the target’s response PDU CHAP_C key must be properly encoded as a binary value as defined in section 5.1 of the iSCSI specification. The value may be encoded as a decimal, hexadecimal , or base 64 constant.

24 The CHAP_C key must not be longer than the maximum allowed length.
Test Assertion GUID: 5cfdfc3f-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test checks that the CHAP_C = key value is not longer than the maximum length allowed. For those values encoded in hexadecimal or base 64 encoding, the maximum byte length is 1024 bytes. For values encoded in decimal encoding, the maximum byte length is 8 bytes. Apply: The second iSCSI logon PDU sent by the initiator contains the CHAP_A = 5 key. Expect: The target logon response returns an iSCSI logon response PDU with a CHAP_i key value that is less than or equal to 255 after it is decoded.

25 The target must not return any invalid keys in the second logon response.
Test Assertion GUID: 5cfdfc28-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test checks that only CHAP_A, CHAP_I, and CHAP_C values are included in the second logon response. Apply: The second iSCSI logon PDU sent by the initiator contains the CHAP_A=5 key. Expect: The target’s response PDU contains only the CHAP_A = 5, a valid CHAP_I and a valid CHAP_C key. Any other included keys are considered an error.

26 The target must return authentication failure status when an invalid response is returned by the initiator.
Test Assertion GUID: 5cfdfc2a-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that a target properly rejects a logon when the initiator returns an invalid response to a CHAP challenge. Apply: The final logon PDU with the CHAP response is sent to the target with an invalid CHAP_R value. Expect: The target must return a logon response packet with its status class set to initiator error and the status detail set to authentication failure.

27 The target must accept a logon request when a valid response is returned by the initiator.
Test Assertion GUID: 5cfdfc29-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that a target properly recognizes when the initiator returns a valid response to a CHAP challenge. Apply: The final logon PDU with the CHAP response is sent to the target with a valid CHAP_R value. Expect: The target must return a logon response packet with its status class and status detail set to 0.

28 The target must indicate that it is ready to transition to the operation negotiation stage after indicating that the logon authentication succeeded.
Test Assertion GUID: 5cfdfc2d-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that a target indicates that it is ready to proceed to the operation negotiation stage after successfully authenticating the initiator. This condition is checked in both one-way and mutual CHAP. Apply: The final logon PDU with the CHAP response is sent to the target and indicates that the initiator wants to transition to the operation negotiation stage. Expect: The target must return a logon response packet with the CSG field set to 0x01 and the T (transit) bit set to 1.

29 The target must not return any key = value pairs in the final response packet when the initiator is not performing mutual CHAP.
Test Assertion GUID: 5cfdfc2b-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test verifies that the final response packet, returned by the initiator during one-way CHAP, does not contain any key=value pairs. Apply: The final logon PDU with the CHAP response is sent to the target with a valid CHAP_R value. Expect: The target must return a logon response packet with no additional data included in the data segment.

30 When the target is performing mutual CHAP, the target must return a logon response packet with a nonzero data segment length.
Test Assertion GUID: 5cfdfc2c-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that the final response packet, returned by the initiator during mutual CHAP, contains key = value pairs in the data segment. Apply: The final logon PDU with the CHAP response is sent to the target with a valid CHAP_R value, a CHAP_I value, and a CHAP_C value. Expect: The target must return a logon response packet with a nonzero data segment length.

31 The target must return only one CHAP_N key in the second logon response PDU.
Test Assertion GUID: 5cfdfc40-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that the target returns one CHAP_N = key in response to the final logon request. Apply: The final logon PDU with the CHAP response is sent to the target with a valid CHAP_R value, a CHAP_I value, and a CHAP_C value. Expect: The target’s response PDU has one CHAP_N = key.

32 The target must return only one CHAP_R key in the second logon response PDU.
Test Assertion GUID: 5cfdfc41-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that the target returns one CHAP_R = key in response to the final logon request. Apply: The final logon PDU with the CHAP response is sent to the target with a valid CHAP_R value, a CHAP_I value, and a CHAP_C value. Expect: The target’s response PDU has one CHAP_R = key.

33 During mutual CHAP, the target must return only one value for the CHAP_R key in the final logon response PDU.
Test Assertion GUID: 5cfdfc42-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that the target does not return a list of values in the CHAP_R = key. Apply: The final iSCSI logon PDU sent by the initiator contains CHAP_I and CHAP_C values that indicate mutual CHAP. Expect: The target’s response PDU CHAP_R = does not contain a comma-delimited value list.

34 The CHAP_R key returned in the final logon response must be a valid large-binary value.
Test Assertion GUID: 5cfdfc43-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that the value returned in the CHAP_R key is a properly encoded binary value. Although the CHAP_R response may be a binary value, for MD5, the required length exceeds the 8-byte limit for decimal-encoded responses. Therefore, the encoding may only be hexadecimal or base 64. Apply: The final iSCSI logon PDU sent by the initiator contains CHAP_I and CHAP_C values that indicate mutual CHAP. Expect: The value of the target’s response PDU CHAP_R must be properly encoded as a large-binary value as defined in section 5.1 of the iSCSI specification. The value can be encoded either as a hexadecimal or base 64constant.

35 The CHAP_R key must be 16 bytes long in its non-encoded form
Test Assertion GUID: 5cfdfc44-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test checks that the CHAP_R key value is equal to 16 bytes, which is the required length for responses returned as part of the MD5 algorithm. Apply: The final iSCSI logon PDU sent by the initiator contains CHAP_I and CHAP_C values that indicate mutual CHAP. Expect: The target logon response returns a iSCSI logon response PDU and the decode CHAP_R response must be 16 bytes long.

36 The target must compute the CHAP response correctly based on the MD5 algorithm.
Test Assertion GUID: 5cfdfc2e-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test checks that the CHAP response, returned by the target, is equivalent to the expected response based on the initiator secret and the CHAP_I and CHAP_C values sent to the target. Apply: The final iSCSI logon PDU sent by the initiator contains CHAP_I and CHAP_C values to indicate mutual CHAP. Expect: The target returns a CHAP_R response key with the correct response value after decoding the CHAP_R key.

37 When performing mutual CHAP, the target must not return any invalid keys in the final logon response.
Test Assertion GUID: 5cfdfc2f-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test checks that CHAP_N and CHAP_R are the only values included in the final logon response. Apply: The final iSCSI logon PDU sent by the initiator contains CHAP_I and CHAP_C values that indicate mutual CHAP. Expect: The target’s response contains only the CHAP_N and CHAP_R above keys. Any other keys included are considered an error.

100 A target must allow connections at the IP address and port number specified for the target.
Test Assertion GUID: 5cfdfc1c-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that a TCP connection with the target being tested can be properly established. Apply: The test attempts to connect to the target using TCP/IP. Expect: The connection is properly established.

101 A target that supports logon redirection must include a data segment in the logon packet that redirects the test.
Test Assertion GUID: 5cfdfc1f-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that a logon response PDU with the status class set to 0x01 includes a data segment. Apply: The initial logon PDU is sent to the target device. Expect: If the target needs to redirect the test, it must contain a data segment so that it can specify a new target address.

102 A target that supports logon redirection must include at least one TargetAddress key in the returned data segment.
Test Assertion GUID: 5cfdfc20-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that a logon response PDU with the status class set to 0x01 includes a TargetAddress key. Apply: The initial logon PDU is sent to the target device. Expect: If the target needs to redirect the test, the returned data segment that indicates redirection contains a TargetAddress key.


Media Lock Test

Type: Manual Test

Overview

This user mode application will test the functionality of locking mechanisms on SCSI removable devices of type CD-ROM and direct access (e.g. Iomega Jaz, Zip drive) by issuing SCSI passthrough commands Prevent/Allow medium removal.

Details

This test verifies if the device supports the media lock command properly. It locks the media using Prevent/Allow medium removal command then verifies if the media is locked. This is a manual test and needs manual intervention.

Run Time: 20 min
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • SCSI removable devices

Running Media Lock Test

  1. Run test as DTM job.
  2. Manual Intervention is required for this test

Command Syntax

Command option | Description
mlocktst.exe <drive> |

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location
mlocktst.exe | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk

Click to show or hide information. Test Assertions

Test Assertions

Device must expose a drive letter and permit the test to open a handle to the drive."
Test Assertion GUID: 8902c4c2-c50d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device must support SCSI Inquiry, with SCSI Peripheral Device Type of direct-access (00h), CDROM (05h), Optical (07h), or Simplified direct-access (0Eh) and expose the Removable Medium bit."
Test Assertion GUID: 8902c4c3-c50d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device must report "Medium not present" when no media is loaded."
Test Assertion GUID: 8902c4c4-c50d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device must report 'transition' to ready, or media change when media is inserted"
Test Assertion GUID: 8902c4c5-c50d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device must report disk geometry when issued IOCTL_DISK_GET_DRIVE_GEOMETRY"
Test Assertion GUID: 8902c4c6-c50d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device must report media status with Test Unit Ready as defined in SCSI-2 specification."
Test Assertion GUID: 8902c4c7-c50d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device must support a button\mechanism for ejecting media."
Test Assertion GUID: 8902c4c8-c50d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device must transition to ready state within 45s after media is inserted."
Test Assertion GUID: 8902c4c9-c50d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device must mount media after media is inserted."
Test Assertion GUID: 8902c4ca-c50d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device must transition to no media state within 45s after media is ejected."
Test Assertion GUID: 8902c4cb-c50d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device must dismount media after media is ejected."
Test Assertion GUID: 8902c4cc-c50d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device must properly implement front panel button."
Test Assertion GUID: 8902c4cd-c50d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device must support the 'Prevent' command to lock the media."
Test Assertion GUID: 8902c4ce-c50d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device must support the 'Prevent' command to unlock the media."
Test Assertion GUID: 8902c4cf-c50d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device must support the 'Start stop unit' command to eject the media."
Test Assertion GUID: 8902c4d0-c50d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Media must not be accessible after issuing the 'Start stop unit' command to eject the media."
Test Assertion GUID: 8902c4d1-c50d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Media must physically eject from the device after issuing the 'Start stop unit' command to eject the media."
Test Assertion GUID: 8902c4d2-c50d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Issuing the 'Start stop unit' command to eject the media when media is locked should fail with status: ASC=53h, ASCQ=02h."
Test Assertion GUID: 8902c4d3-c50d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Media should remail accessible after a failed eject command."
Test Assertion GUID: 8902c4d4-c50d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device must properly support Prevent/Allow and Start/Stop SCSI commands."
Test Assertion GUID: 8902c4d5-c50d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:


MMC Test

Type: Manual Test

Overview

This test validates a device's compliance with the MMC-1, MMC-2, MMC-3 and SFF-8090i (Mt. Fuji) standards as the basis for supporting CD-ROM, DVD-ROM, CD-RW, CD-R, and DVD-RAM devices.

Details

This test sends the MMC commands and verifies the response from the device to make sure that the device complies with the MMC specifications.
Run Time: 10 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running MMC Test

  1. Run the test as a DTM job
  2. Manual Interaction is required for this test

Command Syntax

Command option | Description
mmctest.exe |

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location
mmctest.exe | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk

Click to show or hide information. Test Assertions

Test Assertions

Command Get Configuration
Test Assertion GUID: 5bd99e15-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Inquiry
Test Assertion GUID: 5bd99e16-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Test Unit Ready
Test Assertion GUID: 5bd99e17-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Mode Sense (10)
Test Assertion GUID: 5bd99e18-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Request Sense
Test Assertion GUID: 5bd99e19-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Get Event Status Notification
Test Assertion GUID: 5bd99e1a-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Mode Select
Test Assertion GUID: 5bd99e1b-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Prevent Allow Medium Removable
Test Assertion GUID: 5bd99e1c-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Mechanism Status
Test Assertion GUID: 5bd99e1d-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Start Stop Unit
Test Assertion GUID: 5bd99e1e-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Read Capacity
Test Assertion GUID: 5bd99e1f-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Read 10
Test Assertion GUID: 5bd99e20-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Read CD
Test Assertion GUID: 5bd99e21-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Read CD MSF
Test Assertion GUID: 5bd99e22-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Read TOC/PMA/ATIP
Test Assertion GUID: 5bd99e23-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Read Disc Information
Test Assertion GUID: 5bd99e24-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Synchronize Cache
Test Assertion GUID: 5bd99e25-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Reserve Track
Test Assertion GUID: 5bd99e26-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Read 12
Test Assertion GUID: 5bd99e27-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Set Streaming
Test Assertion GUID: 5bd99e28-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Set Read Ahead
Test Assertion GUID: 5bd99e29-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Send OPC Information
Test Assertion GUID: 5bd99e2a-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Read Format Capacities
Test Assertion GUID: 5bd99e2b-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Verify 10
Test Assertion GUID: 5bd99e2c-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Blank
Test Assertion GUID: 5bd99e2d-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Write 12
Test Assertion GUID: 5bd99e2e-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Write 10
Test Assertion GUID: 5bd99e2f-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Format Unit
Test Assertion GUID: 5bd99e30-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Read DVD Structure
Test Assertion GUID: 5bd99e31-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Read Buffer Capacity
Test Assertion GUID: 5bd99e32-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Close Track Session
Test Assertion GUID: 5bd99e33-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Get Performance
Test Assertion GUID: 5bd99e34-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Read Track Information
Test Assertion GUID: 5bd99e35-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Set CD Speed
Test Assertion GUID: 5bd99e36-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Pause/Resume
Test Assertion GUID: 5bd99e37-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Stop Play/Scan
Test Assertion GUID: 5bd99e38-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Scan
Test Assertion GUID: 5bd99e39-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Report Key
Test Assertion GUID: 5bd99e3a-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Write And Verify 10
Test Assertion GUID: 5bd99e3b-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Play Audio 10
Test Assertion GUID: 5bd99e3c-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Play Audio 12
Test Assertion GUID: 5bd99e3d-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Play Audio MSF
Test Assertion GUID: 5bd99e3e-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Send DVD Structure
Test Assertion GUID: 5bd99e3f-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Load Unload Medium
Test Assertion GUID: 5bd99e40-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Seek 10
Test Assertion GUID: 5bd99e41-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Send Key
Test Assertion GUID: 5bd99e42-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Erase 10
Test Assertion GUID: 5bd99e43-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Command Read Sub Channel
Test Assertion GUID: 5bd99e44-c685-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature Profile List
Test Assertion GUID: a8aa5515-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature Core
Test Assertion GUID: a8aa5516-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature Morphing
Test Assertion GUID: a8aa5517-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature Removable Medium
Test Assertion GUID: a8aa5518-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature Random Readable
Test Assertion GUID: a8aa5519-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature Write Protect
Test Assertion GUID: a8aa551a-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature Multi Read
Test Assertion GUID: a8aa551b-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature CD Read
Test Assertion GUID: a8aa551c-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature DVD Read
Test Assertion GUID: a8aa551d-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature Random Writable
Test Assertion GUID: a8aa551e-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature Incremental Streaming Writable
Test Assertion GUID: a8aa551f-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature Sector Erasable
Test Assertion GUID: a8aa5520-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature Formattable
Test Assertion GUID: a8aa5521-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature Hardware Defect Management
Test Assertion GUID: a8aa5522-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature Write Once
Test Assertion GUID: a8aa5523-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature Restricted overwrite
Test Assertion GUID: a8aa5524-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature CD-RW CAV WRITE
Test Assertion GUID: a8aa5525-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature MRW
Test Assertion GUID: a8aa5526-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature Enhanced Defect Reporting
Test Assertion GUID: a8aa5527-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature DVD+RW
Test Assertion GUID: a8aa5528-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature DVD+R
Test Assertion GUID: a8aa5529-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature Rigid Restricted Overwrite
Test Assertion GUID: a8aa552a-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature CD Track At Once
Test Assertion GUID: a8aa552b-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature DVD-R/-RW WRITE
Test Assertion GUID: a8aa552c-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature CD Mastering
Test Assertion GUID: a8aa552d-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature Double Density CD Read
Test Assertion GUID: a8aa552e-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature Double Density CD-R Write
Test Assertion GUID: a8aa552f-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature Double Density CD-RW Write
Test Assertion GUID: a8aa5530-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature CD-RW Media Write Support
Test Assertion GUID: a8aa5531-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature Power Management
Test Assertion GUID: a8aa5532-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature S.M.A.R.T
Test Assertion GUID: a8aa5533-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature Embedded Changer
Test Assertion GUID: a8aa5534-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature CD Audio Analog Play
Test Assertion GUID: a8aa5535-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature Microcode Upgrade
Test Assertion GUID: a8aa5536-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature Timeout
Test Assertion GUID: a8aa5537-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature DVD_CSS
Test Assertion GUID: a8aa5538-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature Real Time Streaming
Test Assertion GUID: a8aa5539-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature Logical Unit serial number
Test Assertion GUID: a8aa553a-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature Disc Control Blocks
Test Assertion GUID: a8aa553b-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature DVD_CPRM
Test Assertion GUID: a8aa553c-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Feature Reserved
Test Assertion GUID: a8aa553d-c686-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Profile CD-RW
Test Assertion GUID: ebfd2e8f-c687-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Profile CD-R
Test Assertion GUID: ebfd2e90-c687-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Profile No Current
Test Assertion GUID: ebfd2e91-c687-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Profile Non Removable Disk
Test Assertion GUID: ebfd2e92-c687-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Profile Removable Disk
Test Assertion GUID: ebfd2e93-c687-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Profile Magneto-Optical Erasable
Test Assertion GUID: ebfd2e94-c687-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Profile Optical Write Once
Test Assertion GUID: ebfd2e95-c687-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Profile AS MO
Test Assertion GUID: ebfd2e96-c687-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Profile CD ROM
Test Assertion GUID: ebfd2e97-c687-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Profile DVD-ROM
Test Assertion GUID: ebfd2e98-c687-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Profile DVD-R Sequential Recording
Test Assertion GUID: ebfd2e99-c687-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Profile DVD-RAM
Test Assertion GUID: ebfd2e9a-c687-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Profile DVD-RW Restricted Overwrite
Test Assertion GUID: ebfd2e9b-c687-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Profile DVD-RW Sequential Recording
Test Assertion GUID: ebfd2e9c-c687-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Profile DVD+RW
Test Assertion GUID: ebfd2e9d-c687-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Profile DVD+R
Test Assertion GUID: ebfd2e9e-c687-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Profile DDCD-ROM
Test Assertion GUID: ebfd2e9f-c687-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Profile DDCD-R
Test Assertion GUID: ebfd2ea0-c687-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Profile DDCD-RW
Test Assertion GUID: ebfd2ea1-c687-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Profile Logical Unit Not Confirming To Standard
Test Assertion GUID: ebfd2ea2-c687-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Profile Reserved
Test Assertion GUID: ebfd2ea3-c687-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:


Hybrid Disk Logo test

Type: Automated Test

Overview

This test validates and verifies if the hybrid disk drive is in compliance with the standards and achieve the performance and power management requirements

Details

The test verifies the following requirements of the Hybrid Disk Drive:
  1. Basic logo requirements
- Hybrid disk is detectable
- Disk satisfies the minimum NV cache size requirement
2. Supports ATA command set extension
3. Performance requirements

Run Time: 1 hour
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running Hybrid Disk Logo test

Run the test as a DTM job from the device console

Command Syntax

Command option | Description
pitonlogotest.exe -device <deviceid> |

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location
pitonlogotest.exe | storage\wdk\piton
pitonlogotestsetup.exe | storage\wdk\piton
powertst.sys | storage\wdk\piton

Click to show or hide information. Test Assertions

Test Assertions

TEST: IDENTIFY Device Command
Test Assertion GUID: aaecc364-c420-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

TEST: Enable Disable NV Cache Power Mode
Test Assertion GUID: aaecc365-c420-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

TEST: Max NV Cache Pin Area
Test Assertion GUID: aaecc366-c420-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

TEST: Power Mode Spinup Time
Test Assertion GUID: aaecc367-c420-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

TEST: Power Mode State Test
Test Assertion GUID: aaecc368-c420-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

TEST: Pin Data
Test Assertion GUID: aaecc369-c420-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

TEST: Unpin Data
Test Assertion GUID: aaecc36a-c420-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

TEST: Pin Max LBAs
Test Assertion GUID: aaecc36b-c420-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

TEST: Pin LBAs More than NV cache size
Test Assertion GUID: aaecc36c-c420-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

TEST: Query Cache Misses
Test Assertion GUID: aaecc36d-c420-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

TEST: Read LBAs
Test Assertion GUID: aaecc36e-c420-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

TEST: Write LBAs
Test Assertion GUID: aaecc36f-c420-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

TEST: Pin Maximum Random LBA Entries
Test Assertion GUID: aaecc370-c420-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

TEST: Power Mode Performance Test
Test Assertion GUID: aaecc371-c420-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:


SMART test utility

Type: Automated Test

Overview

1) Verify each S.M.A.R.T. command by issuing the commands to the drive
2) issue SMART commands in random order and random number of times

Details

Verify the drive returns proper error code and works in different combinations of commands
Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running SMART test utility

1. Run test as a DTM job.

Command Syntax

Command option | Description
smarttst <drive number> |

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location
smarttst.exe | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk

Click to show or hide information. Test Assertions

Test Assertions

SMART_GET_VERSION: bReserved should be zero.
Test Assertion GUID: e195012d-c8ea-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Content will be published

SMART_GET_VERSION: bit 3-31 in fCapabilities should be zero.
Test Assertion GUID: e195012e-c8ea-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Content will be published

SMART_GET_VERSION: a call with a NULL handle should fail.
Test Assertion GUID: e195012f-c8ea-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Content will be published

SMART_GET_VERSION: a call with bogus handle should fail.
Test Assertion GUID: e1950130-c8ea-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Content will be published

SMART_GET_VERSION: a call to DeviceIOControl with handle to device and bogus IoControlCode shoud fail.
Test Assertion GUID: e1950131-c8ea-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Content will be published

SMART_GET_VERSION: a call to DeviceIOControl with handle to device and null IoControlCode shoud fail.
Test Assertion GUID: e1950132-c8ea-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Content will be published

SMART_GET_VERSION: bogus lpvInBuffer should be not cause failure.
Test Assertion GUID: e1950133-c8ea-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Content will be published

SMART_GET_VERSION: pass NULL for LpvOutBuffer should fail.
Test Assertion GUID: e1950134-c8ea-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Content will be published

ENABLE_SMART: Bytes returned should match SENDCMDOUTPARAMS structure.
Test Assertion GUID: e1950135-c8ea-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Content will be published

IDE_IDENTIFY: Bytes returned should match IDENTIFY_DATA.
Test Assertion GUID: e1950136-c8ea-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Content will be published

ATAPI_IDENTIFY: If supporuted, should succeed.
Test Assertion GUID: e1950137-c8ea-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Content will be published

READ_ATTRIBUTES \ READ_THRESHOLDS: number of attribute bytes should match for both calls.
Test Assertion GUID: e1950138-c8ea-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Content will be published

READ_ATTRIBUTES: bytes returned should match sizeof(SENDCMDOUTPARAMS) - 1 + READ_ATTRIBUTE_BUFFER_SIZE.
Test Assertion GUID: e1950139-c8ea-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Content will be published

READ_THRESHOLDS: Bytes returned should match sizeof(SENDCMDOUTPARAMS) - 1 + READ_THRESHOLD_BUFFER_SIZE.
Test Assertion GUID: e195013a-c8ea-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Content will be published

RETURN_SMART_STATUS: Bytes returned should match sizeof(SENDCMDOUTPARAMS) - 1 + sizeof(IDEREGS).
Test Assertion GUID: e195013b-c8ea-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Content will be published

ENABLE_DISABLE_AUTOSAVE: Enable Attribute AutoSave successful should be successful and bytes returned should match SENDCMDOUTPARAMS structure.
Test Assertion GUID: e195013c-c8ea-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Content will be published

ENABLE_DISABLE_AUTOSAVE: Disable Attribute AutoSave successful should be successful and bytes returned should match SENDCMDOUTPARAMS structure.
Test Assertion GUID: e195013d-c8ea-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Content will be published

EXECUTE_OFFLINE_DIAGS: If supported should succeed and bytes returned should match SENDCMDOUTPARAMS structure.
Test Assertion GUID: e195013e-c8ea-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Content will be published

DISABLE_SMART: should be successful and bytes returned should match SENDCMDOUTPARAMS structure.
Test Assertion GUID: e195013f-c8ea-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Content will be published

SAVE_ATTRIBUTE_VALUES: should be successful and bytes returned should match SENDCMDOUTPARAMS structure.
Test Assertion GUID: e1950140-c8ea-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Content will be published

DeviceIoControl calls should behave as expected.
Test Assertion GUID: e1950141-c8ea-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Content will be published


Symlink Regressions

Overview

This test will run several variations containing symbolic links. It will require the input of a source path and a target path. The source path must be on an NTFS volume.

Details

This will run several variations with NTFS symbolic links for use with filter drivers to ensure they have not broken symbolic link behavior.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running Symlink Regressions

Run the job from Job Explorer with valid target and source directories.

Command Syntax

Command option | Description

Code Tour

File Manifest

File | Location
symlinkregressions.exe | nttest\BASETEST\core_file_Services\NTFS\symlinkregressions.exe

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


iSCSI WMI Verification

Type: Automated Test

Overview

This test verifies that an iSCSI host-bus adapter (HBA) driver implements the required Microsoft Windows Management Instrumentation (WMI) interfaces. To qualify for the "Designed for Windows" logo, iSCSI HBA drivers must support the WMI classes documented in the iSCSI Driver Development Kit (DDK) version 1.0.

Details

The test enumerates all WMI classes exposed by the HBA driver being tested. The test verifies that there is an instance of each required class and logs a failure if a class is missing. In addition, for each class that is implemented, the test verifies the data items in the class contain valid values.
The required iSCSI initiator WMI classes include the following:
  • MSiSCSI_HBAInformation
  • MSiSCSI_InitiatorSessionInfo
  • MSiSCSI_PersistentLogins
  • MSiSCSI_TargetMappings
  • MSiSCSI_LUNMappingInformation
  • MSiSCSI_HBASessionConfig
  • MSiSCSI_PortalInfoClass
  • MSiSCSI_TCPIPConfig
  • MSiSCSI_NICConfig
  • MSiSCSI_BootConfiguration
  • MSiSCSI_SecurityCapabilities
  • MSiSCSI_DiscoveryConfig
  • MSiSCSI_RADIUSConfig
  • MSiSCSI_ConnectionStatistics
  • MSiSCSI_SessionStatistics
  • MSiSCSI_InitiatorLoginStatistics
  • MSiSCSI_InitiatorInstanceStatistics
  • MSiSCSI_MMIPSECStats
  • MSiSCSI_QMIPSECStats
  • MSiSCSI_NICPerformance

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running iSCSI WMI Verification

Run the test as a DTM job

Fill the required data in the configuration UI that pops up when this job is scheduled

Command Syntax

Command option | Description
iscsiwmi.cmd |

Cautions

Troubleshooting

  1. Look at the job results log file for test failures
  2. Verify the data entered in the configuration dialog (Popup Dialog box when the job is scheduled from device console)

Reference Documentation

Code Tour

File Manifest

File | Location
iscsiwmi.cmd | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\iscsi

Click to show or hide information. Test Assertions

Test Assertions

iScsi WMI provider test
Test Assertion GUID: b17357d0-5f26-4071-8ced-56a135d46a92

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: 0 The host-bus adapter (HBA) must properly implement the MSiSCSI_HBAInformation Windows Management Instrumentation (WMI) class. 1 The HBA must properly implement the MSiSCSI_InitiatorSessionInfo WMI class. 2 The HBA must properly implement the MSiSCSI_PersistentLogins WMI class. 3 The HBA must properly implement the MSiSCSI_TargetMappings WMI class. 4 The HBA must properly implement the MSiSCSI_LUNMappingInformation WMI class. 5 The HBA must properly implement the MSiSCSI_HBASessionConfig WMI class. 6 The HBA must properly implement the MSiSCSI_PortalInfoClass WMI class. 7 The HBA must properly implement the MSiSCSI_TCPIPConfig WMI class. 8 The HBA must properly implement the MSiSCSI_NICConfig WMI class. 9 The HBA must properly implement the MSiSCSI_BootConfiguration WMI class. 10 The HBA must properly implement the MSiSCSI_SecurityCapabilities WMI class. 11 The HBA must properly implement the MSiSCSI_DiscoveryConfig WMI class. 12 The HBA must properly implement the MSiSCSI_RADIUSConfig WMI class. 13 The HBA must properly implement the MSiSCSI_ConnectionStatistics WMI class. 14 The HBA must properly implement the MSiSCSI_SessionStatistics WMI class. 15 The HBA must properly implement the MSiSCSI_InitiatorLoginStatistics WMI class. 16 The HBA must properly implement the MSiSCSI_InitiatorInstanceStatistics WMI class. 17 The HBA must properly implement the MSiSCSI_MMIPSECStats WMI class. 18 The HBA must properly implement the MSiSCSI_MMIPSECStats WMI class. 19 The HBA must properly implement the MSiSCSI_NICPerformance WMI class.


NTFS File Security Test

Overview

This test performs basic NTFS security variations to ensure that there are no regressions in this area.

Details

This test will perform various NTFS security variations including privileged operations, and impersonation to gain access to files and directories that have specific types of ACLs set on them.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running NTFS File Security Test

Run the NTFS File Security Test Job from Job Explorer. Make sure to specify the NTFS_DRIVE_LETTER parameter.

Command Syntax

Command option | Description

Code Tour

File Manifest

File | Location
fileSec.exe | nttest\BASETEST\core_file_Services\NTFS\security\fileSec.exe

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


iSCSI Persistent Login Test

Type: Automated Test

Overview

The iSCSI Persistent Login test verifies the basic functionality of persistent logons, and verifies that targets are logged on every time the operating system restarts.

Details

This test verifies that the Microsoft iSCSI initiator service is running on the system being tested. The test verifies that the host-bus adapter (HBA) driver properly returns the current list of registered persistent targets. The test attempts to add a disk target to the list of current persistent targets and then verifies that the target persists after the system restarts.
The test uses an additional application that is used to access the target after the system restarts. This test application, Hitdisk.exe, must be located in the working directory of the iSCSI Persistent test program.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running iSCSI Persistent Login Test

Logon to the disk target and format the drive. The disk target should have a drive letter before running the test
Run the test as a DTM job

 Fill the required data in the configuration UI that pops up when this job is scheduled

Command Syntax

Command option | Description
iscsi_plogin -phase 1 -hct |

Cautions

Troubleshooting

  1. Look at the job results log file for test failures
  2. Check if the target has a drive letter
  3. Verify the data entered in the configuration dialog (Popup Dialog box when the job is scheduled from device console)

Reference Documentation

Code Tour

File Manifest

File | Location
iscsi_plogin.exe | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\iscsi

Click to show or hide information. Test Assertions

Test Assertions

1.1 The Microsoft ISCSI Initiator service must be installed.
Test Assertion GUID: 77ac12a0-c4d9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Persistent Login test verifies that the Microsoft initiator service is running on the system that is being tested. Apply: The test uses the service control manager APIs to verify that the Microsoft iSCSI initiator service (iscsiexe.exe) is present and started. If the service is not already started, the test automatically starts the service. Expect: The HBA establishes a TCP/IP connection with the test target.

1.2 The HBA must successfully return a list of current persistent targets.
Test Assertion GUID: 77ac12a1-c4d9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The test verifies that the HBA driver properly returns the current list of registered persistent targets. Apply: The test queries the iSCSI initiator service for the list of currently registered persistent targets by using the ReportIScsiPersistentLogins routine. Expect: The HBA driver successfully returns the current list of persistent targets registered with it.

1.3 The HBA must successfully add the test target as a persistent target.
Test Assertion GUID: 77ac12a2-c4d9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The test attempts to add the disk target used for HCT testing to the list of current persistent targets. Apply: The test uses the LoginIScsiTarget routine with the IsPersistent parameter set to TRUE, indicating that the specified target should be added as a persistent target. Expect: The HBA driver successfully adds the persistent target and returns STATUS_SUCCESS to indicate this condition.

1.4 The HBA must report the test target in the list of persistent targets.
Test Assertion GUID: 77ac12a3-c4d9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The test verifies that the HBA driver properly returns the current list of registered persistent targets. Apply: The test queries the iSCSI initiator service for the list of currently registered persistent targets using the ReportIScsiPersistentLogins routine. Expect: The list of persistent targets that the HBA returns includes the disk target added as a persistent target.

1.5 The test service must be started following reboot.
Test Assertion GUID: 77ac12a4-c4d9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The test verifies that the HBA driver properly reestablishes a persistent target after the system is restarted. Apply: Before restarting, the test installs a test service that tries to access the disk target that is installed as a persistent target. This test service is made to depend on the iSCSI initiator service. Therefore, the test service should not start until the drive is available. Expect: The test service can read/write from the persistent volumes. The test service fails to start if it cannot access those volumes.


Medium changer stress

Type: Automated Test

Overview

The target component for this test utility is the medium changer device and driver and its interoperation with Removable Storage Management (RSM). This test stresses various RSM calls and verifies that the device responds as expected.

Details

This utility will create several threads to stress different subsets of RSM calls concurrently.
This is an extended stress test that repeatedly executes various Removable Storage Management (RSM) operations, such as opening and closing sessions and creating and deleting media pools on changers and jukeboxes.
The test also verifies the functionality of various media services application programming interfaces (APIs) by means of approximately 28 different scenarios:
  1. Open\Close
  2. Get Info All
  3. Multiple Open\Close
  4. Create Delete Media Pool
  5. Export Database
  6. Move Media From Other System Pools To Free Poo
  7. Move\Allocate\Mount\Dismount\Deallocate\Move Media
  8. Create\Delete Tree Of Media Pools
  9. Get & Set Info All
  10. Multiple Move\Allocate\Mount\Dismount\Deallocate\Move Media
  11. Set & Get Attribute
  12. Create\Delete Media Pool Of All Media Types
  13. Get All Pool Names
  14. Create\Delete Media Pool Of Any Media Type
  15. Multiple Allocate\Deallocate Media
  16. Allocate\Deallocate Media With Alocation Policy
  17. Create\Delete Multiple Media Pool
  18. Move\Allocate\Deallocate\Move All Available Media
  19. Move\Allocate\Deallocate\Move Media
  20. Move Media Between Application Media Pools
  21. Move Single Media Between Media Pools
  22. Request Ordering Of A Library
  23. Operator Requests
  24. Move Media Randomly Between Pools
  25. Multiple Operator Requests
  26. Move Multiple Media Between Media Pools
  27. Create\Delete Media Pool Of Any Media Type
  28. Add\Delete Media Types In A Library One At A Time

Run Time: 2 hours
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Media and Cleaning cartridge.

Running Medium changer stress

This test requires a system with at least one medium changer (device under test). The test requires writable media and cleaning cartridges (if applicable) in the medium changer. The media may be overwritten.
Additionally, on Microsoft Windows Vista, the Removable Storage Management (RSM) optional component must be installed.

Command Syntax

Command option | Description
mcstress.exe /d 120 |

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location
mcstress.exe | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk

Click to show or hide information. Test Assertions

Test Assertions

Add Delete Media Types From All Libraries One At A Time
Test Assertion GUID: deccab14-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Add Delete Media Types In A Library All At A Time
Test Assertion GUID: deccab13-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Add Delete Media Types In A Library One At A Time
Test Assertion GUID: deccab12-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Allocate Deallocate Media
Test Assertion GUID: deccab04-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Allocate Deallocate Media With Alocation Policy
Test Assertion GUID: deccab01-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Create And Delete Media Pool Of Any Media Type
Test Assertion GUID: deccab0f-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Create Delete Media Pool Of All Media Types
Test Assertion GUID: deccab0e-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Create Delete Multiple Media Pool
Test Assertion GUID: deccab0d-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Create Delete Tree Of Media Pools
Test Assertion GUID: deccab10-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Create-Delete Single Media Pool
Test Assertion GUID: deccab11-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Export Database
Test Assertion GUID: deccaa06-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Get All Pool Names
Test Assertion GUID: deccab20-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Get And Set Information About All Objects
Test Assertion GUID: deccab08-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Get Information About All Objects
Test Assertion GUID: deccab07-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Inventory All Ntms Libraries
Test Assertion GUID: deccab0a-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Inventory An Ntms Library
Test Assertion GUID: deccab09-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Move Allocate Deallocate Move All Available Media
Test Assertion GUID: deccab02-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Move Allocate Deallocate Move Media
Test Assertion GUID: deccab00-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Move Allocate Mount Dismount Deallocate Move Media
Test Assertion GUID: deccab16-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Move Media Between Application Media Pools
Test Assertion GUID: deccab1b-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Move Media From Other System Pools To Free Pool
Test Assertion GUID: deccab1d-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Move Media Randomly Between Pools
Test Assertion GUID: deccab1c-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Move Multiple Media Between Media Pools
Test Assertion GUID: deccab1a-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Move Single Media Between Media Pools
Test Assertion GUID: deccab19-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Multiple Move Allocate Mount Dismount Deallocate Move Media
Test Assertion GUID: deccab17-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Multiple Open-Multiple Close
Test Assertion GUID: deccab23-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Notification
Test Assertion GUID: deccab21-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Request Ordering Of A Library
Test Assertion GUID: deccab0b-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Request Ordering Of All Libraries
Test Assertion GUID: deccab0c-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Set And Get Attribute of All Objects
Test Assertion GUID: deccaa05-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Single Open-Close
Test Assertion GUID: deccab22-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Submit-Wait-Cancel Operator request - Multiple
Test Assertion GUID: deccab1f-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Submit-Wait-Cancel Operator request - One
Test Assertion GUID: deccab1e-c5be-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:


DMA Test

Type: Automated Test

Overview

The DMA test checks the ability of a driver to set a specified DMA (Direct Memory Access) timing mode for a device. The test checks that the driver can do so while I/O is pending without corrupting the transfer.

Details

The DMA test checks the ability of a driver to set a specified DMA (Direct Memory Access) timing mode for a device. For all devices in the system, the DMA test attempts to set all timing modes supported by the device. There are three variations: highest mode to lowest mode; lowest mode to highest mode; and lowest mode to highest mode with a pause (the default is 20,000 milliseconds) between variations. The test also runs multi-threaded file I/O in the background, runs file I/O with copy from each available source to each valid destination, compares the copied data, and reports passes or failures based on the compare function.
The DMA test is an automated test designed to ensure that ATA/ATAPI storage drivers correctly time devices as specified by the user or the system. If the system has a controller that supports ULTRADMA 3 or faster, you must attach an 80-pin cable for accurate results.

Run Time: 90 Minutes
Log File: dmatest.wtl
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • ATAPI Optical drive and non-blank media.

Running DMA Test

This test requires a system with at least one ATA/ATAPI device to run. If a system is using the PCIIDE minidriver, the system fails all DMA variations except for PIO4 and the mode that the device was running at start time because the generic driver does not know which registers to use to set up timing modes. The test requires a CD with data be inserted in all CD drives connected to the controller, and will prompt on the client machine if this is not the case.

Command Syntax

Command option | Description
DMATest.exe /ng /deviceinstance:"[WDKDeviceID]" /logo |

Cautions

Make sure that any volumes on fixed disks are formatted and writeable.

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location
DMATest.exe | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk

Click to show or hide information. Test Assertions

Test Assertions

PIO0 If PIO0 is supported, device must allow switching to PIO0 during IO.
Test Assertion GUID: 1e76d583-c379-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

PIO1 If PIO1 is supported, device must allow switching to PIO1 during IO.
Test Assertion GUID: 1e76d584-c379-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

PIO2 If PIO2 is supported, device must allow switching to PIO2 during IO.
Test Assertion GUID: 1e76d585-c379-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

PIO3 If PIO3 is supported, device must allow switching to PIO3 during IO.
Test Assertion GUID: 1e76d586-c379-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

PIO4 If PIO4 is supported, device must allow switching to PIO4 during IO.
Test Assertion GUID: 1e76d587-c379-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

SWDMA0 If SWDMA0 is supported, device must allow switching to SWDMA0 during IO.
Test Assertion GUID: 1e76d588-c379-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

SWDMA1 If SWDMA1 is supported, device must allow switching to SWDMA1 during IO.
Test Assertion GUID: 1e76d589-c379-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

SWDMA2 If SWDMA2 is supported, device must allow switching to SWDMA2 during IO.
Test Assertion GUID: 1e76d58a-c379-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

MWDMA0 If MWDMA0 is supported, device must allow switching to MWDMA0 during IO.
Test Assertion GUID: 1e76d58b-c379-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

MWDMA1 If MWDMA1 is supported, device must allow switching to MWDMA1 during IO.
Test Assertion GUID: 1e76d58c-c379-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

MWDMA2 If MWDMA2 is supported, device must allow switching to MWDMA2 during IO.
Test Assertion GUID: 1e76d58d-c379-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

UDMA0 If UDMA0 is supported, device must allow switching to UDMA0 during IO.
Test Assertion GUID: 1e76d58e-c379-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

UDMA1 If UDMA1 is supported, device must allow switching to UDMA1 during IO.
Test Assertion GUID: 1e76d58f-c379-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

UDMA2 If UDMA2 is supported, device must allow switching to UDMA2 during IO.
Test Assertion GUID: 1e76d590-c379-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

UDMA3 If UDMA3 is supported, device must allow switching to UDMA3 during IO.
Test Assertion GUID: 1e76d591-c379-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

UDMA4 If UDMA4 is supported, device must allow switching to UDMA4 during IO.
Test Assertion GUID: 1e76d592-c379-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

UDMA5 If UDMA5 is supported, device must allow switching to UDMA5 during IO.
Test Assertion GUID: 1e76d593-c379-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

DMATEST ATA Controller must support switching transfer modes during IO.
Test Assertion GUID: 1e76d594-c379-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: The controller must not corrupt data or stop responding when switching transfer modes during IO.

Initializing Controller must be installed and set up as specified in the Logo Program Setup documentation.
Test Assertion GUID: 1e76d595-c379-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Be sure to connect both the necessary Hard Disk(s) and optical device. Place non-blank media in the optical device.


iSCSI Ping Test (HBA)

Type: Automated Test

Overview

The iSCSI Ping (HBA) test verifies that iSCSI initiators (HBA) can send and receive ping requests.

Details

This test operates in two phases. The first phase verifies that the HBA responds to ping requests by sending a ICMP echo packets to the HBA using a network card in the test system. The second phase verifies the HBA can send ICMP echo packets to another address, which in this case is the network card in the test system.
Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running iSCSI Ping Test (HBA)

Run the test as a DTM job.
Fill the required data in the configuration UI that pops up when this job is scheduled

Command Syntax

Command option | Description
iscsi_pingtest -initiator -hct |

Cautions

Troubleshooting

  1. Look at the job results log file for test failures
  2. Verify the data entered in the configuration dialog (Popup Dialog box when the job is scheduled from device console)

Reference Documentation

Code Tour

File Manifest

File | Location
iscsi_pingtest.exe | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\iscsi

Click to show or hide information. Test Assertions

Test Assertions

1 The device being tested must return an Internet Control Message Protocol (ICMP) Echo Reply packet with the same 32 bytes of data issued in the original request.
Test Assertion GUID: f0e221bd-c4da-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test checks an iSCSI target or initiator's ability to respond to an echo request initiated by the host to the device being tested. This test is run five times against the device being tested. Apply: Sends ICMP Echo packets with a request buffer size of 32 bytes.Expect: The device being tested returns an ICMP Echo Reply packet with the same 32 bytes of data issued in the original request.

2 The device being tested must be able to send multiple ICMP Echo Reply packets to the host.
Test Assertion GUID: f0e221be-c4da-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Ping (HBA/Target) test checks an iSCSI target or initiator’s ability to send an ICMP Echo Reply packet to the host. This test is run five times against the device being tested. Apply: Listens for ICMP Echo packets with a request buffer size of up to 64 KB. Expect: The device being tested can send multiple ICMP Echo Reply packets to the host.


Crashdump Support Test

Type: Automated Test

Overview

The OS supports the creation of memory dump file after a system stop error through the underlying storage miniport driver. The target component for this test utility is the storage miniport driver. During a system crash, the storage miniport will be called by the OS crash dump components to write memory contents to the physical disk.
The goal of the test is to verify that the storage miniport writes data to the disk correctly and that a valid memory dump file gets generated after a system crash. The Windows OS allows three different types of memory dump files to be generated: full, kernel, and mini. The test will test all three dump file types. For further information about these dump file types, please refer to the Microsoft Kernel Debugger documentation.

Details

The test will install Debugging Tools for windows to the %SystemDrive%\Debuggers directory and setup AutoLogon for the DTM-created Administrator on the machine.
This utility will install and start a basic driver service on the local machine and simulate system crashes by sending bugcheck codes through this driver. Once the system reboots, the utility will run automatically and examine the previous crash by analyzing the memory dump file through the kernel debugger, and parsing debugger output. The test will do this by using bugcheck code 0x0000007B and by enumerating through full, kernel, and mini crash dump modes.

Run Time: 45 minutes
Log File:
System Restart Required: Yes
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running Crashdump Support Test

  1. Install Windows Symbols Package to c:\symbols from: http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx
  2. Run test as DTM job.

Command Syntax

Command option | Description
crashdumptest.exe -hct -lp * -dtm |

Cautions

Troubleshooting

If this test fails in any phase other than the logging phase check the following things:
  1. Is the test launching each run task? Choose "View Errors". If it is not fix this by ensuring that the Configure job for the Logo Program has run on your machine.
  2. Is the system bugchecking with a code other than 0x0000007B? If so, this is an unexpected bugcheck and should considered as a driver / hardware failure. Follow up with the developer.
  3. If a task is failing for any other reason, the symbols may be incorrect or incomplete.

Reference Documentation

Code Tour

File Manifest

File | Location
crashdumptest.exe | …\tests\%ARCHITECTURE\nttest\driverstest\storage\wdk

Click to show or hide information. Test Assertions

Test Assertions

1.1 INACCESSIBLE_BOOT_DEVICE, Full memory dump: Pre-crash and crashdump file devnode count must match.
Test Assertion GUID: eb3e064c-c36d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

1.2 INACCESSIBLE_BOOT_DEVICE, Full memory dump: Bugcheck code and user parameter must match and verify Advanced RISC Computing specification name for the device.
Test Assertion GUID: eb3e064d-c36d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

1.3 INACCESSIBLE_BOOT_DEVICE, Full memory dump: All loaded drivers should be written to dump file.
Test Assertion GUID: eb3e064e-c36d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

1.4 INACCESSIBLE_BOOT_DEVICE, Full memory dump: Verify processes and all children threads.
Test Assertion GUID: eb3e064f-c36d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

1.5 INACCESSIBLE_BOOT_DEVICE, Full memory dump: CPU vendors info must match. Verify threads running on all CPUs.
Test Assertion GUID: eb3e0650-c36d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

1.6 INACCESSIBLE_BOOT_DEVICE, Full memory dump: Dump file size must be greater than physical memory size.
Test Assertion GUID: eb3e0651-c36d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

1.7 INACCESSIBLE_BOOT_DEVICE, Full memory dump: Verify memusage summary info.
Test Assertion GUID: eb3e0652-c36d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

1.8 INACCESSIBLE_BOOT_DEVICE, Full memory dump: Verify virtual memory summary info.
Test Assertion GUID: eb3e0653-c36d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

1.9 INACCESSIBLE_BOOT_DEVICE, Full memory dump: Verify resource locks summary info.
Test Assertion GUID: eb3e0654-c36d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

2.1 INACCESSIBLE_BOOT_DEVICE, Kernel memory dump: Pre-crash and crashdump file devnode count must match.
Test Assertion GUID: eb3e0655-c36d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

2.2 INACCESSIBLE_BOOT_DEVICE, Kernel memory dump: Bugcheck code and user parameter must match.
Test Assertion GUID: eb3e0656-c36d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

2.3 INACCESSIBLE_BOOT_DEVICE, Kernel memory dump: All loaded drivers should be written to dump file.
Test Assertion GUID: eb3e0657-c36d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

2.4 INACCESSIBLE_BOOT_DEVICE, Kernel memory dump: Verify processes and all children threads.
Test Assertion GUID: eb3e0658-c36d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

2.5 INACCESSIBLE_BOOT_DEVICE, Kernel memory dump: CPU vendors info must match. Verify threads running on all CPUs.
Test Assertion GUID: eb3e0659-c36d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

2.6 INACCESSIBLE_BOOT_DEVICE, Kernel memory dump: Dump file size must be 1/3 (relative) of physical memory size.
Test Assertion GUID: eb3e065a-c36d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

2.7 INACCESSIBLE_BOOT_DEVICE, Kernel memory dump: Verify memusage summary info.
Test Assertion GUID: eb3e065b-c36d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

2.8 INACCESSIBLE_BOOT_DEVICE, Kernel memory dump: Verify virtual memory summary info.
Test Assertion GUID: eb3e065c-c36d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

2.9 INACCESSIBLE_BOOT_DEVICE, Kernel memory dump: Verify resource locks summary info.
Test Assertion GUID: eb3e065d-c36d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

3.1 INACCESSIBLE_BOOT_DEVICE, Mini memory dump: Bugcheck code and user parameter must match.
Test Assertion GUID: eb3e065e-c36d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

3.2 INACCESSIBLE_BOOT_DEVICE, Mini memory dump: Dump file size must be 64 KB.
Test Assertion GUID: eb3e065f-c36d-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:


SCSI Compliance test

Type: Automated Test

Overview

This test verifies that a SCSI device supported by the operating system fully complies with the SCSI standards described in the SCSI-3 Primary Commands (SPC), SPC-2, and SCSI Block Commands (SBC) specifications (to obtain these specifications, see the T10 Technical Committee Web site at www.t10.org ). Ensuring that the SCSI device and the operating system maintain compliance with these standards makes for a more robust and reliable system.
The test uses SCSI pass-through requests (IOCTL_SCSI_PASS_THROUGH) to construct and send SCSI command descriptor blocks (CDB) to the device. The test evaluates the results of the commands to verify compliance.

Details

The SCSI Compliance test consists of several phases: setup, device enumeration, execution, and results reporting. The test operates in two modes:
  • An automated non-destructive test that runs against all SCSI devices.
  • A destructive test that targets one or more specified disks.
A number of tests are performed for each command to test compliance. The program stores the test results in a matrix, indicating the results for each command on each device. When the test is completed, a summary report of the results is generated.
Functionality Testing
The test sends the following commands down to the device. The test runs a variety of tests for each command descriptor block (CDB) to ensure full and complete compliance.
SCSI
  • INQUIRY
  • REQUEST SENSE
  • TEST UNIT READY
  • MODE SENSE (6)
  • MODE SENSE (10)
  • MODE SELECT (6)
  • MODE SELECT (10)
  • RESERVE (6)
  • RELEASE (6)
  • READ CAPACITY
  • LONGLBA Support
  • READ (6)
  • READ (10)
  • READ (16)
  • WRITE (6)
  • WRITE (10)
  • WRITE (10) with FUA bit
  • WRITE (16)
  • WRITE (16) with FUA bit
  • SYNCHRONIZE CACHE
Robustness and Reliability Testing
To validate robustness and reliability, the test performs the following steps:
  • Checks for valid return codes for each IOCTL_SCSI_PASS_THROUGH request.
  • Checks adherence to data buffer length.
  • If the buffer size is insufficient, the test verifies that the IOCTL returns with the correct required length.
  • Verifies that non-destructive tests do not change any system configuration or data.
  • Verifies that repeated calls return the same or similar data.

Run Time: 30 minutes*
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Windows 2000
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running SCSI Compliance test

1. Run the test as a DTM Job

Command Syntax

Command option | Description
ScsiComplianceTest.exe -hct [PhysicalDeviceObjectLink] or Drive Letter | ScsiComplianceTest [-v [level]] [-full] [-hct][-iscsi] [-mi device] [device | -alldevices]OptionDescription-v [level]Sets the logging verbosity level. Level can be specified as 0, 1, or 2. 0 = List assertions tested and results.1 = Show assertion details (default).2 = Show CDBs sent to device, data, and sense data returned.-fullSpecify that the destructive tests should also be run.-hctRun as part of an HCT test pass.-iscsiTest iSCSI compliance.-mi deviceRun the multi-initiator tests on the specified device, where the device points to the device under test by way of a second initiator.deviceThe device to test (for example: \\.\physicaldrive1, \\.\d:).-alldevicesTo test all devices.-?Show usage.

Cautions

Troubleshooting

The test writes the results to the log files scsicompliance.log.xml and scsicompliance.log.txt. Use the results to determine:
  • If a device is compliant to the SCSI specification.
  • The optional SCSI commands supported by a device.
To pass, the SCSI device must support every mandatory command and must be fully compliant with those commands. Each command has a different threshold for pass or fail, and the expectations are specified explicitly in test and in the log file.
Optional commands are also tested. If a device supports the optional commands and the commands are found to be non-compliant, the test fails. If the device does not support optional commands, the test passes.

Reference Documentation

SPC-2 (SCSI Primary Commands - 2) Specification, Revision 20

Code Tour

File Manifest

File | Location
scsicompliancetest.exe | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk

Click to show or hide information. Test Assertions

Test Assertions

1.1 INQUIRY Basic Verification Test
Test Assertion GUID: 6bfd171e-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks the support for a simple INQUIRY command and validates the returned data size. Apply: The test sends a simple INQUIRY command and requests 0xff bytes of INQUIRY data. Expect: The command should return GOOD status; the data size should be less than 0xff and greater than 0x0.

1.2 INQUIRY Test with ALLOCATION LENGTH Field
Test Assertion GUID: 6bfd171f-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that an INQUIRY command returns the correct amount of data, given various allocation sizes. Apply: The test requests INQUIRY data in 0x10 byte increments. Expect: The device should return the amount of data that was requested.

1.3 INQUIRY Test with CMDDT and EVPD Field Set
Test Assertion GUID: 6bfd1720-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that a status of CHECK CONDITION is returned when CMDDT=1 and EVPD=1. Apply: The test sends an INQUIRY command descriptor block (CDB) with CMDDT=1 and EVPD=1. Expect: The value of ScsiStatus should be 0x2, CHECK CONDITION.

1.4 INQUIRY Test for error when PAGE CODE field is nonzero and EVPD=0.
Test Assertion GUID: 6bfd1721-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the device returns an error when the PAGE CODE field is nonzero and EVPD=0. Apply: The test sets the PAGE CODE field to 0xff and the EVPD bit to 0. Expect: The value of ScsiStatus should be 0x2, CHECK CONDITION.

1.5 INQUIRY Retrieving standard inquiry data.
Test Assertion GUID: 6bfd1722-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks the device's ability to retrieve standard INQUIRY data. Apply: The test sends a simple INQUIRY CDB. Expect: The value of ScsiStatus should be 0x0, GOOD.

1.6 INQUIRY Checking size of standard inquiry data.
Test Assertion GUID: 6bfd1723-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that standard INQUIRY data contains at least 36 bytes. Apply: The test sends a standard INQUIRY command. Expect: The device should return a transfer length for the data that is greater than or equal to 36 bytes.

1.7 INQUIRY Testing device type field.
Test Assertion GUID: 6bfd1724-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Optional: The TD-28.25 SCSI Compliance test checks the device type field to ensure the device is a direct access device. Apply: The test checks device type field. Expect: The value of the device type field should be 0x0, direct-access device.

1.8 INQUIRY Testing peripheral qualifier field.
Test Assertion GUID: 6bfd1725-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Optional: The TD-28.25 SCSI Compliance test ensures that valid data is in PERIPHERAL QUALIFIER field. Apply: The test sends a standard INQUIRY command. Expect: The value in the PERIPHERAL QUALIFIER field should be zero.

1.9 INQUIRY VERSION Field Test
Test Assertion GUID: 6bfd1726-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks the VERSION field to make sure the device complies with the SPC-2 standard. Apply: The test sends a standard INQUIRY command. Expect: The value in the VERSION field should be greater than or equal to 0x3.

1.10 INQUIRY Checking RESPONSE DATA FORMAT.
Test Assertion GUID: 6bfd1727-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test check that the RESPONSE DATA FORMAT field has valid data. Apply: The test sends a standard INQUIRY command. Expect: The value in the RESPONSE DATA FORMAT field should be two.

1.11 INQUIRY Checking additional length.
Test Assertion GUID: 6bfd1728-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test verifies that the ADDITIONAL LENGTH field is correct. Apply: The test sends a standard INQUIRY command. Expect: ADDITIONAL LENGTH field == Total Data size - 5 == 91.

1.12 INQUIRY Checking VENDOR IDENTIFICATION field.
Test Assertion GUID: 6bfd1729-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the VENDOR IDENTIFICATION field contains valid ASCII data. Apply: The test sends a standard INQUIRY command. Expect: The VENDOR IDENTIFICATION field should contain valid ASCII data.

1.13 INQUIRY Checking PRODUCT IDENTIFICATION field.
Test Assertion GUID: 6bfd172a-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the PRODUCT IDENTIFICATION field contains valid ASCII data. Apply: The test sends a standard INQUIRY command. Expect: The PRODUCT IDENTIFICATION field should contain valid ASCII data.

1.14 INQUIRY Checking PRODUCT REVISION LEVEL field.
Test Assertion GUID: 6bfd172b-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the PRODUCT REVISIONLEVEL field contains valid ASCII data. Apply: The test sends a standard INQUIRY command. Expect: The PRODUCT REVISION LEVEL field should contain valid ASCII data.

1.15 INQUIRY Command Support Data Test
Test Assertion GUID: 6bfd172c-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Optional: The TD-28.25 SCSI Compliance test checks if command support data is supported. Apply: The test sets CMDT = 1 and PAGE CODE = 0 to see if TEST UNIT READY is supported. Expect: The value of ScsiStatus should be 0x0.

1.16 INQUIRY Testing Command Support Data for all page codes.
Test Assertion GUID: 6bfd172d-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks the command support data for each page code. Apply: The test tests PAGE CODES from 0x0 to 0xff. Expect: The value of ScsiStatus should be 0 and the value of CdbSize should be DataTransferLength – 6.

1.17 INQUIRY Checking for Supported Vital Product Pages.
Test Assertion GUID: 6bfd172e-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test ensures that Vital Product Pages are supported. Apply: The test sets EVPD = 1 and Page Code = 0. Expect: The device should return a list of supported Vital Product Data Pages.

1.18 INQUIRY Testing access to each supported Vital Product Data Page.
Test Assertion GUID: 6bfd172f-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test attempts to access each supported Vital Product Data Page. Apply: The test tests each page code that is returned from supported Vital Product Data Pages. Expect: Each supported page should be accessible.

1.19 INQUIRY Attempting Unit Serial Number Page 0x80.
Test Assertion GUID: 6bfd1730-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks if unit serial number page 0x80 is supported and is valid ASCII data. Apply: The test sets Page Code = 0x80. Expect: The value of ScsiStatus should be 0x0 and the result should be valid ASCII data.

1.20 INQUIRY Attempting Device identification Page 0x83.
Test Assertion GUID: 6bfd1731-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test verifies that the device identification page 0x83 is supported. Apply: The test sets Page Code = 0x83. Expect: The value of ScsiStatus should be 0x0.

1.21 Checking Identification Descriptors in VPD page 0x83.
Test Assertion GUID: 6bfd1732-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that Identification descriptors contain meaningful data. Apply: The test sets Page Code = 0x83. Expect: All descriptors should be compliant and contain meaningful data.

1.22 INQUIRY Checking Version Descriptors.
Test Assertion GUID: 6bfd1733-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks if the values in the VERSION DESCRIPTOR fields are compliant. Apply: The test sends a standard INQUIRY command. Expect: All descriptors should be compliant and contain meaningful data.

1.23 Checking Windows Device Identifiers.
Test Assertion GUID: 6bfd1734-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

2.1 MODE SENSE (6) Testing simple MODE SENSE command.
Test Assertion GUID: 6bfd1735-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks if a simple MODE SENSE command on Page 0x3f will return GOOD status. Apply: The test sends a MODE SENSE command with Page Code set to 0x3f. Expect: The value of ScsiStatus should be 0x0.

2.2 MODE SENSE (6) Checking size of returned data.
Test Assertion GUID: 6bfd1736-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test verifies that a minimum amount of data (at least the MODE PARAMETER HEADER) is returned. Apply: The test sends a simple MODE SENSE command. Expect: The transfer length of the data should be greater than or equal to 4 bytes.

2.3 MODE SENSE (6) Checking MODE PARAMETER HEADER.
Test Assertion GUID: 6bfd1737-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test verifies that the MODE PARAMETER HEADER length information is valid. Apply: The test examines the current MODE PARAMETER HEADER. Expect: The value of ModeDataLength should be Data Transfer Length - 1 == 229 bytes.

2.4 MODE SENSE (6) Test DBD (disable block descriptors) bit.
Test Assertion GUID: 6bfd1738-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test makes sure that no block descriptors are returned when a DBD bit is set. Apply: The test sets DBD = 1. Expect: The device should set Block Descriptor Length == 0.

2.5 MODE SENSE (6) Testing new data length when DBD bit is set.
Test Assertion GUID: 6bfd1739-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the new data length equals the old data length minus the block descriptor length. Apply: The test examines the current data. Expect: The new data length should equal the old data length minus the block descriptor length.

2.6 MODE SENSE (6) Comparing MODE PAGE data before and after DBD bit is set.
Test Assertion GUID: 6bfd173a-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test makes sure that page data is the same before and after the DBD bit is set. Apply: The test compares page data before and after the DBD bit is set. Expect: The page data should match.

2.7 MODE SENSE (6) Testing Page Control Field.
Test Assertion GUID: 6bfd173b-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks different values of the page control field and enforces the size of the data that is returned. Apply: The test tests the page control field from 00b to 11b. Expect: The data length for each value of the page control field should be correct.

2.8 MODE SENSE (6) Scanning All Mode Pages.
Test Assertion GUID: 6bfd173c-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks mode page 0x3f data to examine the supported mode pages. Apply: The test examines current data. Expect: The test should find the supported mode pages.

2.9 MODE SENSE (6) Ensuring mandatory mode pages are supported.
Test Assertion GUID: 6bfd173d-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Optional: The TD-28.25 SCSI Compliance test checks that required mode pages are present in MODE PAGE 0x3f. Apply: The test examines current data. Expect: At a minimum, the device supports the Control and Disconnect/Reconnect pages.

2.10 MODE SENSE (6) Checking Individual Mode Pages.
Test Assertion GUID: 6bfd173e-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test ensures that each individual mode page can be accessed and that the parameters are correct. Apply: The test sends MODE SENSE commands for each supported mode page that is returned in 0x3f. Expect: The pages should be returned and the headers should be compliant.

2.11 MODE SENSE (6) Checking Control Mode Page.
Test Assertion GUID: 6bfd173f-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test verifies that the control mode page is compliant. Apply: The test sends a MODE SENSE command to retrieve the control mode page. Expect: The control mode page should be supported.

2.12 MODE SENSE (6) Checking Disconnect/Reconnect Mode Page.
Test Assertion GUID: 6bfd1740-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test ensures that the disconnect-reconnect mode page is compliant. Apply: The test sends a MODE SENSE command to retrieve the disconnect-reconnect mode page. Expect: The disconnect-reconnect mode page should be supported.

2.13 MODE SENSE (6) Checking Informational Exception Mode Page.
Test Assertion GUID: 6bfd1741-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: [Deleted]

2.14 MODE SENSE (6) Checking Power Condition Mode Page.
Test Assertion GUID: 6bfd1742-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: [Deleted]

2.15 MODE SENSE (6) Checking Caching Mode Page.
Test Assertion GUID: 6bfd1743-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test ensures that the caching mode page is compliant. Apply: The test sends a MODE SENSE command to retrieve the caching mode page. Expect: The caching mode page should be supported.

2.16 MODE SENSE (6) Checking Format Device Mode Page.
Test Assertion GUID: 6bfd1744-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test ensures that the format device mode page is compliant. Apply: The test sends a MODE SENSE command to retrieve the format device mode page. Expect: The format device mode page should be supported.

2.17 MODE SENSE (6) Checking Rigid Disk Geometry Mode Page.
Test Assertion GUID: 6bfd1745-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test ensures that the rigid disk geometry mode page is compliant. Apply: The test sends a MODE SENSE command to retrieve the rigid disk geometry mode page. Expect: The rigid disk geometry mode page should be supported.

2.18 MODE SENSE (6) Checking Device Specific Parameters.
Test Assertion GUID: 6bfd1746-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test verifies that the device-specific parameters are supported.

3.1 MODE SENSE (10) Testing simple MODE SENSE command.
Test Assertion GUID: 6bfd1747-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks if a simple MODE SENSE command on Page 0x3f will return GOOD status. Apply: The test sends a MODE SENSE command with Page Code set to 0x3f. Expect: The value of ScsiStatus should be 0x0.

3.2 MODE SENSE (10) Checking size of returned data.
Test Assertion GUID: 6bfd1748-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test verifies that a minimum amount of data (at least the MODE PARAMETER HEADER) is received. Apply: The test sends a simple MODE SENSE command. Expect: The transfer length of the data should be greater than or equal to 8 bytes.

3.3 MODE SENSE (10) Checking MODE PARAMETER HEADER.
Test Assertion GUID: 6bfd1749-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the MODE PARAMETER HEADER length information is valid. Apply: The test examines the current MODE PARAMETER HEADER. Expect: ModeDataLength == Data Transfer Length - 2 == 233 bytes.

3.4 MODE SENSE (10) Test DBD (disable block descriptors) bit.
Test Assertion GUID: 6bfd174a-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test makes sure that, when the DBD bit is set, no block descriptors are returned. Apply: The test sets DBD = 1. Expect: The length of the block descriptors should be equal to zero.

3.5 MODE SENSE (10) Testing new data length when DBD bit is set.
Test Assertion GUID: 6bfd174b-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test ensures that the new data length should equal the old data length minus the block descriptor length. Apply: The test examines the current data. Expect: The new data length should equal the old data length minus the block descriptor length.

3.6 MODE SENSE (10) Comparing MODE PAGE data before and after DBD bit is set.
Test Assertion GUID: 6bfd174c-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test ensures that page data is the same before and after the DBD bit is set. Apply: The test compares page data before and after the DBD bit is set. Expect: The page data should match.

3.7 MODE SENSE (10) Testing Page Control Field.
Test Assertion GUID: 6bfd174d-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks different values of the page control field and enforces the size of the data that is returned. Apply: The test tests values of the page control field from 00b to 11b. Expect: The data length for each value of the page control field should be correct.

4.1 MODE SELECT (6) Testing simple MODE SELECT command.
Test Assertion GUID: 6bfd174e-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test check if a simple MODE SELECT command, with PF and SP == 0, passes. Apply: The test sends a MODE SELECT command with parameters set to zero. Expect: The value of ScsiStatus should be 0x0.

4.2 MODE SENSE (6) Attempting to get Caching mode page.
Test Assertion GUID: 6bfd174f-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks if a simple MODE SENSE command on Page 0x08 will return GOOD status. Apply: The test sends a MODE SENSE command for the caching mode page. Expect: The value of ScsiStatus should be 0x0.

4.3 MODE SENSE (6) Checking Parameters Savable (PS bit).
Test Assertion GUID: 6bfd1750-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Optional: The TD-28.25 SCSI Compliance test checks if the parameters savable (PS) bit for the caching mode page is set to one. Apply: The test sends a MODE SENSE command for the caching mode page. Expect: The PS bit should have a value of 1.

4.4 MODE SENSE (6) Checking Mode Parameter Header.
Test Assertion GUID: 6bfd1751-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test verifies that MediumType == 0 and BlockDescriptorLength == 0. Apply: The test sends a MODE SENSE command for the caching mode page. Expect: The value of MediumType should be 0x0 and the value of BlockDescriptorLength should be 0x0.

4.5 MODE SENSE (6) Checking Caching Mode Page Length.
Test Assertion GUID: 6bfd1752-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the caching mode page is 20 bytes. Apply: The test sends a MODE SENSE command for the caching mode page. Expect: The value of cachePageLength should be 20 bytes.

4.6 MODE SENSE (6) Getting Current Values.
Test Assertion GUID: 6bfd1753-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test saves away current values for caching mode page. Apply: The test sends a MODE SENSE command on the caching mode page with PC == 00b. Expect: The value of ScsiStatus should be 0x0.

4.7 MODE SENSE (6) Getting Changeable values.
Test Assertion GUID: 6bfd1754-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test saves away changeable values for caching mode page. Apply: The test sends a MODE SENSE command on the caching mode page with PC == 01b. Expect: The value of ScsiStatus should be 0x0.

4.8 MODE SENSE (6) Getting default values.
Test Assertion GUID: 6bfd1755-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test saves away default values for caching mode page. Apply: The test sends a MODE SENSE command on the caching mode page with PC == 10b. Expect: The value of ScsiStatus should be 0x0.

4.9 MODE SENSE (6) Getting Saved values.
Test Assertion GUID: 6bfd1756-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: [Deleted]

4.10 MODE SELECT (6) Changing WCE.
Test Assertion GUID: 6bfd1757-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test applies MODE SELECT on all reported changeable values for the device. Apply: The test sends a MODE SELECT command with the changeable caching mode page values set to one. Expect: The value of ScsiStatus should be 0x0.

4.11 MODE SENSE (6) Checking that WCE has been cleared.
Test Assertion GUID: 6bfd1758-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the previous MODE SELECT command actually changed the current mode parameters. Apply: The test sends a MODE SENSE command on the caching mode page. Expect: The current values should have changed.

4.12 MODE SENSE (6) Checking that Saved Values have changed.
Test Assertion GUID: 6bfd1759-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the previous MODE SELECT command actually changed the saved mode parameters. Apply: The test sends a MODE SENSE command on the caching mode page with PS == 11b. Expect: The saved values should have changed.

4.13 MODE SELECT (6) setting WCE.
Test Assertion GUID: 6bfd175a-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test applies a MODE SELECT command to clear all changeable values for the device. Apply: The test sends a MODE SELECT command with changeable caching mode page values set to zero. Expect: The value of ScsiStatus should be 0x0.

4.14 MODE SENSE (6) Checking that WCE has been set.
Test Assertion GUID: 6bfd175b-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the previous MODE SELECT command actually cleared the current mode parameters. Apply: The test sends a MODE SENSE command on the caching mode page. Expect: The current values should have been cleared.

4.15 MODE SELECT (6) Changing non-changeable parameters.
Test Assertion GUID: 6bfd175c-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: [Deleted]

4.16 MODE SELECT (6) Attempting to restore original values.
Test Assertion GUID: 6bfd175d-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test verifies that the MODE SELECT command can return the caching mode page values to their default values. Apply: The test sends a MODE SELECT command with values set to the default values of the caching mode page values. Expect: The value of ScsiStatus should be 0x0.

4.17 MODE SENSE (6) Verifying values were restored.
Test Assertion GUID: 6bfd175e-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the default values were restored in the caching mode page. Apply: The test sends a MODE SENSE command on the caching mode page. Expect: The current values should equal the default values.

5.1 MODE SELECT (10) Testing simple MODE SELECT command.
Test Assertion GUID: 6bfd175f-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks if a simple MODE SELECT command, with PF and SP == 0, passes. Apply: The test sends a MODE SELECT command with parameters set to zero. Expect: The value of ScsiStatus should be 0x0.

5.2 MODE SENSE (10) Attempting to get Caching mode page.
Test Assertion GUID: 6bfd1760-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks if a simple MODE SENSE command on page 0x08 will return GOOD status. Apply: The test sends a MODE SENSE command for the caching mode page. Expect: The value of ScsiStatus should be 0x0.

5.3 MODE SENSE (10) Checking Parameters Savable (PS bit).
Test Assertion GUID: 6bfd1761-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Optional: The TD-28.25 SCSI Compliance test checks if the PS bit for the caching mode page is one. Apply: The test sends a MODE SENSE command for the caching mode page. Expect: The value of PS should be 1.

5.4 MODE SENSE (10) Checking Mode Parameter Header.
Test Assertion GUID: 6bfd1762-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test verifies that MediumType == 0x0 and BlockDescriptorLength == 0x0. Apply: The test sends a MODE SENSE command for the caching mode page. Expect: The value of MediumType should be 0x0 and the value of BlockDescriptorLength should be 0x0.

5.5 MODE SENSE (10) Checking Caching Mode Page Length.
Test Assertion GUID: 6bfd1763-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the caching mode page is 20 bytes. Apply: The test sends a MODE SENSE command for the caching mode page. Expect: The value of cachePageLength should be 20 bytes.

5.6 MODE SENSE (10) Getting Current Values.
Test Assertion GUID: 6bfd1764-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test saves the current values for the caching mode page. Apply: The test sends a MODE SENSE command on the caching mode page with PC == 00b. Expect: The value of ScsiStatus should be 0x0.

5.7 MODE SENSE (10) Getting Changeable values.
Test Assertion GUID: 6bfd1765-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test saves the changeable values for the caching mode page. Apply: The test sends a MODE SENSE command on the caching mode page with PC == 01b. Expect: The value of ScsiStatus should be 0x0.

5.8 MODE SENSE (10) Getting Default values.
Test Assertion GUID: 6bfd1766-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test saves the default values for the caching mode page. Apply: The test sends a MODE SENSE command on the caching mode page with PC == 10b. Expect: The value of ScsiStatus should be 0x0.

5.9 MODE SENSE (10) Getting Saved values.
Test Assertion GUID: 6bfd1767-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: [Deleted]

5.10 MODE SELECT (10) Changing WCE.
Test Assertion GUID: 6bfd1768-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test applies a MODE SELECT command on all reported changeable values for the device. Apply: The test sends a MODE SELECT command with changeable caching mode page values set to one. Expect: The value of ScsiStatus should be 0x0.

5.11 MODE SENSE (10) Checking that WCE has been cleared.
Test Assertion GUID: 6bfd1769-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the previous MODE SELECT command actually changed the current mode parameters. Apply: The test sends a MODE SENSE command on the caching mode page. Expect: The current values should have changed.

5.12 MODE SENSE (10) Checking that Saved Values have changed." )
Test Assertion GUID: 6bfd176a-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the previous MODE SELECT command actually changed the saved mode parameters. Apply: The test sends a MODE SENSE commands on the caching mode page with PS == 11b. Expect: The saved values should have changed.

5.13 MODE SELECT (10) setting WCE.
Test Assertion GUID: 6bfd176b-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test applies a MODE SELECT command to clear all changeable values for the device. Apply: The test sends a MODE SELECT command with the changeable caching mode page values set to zero. Expect: The value of ScsiStatus should be 0x0.

5.14 MODE SENSE (10) Checking that WCE has been set.
Test Assertion GUID: 6bfd176c-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the previous MODE SELECT command actually cleared the current mode parameters. Apply: The test sends a MODE SENSE command on the caching mode page. Expect: The current values should have been cleared.

5.15 MODE SELECT (10) Changing non-changeable parameters.
Test Assertion GUID: 6bfd176d-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: [Deleted]

5.16 MODE SELECT (10) Attempting to restore original values.
Test Assertion GUID: 6bfd176e-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that a MODE SELECT command can return the caching mode page values to their default values. Apply: The test sends a MODE SELECT command with values set to their defaults. Expect: The value of ScsiStatus should be 0x0.

5.17 MODE SENSE (10) Verifying values were restored.
Test Assertion GUID: 6bfd176f-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the default values were restored in the caching mode page. Apply: The test sends a MODE SENSE command on the caching mode page. Expect: The current values should equal the default values.

6.1 READ (6) Basic Verification Test
Test Assertion GUID: 6bfd1770-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the command correctly reads the first two blocks of data. Info: The test sends two READ commands that read two different but overlapped blocks of data. Next, it compares the overlapped data and returns true if the overlapped data is the same between the read operations (implying that the two commands read the same data correctly). Apply: The test sends a READ (6) command (0x8) to read the first two blocks of data. Expect: The value of ScsiStatus should be 0x0.

6.2 READ (6) Sequential Read Test
Test Assertion GUID: 6bfd1771-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the command correctly reads 1000 sequential blocks of data. The test sends the READ (6) command 1000 times, reading data sequentially starting at a random logical block address. Apply: The test sends a READ (6) command (0x8) 1000 times. Expect: All sequential READ (6) commands should succeed.

6.3 READ (6) Random Read Test
Test Assertion GUID: 6bfd1772-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the READ (6) command correctly read 1000 random blocks of data. The test sends the command 1000 times, reading data at random logical block addresses. Apply: The test sends a READ (6) command (0x8) 1000 times. Expect: All random READ (6) commands should succeed.

6.4 READ (6) Read-With-Disk-Cache-Cleared Test
Test Assertion GUID: 6bfd1773-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the command correctly reads 12 MB of data with disk cache cleared. Apply: The test first reads 12 MB of sequential data and then stores the data for later verification. Next, the test clears the disk cache by reading 12 MB of random data. Finally, the test reads the same 12 MB of sequential data and compares the checksum of the data by the READ commands to see if the data is identical to the data that it first read. Expect: The 12 MB of data that is read after the cache is cleared should be correct.

7.1 READ (10) Basic Functionality Test
Test Assertion GUID: 6bfd1774-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the command correctly reads the first two blocks of data. The test sends two READ commands that read two different but overlapped blocks of data. Next, the test compares the overlapped data and returns true if the overlapped data is the same between the read operations (implying that the two commands read the same data correctly). Apply: The test sends a simple READ (10) command (0x28) to the device. Expect: The value of ScsiStatus should be 0x0.

7.2 READ (10) Sequential Read Test
Test Assertion GUID: 6bfd1775-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the command correctly reads 1000 sequential blocks of data. Info: The test sends the command 1000 times, reading data sequentially starting at a random logical block address. Apply: The test sends a READ (10) command (0x28) 1000 times... Expect: All sequential READ (10) commands should succeed.

7.3 READ (10) Random Read Test
Test Assertion GUID: 6bfd1776-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the command correctly reads 1000 random blocks of data. Info: The test sends the command 1000 times, reading data at random logical block addresses. Apply: The test sends a READ (10) command (0x28) 1000 times. Expect: All random READ (10) commands should succeed.

7.4 READ (10) Read-With-Disk-Cache-Cleared Test
Test Assertion GUID: 6bfd1777-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the command correctly reads 12 MB of data with the disk cache cleared. Apply: The test first reads 12 MB of sequential data and stores the data for later verification. Next, the test clears the disk cache by reading 12 MB of random data. Finally, the test reads the same 12 MB of sequential data and compares the checksum of data by the READ commands to see if the data is same as the one in the first read operation. Expect: The 12 MB of data that are read after the cache is cleared should be correct.

8.1 READ (16) Support Test
Test Assertion GUID: 6bfd1778-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Optional: The TD-28.25 SCSI Compliance test verifies that the device supports the READ (16) command. If not supported, all further tests are halted. Expect: The value of ScsiStatus should be 0x0.

8.2 READ (16) Basic Functionality Test
Test Assertion GUID: 6bfd1779-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the READ command correctly reads the first two blocks of data. Info: The test sends two READ commands to read two different but overlapped blocks of data. Next, the test compares the overlapped data and returns true if the overlapped data is the same between the read operations (implying that the two commands read the same data correctly). Apply: The test sends a simple READ (16) command (0x88) to the device. Expect: The value of ScsiStatus should be 0x0.

8.3 READ (16) Sequential Read Test
Test Assertion GUID: 6bfd177a-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the READ (16) command correctly reads 1000 sequential blocks of data. Apply: The test sends a READ (16) command (0x88) 1000 times, reading data sequentially starting at a random logical block address. Expect: All sequential READ (16) commands should succeed.

8.4 READ (16) Random Read Test
Test Assertion GUID: 6bfd177b-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the READ (16) command correctly reads 1000 random blocks of data. Apply: The test sends a READ (16) command (0x88) 1000 times, reading data at random logical block address. Expect: All random READ (16) commands should succeed.

8.5 READ (16) Read-With-Disk-Cache-Cleared Test
Test Assertion GUID: 6bfd177c-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The READ command must read 12 MB of data correctly with the disk cache cleared. Apply: The test first reads 12 MB of sequential data and stores the data for later verification. Next, the test clears the disk cache by reading 12 MB of random data. Finally, the test reads the same 12 MB of sequential data and compares the checksum of data by the READ commands to see if the data is same as the one it first read. Expect: The 12 MB of data that are read after the cache is cleared should be correct.

9.1 READ CAPACITY (10) Basic Verification Test
Test Assertion GUID: 6bfd177d-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the READ CAPACITY (10) command returns correct disk capacity information. Info: The test sends the command to request for the number of logical block addresses and block length of the disk. Apply: The test sends a READ CAPACITY (10) command (0x25) to the device to request the number of logical block addresses and block length of the disk. Expect: The value of ScsiStatus should be 0x0.

9.2 READ CAPACITY (10) PMI Test
Test Assertion GUID: 6bfd177e-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

9.3 READ CAPACITY (10) Negative Test
Test Assertion GUID: 6bfd177f-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

10.1 REQUEST SENSE (6) Support Test
Test Assertion GUID: 6bfd1780-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks if the REQUEST SENSE command is supported and returns a GOOD status. Apply: The test sends a REQUEST SENSE (0x03) command to the disk device. Expect: The value of ScsiStatus should be 0x0. Response: ScsiStatus is 0x0.

10.2 REQUEST SENSE (6) RESPONSE CODE Test
Test Assertion GUID: 6bfd1781-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test verifies that the RESPONSE CODE value is either 0x70 or 0x71. Apply: The test checks the RESPONSE CODE value in the sense buffer. Expect: The value of RESPONSE CODE should be 0x70 or 0x71. Response: RESPONSE CODE == 0x70.

10.3 REQUEST SENSE (6) Sense Data Length Test
Test Assertion GUID: 6bfd1782-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test verifies that the length of the sense data is correct. Apply: The test checks additional sense length to ensure that it is correct. Expect: The value of the additional sense length should be the sense data size minus eight. Response: Additional Sense Length == 10.

11.1 WRITE (6) Basic Functionality Test
Test Assertion GUID: 6bfd1783-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the command correctly writes one block of data to the device. Apply: The test verifies the WRITE command by comparing the data that is written and the data that is returned by the READ command after the write operation. If the data is the same, the WRITE command is writing the correct data on the disk. Expect: The value of ScsiStatus should be 0x0.

11.2 WRITE (6) Sequential Write Test
Test Assertion GUID: 6bfd1784-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the WRITE (6) command correctly writes 1000 sequential blocks of data. Apply: The test sends a WRITE (6) command (0xA) 1000 times, writing data sequentially starting at a random logical block address. Expect: All sequential WRITE (6) commands should succeed.

11.3 WRITE (6) Random Write Test
Test Assertion GUID: 6bfd1785-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the WRITE (6) command correctly writes 1000 random blocks of data. Apply: The test sends a WRITE (6) command (0xA) 1000 times, writing data at random logical block address. Expect: All random WRITE (6) commands should succeed.

11.4 WRITE (6) Write-With-Disk-Cache-Enabled Test
Test Assertion GUID: 6bfd1786-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the WRITE (6) commandcorrectly writes 12 MB of data with cache enabled. Apply: With write cache enabled, the test writes 12 MB of data to the disk for later verification. Next, the test sends a SYNCHRONIZE CACHE (10) (0x35) command to synchronize the logical block address in cache with the ones in disk. Finally, the test reads the same 12 MB of data that the WRITE command wrote to verify that the data is correct. Expect: The 12 MB of data should be written correctly.

11.5 WRITE (6) Write-With-Disk-Cache-Disabled Test
Test Assertion GUID: 6bfd1787-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the WRITE (6) command correctly writes 12 MB of data with cache disabled. Apply: With write cache disabled, the test writes 12 MB of data to the disk for later verification. Next, the test reads the same 12 MB of data that the WRITE command wrote to verify that the data is correct. Expect: The 12 MB data should be written correctly.

12.1 WRITE (10) Basic Functionality Test
Test Assertion GUID: 6bfd1788-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the WRITE (10) command correctly writes one block of data to the device. Apply: The test verifies the WRITE command by comparing the data to be written and the data returned by the READ comand after the write operation. If the data is the same, the WRITE command wrote the correct data to the disk. Expect: The value of ScsiStatus should be 0x0.

12.2 WRITE (10) Sequential Write Test
Test Assertion GUID: 6bfd1789-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the WRITE (10) command correctly writes 1000 sequential blocks of data. Apply: The test sends a WRITE (10) command (0x2A) 1000 times, writing data sequentially starting at a random logical block address. Expect: All sequential WRITE (10) commands should succeed.

12.3 WRITE (10) Random Write Test
Test Assertion GUID: 6bfd178a-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the WRITE (10) command correctly writes 1000 random blocks of data. Apply: The test sends a WRITE (10) command (0x2A) 1000 times, writing data at a random logical block address. Expect: All random WRITE (10) commands should succeed.

12.4 WRITE (10) Write-With-Disk-Cache-Enabled Test
Test Assertion GUID: 6bfd178b-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the WRITE (10) command correctly writes 12 MB of data with disk cache enabled. Apply: With write cache enabled, the test writes 12 MB of data to disk for later verification. Next, the test sends a SYNCHRONIZE CACHE (10) (0x35) command to synchronize the logical block address in cache with the ones on the disk. Finally, the test reads the same 12 MB of data that the WRITE command wrote to verify that the data is correct. Expect: The 12 MB of data should be written correctly.

12.5 WRITE (10) Write-With-Disk-Cache-Disabled Test
Test Assertion GUID: 6bfd178c-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the WRITE (10) command correctly writes 12 MB of data with the cache disabled. Apply: With write cache disable, the test writes 12 MB of data to disk for later verification. Next, the test reads the same 12 MB of data that the WRITE command wrote to verify that the data is correct. Expect: The 12 MB of data should be written correctly.

12.6 WRITE (10) FUA Test
Test Assertion GUID: 6bfd178d-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the WRITE (10) command correctly writes data with cache enabled and FUA (Force Unit Access) on. Apply: With write cache enabled, the test writes 12 MB of data sequentially to the disk. Next, the test sends a SYNCHRONIZE CACHE (10) (0x35) command. Finally, the test reads 12MB of data sequentially from the disk. Expect: The data should be written correctly to disk with FUA on.

13.1 WRITE (16) Support Test
Test Assertion GUID: 6bfd178e-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Optional: The TD-28.25 SCSI Compliance test verifies that the device supports the command. If not supported, all further tests are halted. Expect: The value of ScsiStatus should be 0x0.

13.2 WRITE (16) Basic Functionality Test
Test Assertion GUID: 6bfd178f-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the WRITE (16) command correctly writes one block of data to the device. Apply: The test verifies the WRITE command by comparing the data to be written and the data returned by the READ command after the write operation. If the data is the same, the WRITE command wrote the correct data on disk. Expect: The value of ScsiStatus should be 0x0.

13.3 WRITE (16) Sequential Write Test
Test Assertion GUID: 6bfd1790-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the WRITE (16) command correctly writes 1000 sequential blocks of data. Apply: The test sends a WRITE (16) command (0x8A) 1000 times writing data sequentially starting at a random logical block address. Expect: All sequential WRITE (16) commands should succeed.

13.4 WRITE (16) Random Write Test
Test Assertion GUID: 6bfd1791-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the WRITE (16) command correctly writes 1000 random blocks of data. Apply: The test sends a WRITE (16) command (0x8A) 1000 times, writing data at a random logical block address. Expect: All random WRITE (16) commands should succeed.

13.5 WRITE (16) Write-With-Disk-Cache-Enabled Test
Test Assertion GUID: 6bfd1792-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the WRITE (16) command correctly writes 12 MB of data with cache enabled. Apply: With write cache enabled, the test writes 12 MB of data to disk for later verification. Next, the test sends a SYNCHRONIZE CACHE (10) (0x35) command to synchronize the logical block address in cache with the ones in disk. Finally, the test reads the same 12 MB of data that the WRITE command wrote to verify that the data is correct. Expect: The 12 MB of data should be written correctly.

13.6 WRITE (16) Write-With-Disk-Cache-Disabled Test
Test Assertion GUID: 6bfd1793-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the WRITE (16) command correctly writes 12 MB of data with cache disabled. Apply: With write cache disabled, the test writes 12 MB of data to disk for later verification. Next, the test reads the same 12 MB of data that the WRITE command wrote to verify that the data is correct. Expect: The 12 MB of data should be written correctly.

14.1 RESERVE (6) Support Test
Test Assertion GUID: 6bfd1794-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks if the RESERVE command is supported and returns GOOD status. Apply: The test sends a RESERVE (0x16) command to the disk device. Expect: The value of ScsiStatus should be 0x0.

15.1 Multi-Initiator Reserve Test By First Initiator
Test Assertion GUID: 6bfd1795-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test sends a RESERVE (6 byte) command to the logical unit that uses the first initiator. The test expects the device to return status of good. Apply: The first initiator sends the RESERVE (6) command to reserve a device that has not been reserved by any initiator. Expect: The RESERVE (6) command should return successfully.

15.1 RESERVE (10) Support Test
Test Assertion GUID: 6bfd1796-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test sends a RESERVE (6 byte) command to the logical unit that uses the first initiator. The test expects the device to return status of good. Apply: The first initiator sends the RESERVE (6) command to reserve a device that has not been reserved by any initiator. Expect: The RESERVE (6) command should return successfully.

15.2 Multi-Initiator Reserve
Test Assertion GUID: 6bfd1797-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks whether a second initiator receives RESERVATION CONFLICT when attempting to send RESERVE or RELEASE commands to the device that was reserved by the first initiator. Apply: The second initiator sends a RESERVE command to the device that has been reserved by the first initiator. Expect: The second initiator should receive RESERVATION CONFLICT (0x18).

15.3 Multi-Initiator Release Test By First Initiator
Test Assertion GUID: 6bfd1798-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks if the device allows the first initiator to release the reservation on it. Apply: The first initiator sends the RELEASE (6) command to release a device that it has previously been reserved. Expect: The device should return GOOD status.

15.4 Multi-Initiator Reserve Test By Second Initiator
Test Assertion GUID: 6bfd1799-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks if the device allows a second initiator to reserve the device if there are no other reservations. Apply: The second initiator sends a RESERVE (6) command (0x16) to reserve a device that has not been reserved by any initiator. Expect: The RESERVE (6) command should return successfully.

15.5 Multi-Initiator Reserve
Test Assertion GUID: 6bfd179a-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the first initiator receives RESERVATION CONFLICT when attempting to send a RESERVE or RELEASE command to the device that is reserved by a second initiator. Apply: The first initiator sends a RESERVE (6) command (0x16). Expect: The status of the RESERVE command should be 0x18.

15.6 Multi-Initiator Release Test By Second Initiator
Test Assertion GUID: 6bfd179b-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the second initiator sends the RELEASE command successfully to a device that it has reserved previously. Apply: The second initiator attempts to release the device by sending a RELEASE (6) command (0x17). Expect: The second initiator should release the device successfully.

15.7 Multi-Initiator Miscellaneous Command Test
Test Assertion GUID: 6bfd179c-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the device supports INQUIRY commands from one initiator when it is reserved by another initiator. Apply: The second initiator sends SCSI commands other than RESERVE and RELEASE to the device that has been reserved by the first initiator. Expect: All commands but INQUIRY should return RESERVATION CONFLICT.

15.8 Multi-Initiator
Test Assertion GUID: 6bfd179d-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the second initiator can reserve and release a device after sending the IOCTL_STORAGE_BREAK_RESERVATION command to break the reservation of the device by the first initiator. Expect: The second initiator should be able to break the reservation of the device by the first initiator.

15.9 Multi-Initiator Post
Test Assertion GUID: 6bfd179e-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks that the second initiator can reserve and release a device after sending the IOCTL_STORAGE_BREAK_RESERVATION command to break the reservation of the device by the first initiator. Expect: The second initiator should be able to reserve and release a device after the device executes IOCTL_STORAGE_BREAK_RESERVATION.

16.1 RELEASE (6) Support Test
Test Assertion GUID: 6bfd179f-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The TD-28.25 SCSI Compliance test checks if the RELEASE command is supported and returns GOOD status. Apply: The test sends a RELEASE (0x17) command to the disk device. Expect: The value of SCSI Status should be 0x0.

17.1 RELEASE (10) Support Test
Test Assertion GUID: 6bfd17a0-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

18.1 REPORT LUNS Basic Verification Test
Test Assertion GUID: 6bfd17a1-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

18.2 REPORT LUNS Basic Verification Test
Test Assertion GUID: 6bfd17a2-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

18.3 REPORT LUNS Test for correct format.
Test Assertion GUID: 6bfd17a3-c6a7-11da-94f5-00123f3a6b601

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:


Storage Device Stress test (SDStress)

Type: Automated Test

Overview

This test stresses the hard disk drives and CD-ROM drives in a system and validates storage API commands.

Details

The SDStress test verifies that:
  • The drive functions properly in Device 0, Device 1, and cable-select configurations.
  • The device driver for partitioned media supports all Microsoft Windows partition types (STOR-0365)
  • The removable media drives function properly with designated controllers.
When SDStress test is started using DTM, the test will stress the drives that are associated with the drive letters passed to the test.

When using DTM to run SDStress, you can specify the driver letters by setting the parameter StorageDriveLetters to a list of letters of the drives that need to be stress-tested. NOTE: Do NOT leave spaces in between multiple drive letters. For example if drives C, D, and E need to be stressed using SDStress, set the parameter StorageDriveLetters to CDE. When stressing an optical drive, the test uses an additional parameter: StorageWritableTarget. This is any writable volume on the system. This parameter should be NULL when not testing an optical drive. When running this job from Device console, this parameter should be populated automatically. You can verify the parameters by right clicking the job in job monitor, choosing view result report, and checking the section marked effective parameters.

There is also the SDStressOptions parameter that gives the user the flexibility to choose from a list of options when running SDStress. This parameters takes a list of arguments. In this case, make sure to leave spaces in between the arguments.

The arguments that can be used for SDStressOptions parameter are:

/B:n Specify block size (multiples of 512 bytes, maximum 128 KB).

/BPCONCORRUPTION Enter debugger using DebugBreak on data corruption.

/C:n Specify the CD thread multiplier.

/DEBUG Debug into the debugger when error occurs.

/D:n Specify the disk thread multiplier.

/P:n Specify the number of passes per thread.

/R Randomize block size.

/T:n Test file size (in megabytes).

/WT Perform I/O operations using cache write through.

/Z1 Perform first test scenario (CopyTestFile).

/Z2 Perform second test scenario (CopyTestFileUsingIoC).

/Z3 Perform third test scenario (CopyTestFileMultiple).

/ZA Perform all test scenarios.

By default the parameter [SDStressOptions] is set to: /P:5 /C:5 /D:2 /ZA /R

Run Time: Up to 12 hours
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running Storage Device Stress test (SDStress)

  • Ensure your machine pool has been configured for the proper logo program.
  • Create a submission (Logo) or select device mode in device console.
  • Run SDStress DTM Job from device console.

Command Syntax

Command option | Description
SDStress /S:[StorageWritableTarget][StorageDriveLetters] /P:5 /C:5 /D:2 /ZA /R | See the Full Description and Theory of Operation section for details.

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location
SDStress.exe | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk\

Click to show or hide information. Test Assertions

Test Assertions

Device should not cause timeout.
Test Assertion GUID: 69ff82c9-c8f4-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device should handle IOCTL_STORAGE_CHECK_VERIFY.
Test Assertion GUID: 69ff82ca-c8f4-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device should support GetDiskFreeSpaceEx and have more than 10 MB free.
Test Assertion GUID: 69ff82cb-c8f4-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Drive must be of known type, determined by GetDriveType.
Test Assertion GUID: 69ff82ce-c8f4-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device should perform under stress.
Test Assertion GUID: 69ff82cf-c8f4-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:


HBA API Test

Type: Automated Test

Overview

The HBA API Compliance test verifies the Windows Management Instrumentation (WMI) interfaces that are implemented by a host bus adapter (HBA) driver for support of the Storage Networking Industry Association's Common HBA API. To qualify for the “Designed for Windows” logo, Fibre Channel and SAS Storport miniport drivers and SCSI miniport drivers must support the HBA API.

Details

The test uses a Visual Basic Script to query the HBAs WMI interfaces. See test Assertion section for specific test cases. You may view the source of the test by opening the VBS with a text editor.
Run Time: 5 minutes
Log File: HbaApiTest.wtl, HbaApiTest.log.txt
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running HBA API Test

The test first installs the schema for the HBA API on the machine, and then launches the script.

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location
hbaapi.vbs | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk
hbaapi.bmf | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk

Click to show or hide information. Test Assertions

Test Assertions

0 HBA miniport must support HBA API WMI interfaces.
Test Assertion GUID: c0bcadba-c401-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

1 The provider must provide one instance of MSFC_FibrePortHBAStatistics per local port.
Test Assertion GUID: c0bcadbb-c401-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

2 The provider must provide one instance of MSFC_FibrePortHBAAttributes per local port with the appropriate subfields filled in.
Test Assertion GUID: c0bcadbc-c401-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

3 The provider must provide one instance of MSFC_FCAdapterHBAAttributes per adapter with the appropriate subfields filled in.
Test Assertion GUID: c0bcadbd-c401-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4 The provider must provide one instance of MSFC_HBAAdapterMethods per adapter.
Test Assertion GUID: c0bcadbe-c401-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4.1 The provider must implement one instance of ResetStatistics per local port under the class MSFC_FibrePortHBAMethods.
Test Assertion GUID: c0bcadbf-c401-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4.2 The provider must provide one instance of MSFC_HBAAdapterMethods per adapter.
Test Assertion GUID: c0bcadc0-c401-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4.3 The provider must provide one instance of MSFC_HBAFCPInfo per adapter.
Test Assertion GUID: c0bcadc1-c401-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4.4 The provider must provide one instance of MSFC_EventControl per adapter.
Test Assertion GUID: c0bcadc2-c401-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4.2.1 The method RefreshInformation must be implemented.
Test Assertion GUID: c0bcadc3-c401-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4.2.2 The methods GetDiscoveredPortAttributes and GetPortAttributesByWWN must be implemented.
Test Assertion GUID: c0bcadc4-c401-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Calling GetDiscoveredPortAttributes with port and discoverd index zero should return success. The returned port attribute fields NodeWWN, PortWWN, and PortFcId must be valid. The NumberOfDiscoveredPorts field must be zero. Calling GetPortAttributesByWWN with above port should match attributes returned above.

4.2.3 The method SendCTPassThru must be implemented.
Test Assertion GUID: c0bcadc5-c401-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4.2.4 The method ScsiReadCapacity must be implemented.
Test Assertion GUID: c0bcadc6-c401-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4.2.5 Calling SendRNID with WWN of all zeros return invalid WWN.
Test Assertion GUID: c0bcadc7-c401-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4.2.6 Calling SendRPL with WWN and PortWWN from 4.2.2 returns success.
Test Assertion GUID: c0bcadc8-c401-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4.2.7 Calling GetFC4Statistics with local PortWWN for this instance the fc4Type of 8 (SCSI disk) returns success.
Test Assertion GUID: c0bcadc9-c401-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4.2.8 The methods Get/SetFC3MgmtInfo must be implemented.
Test Assertion GUID: c0bcadca-c401-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4.2.9 The method GetEventBuffer must be implemented.
Test Assertion GUID: c0bcadcb-c401-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4.3.1 Calling GetFcpTargetMapping with port zero should return success or more data with out count of zero and total of zero on success or greater than or equal to one on more data.
Test Assertion GUID: c0bcadcc-c401-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4.3.2 Calling GetFcpTargetMapping with port one should return success or more data with out count of zero or one and total of zero or one on success or greater than or equal to two on more data.
Test Assertion GUID: c0bcadcd-c401-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4.3.3 Calling GetFcpTargetMapping with port one should return success with out count, total count, and in count all matching.
Test Assertion GUID: c0bcadce-c401-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4.3.4 Calling GetBindingCapability should return a success or not supported.
Test Assertion GUID: c0bcadcf-c401-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4.3.5 Calling GetBindingSupport should return a success or not supported. On success the Supported flags returned must be a subset of the Capabilities flags returned in Test 4.3.4.
Test Assertion GUID: c0bcadd0-c401-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4.3.6 Calling SetBindingSupport should return a success or not supported.
Test Assertion GUID: c0bcadd1-c401-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4.3.7 Calling GetFcpPersistentBinding should return success or more data.
Test Assertion GUID: c0bcadd2-c401-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4.3.8 Calling GetFcpPersistentBinding2 should return success or more data.
Test Assertion GUID: c0bcadd3-c401-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4.4.1 Calling Add Target should return a success or not supported.
Test Assertion GUID: c0bcadd4-c401-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4.4.2 Calling Remove Target should return a success or not supported.
Test Assertion GUID: c0bcadd5-c401-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4.4.3 Calling Add Port should return a success or not supported.
Test Assertion GUID: c0bcadd6-c401-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4.4.4 Calling Remove Port should return a success or not supported.
Test Assertion GUID: c0bcadd7-c401-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4.4.5 Calling Add Link should return a success or not supported.
Test Assertion GUID: 5e0f2d44-c412-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4.4.6 Calling Remove Link should return a success or not supported.
Test Assertion GUID: 5e0f2d45-c412-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:


SCSI Initiator Client Server

Type: Automated Test

Overview

This test verifies the functionality necessary for Microsoft Cluster Server (MSCS) to change and maintain ownership of the RAID storage disks in the cluster client node. It also verifies the functionality

necessary for multi-initiator host bus adapter (HBA) implementations.

Details

The test uses a client/server setup. The test requires one client and n server nodes, where n is a number between two and eight inclusively. The test tool can be run as either client or server using a command line switch. When a client node is running, a server node is automatically started on the same machine, so the actual number of physical machines used is n.
Client:
The client instance of the test will issue SCSI reserve/release, read/write to each of the server nodes and verify the correctness of SCSI challenge/defense mechanism.
Server:
The server instance of the test will handle SCSI reserve/release, read/write accordingly.
Test steps:
The test first determines the number of machines in the target machine pool and arbitrarily chooses one machine to be the client. The test then launches the an instance of the server on every machine and the client the machine chosen before.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Windows 2000
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • N-1 other machines that meet the above requirements.

Running SCSI Initiator Client Server

  • Create a machine pool with N clients. All clients should share the same storage.
  • Schedule the "SCSI Initiator Client Server" job on this machine pool.

Command Syntax

Command option | Description
nnodesim /c:n | Run on one of the N machines
nnodesim /s:client_machine_name | Run on all N machines

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location
nnodesim.exe | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk
countlms.vbs | [WTT\TestBinRoot]\nttest\driverstest\storage\wdk

Click to show or hide information. Test Assertions

Test Assertions

Server must be able to read MBR of storage device.
Test Assertion GUID: 1b088e43-c8d3-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Content will be published

Server must be able to perform a random read / write on the storage device.
Test Assertion GUID: 1b088e44-c8d3-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Server must be able to perform a sequential read / write on the storage device.
Test Assertion GUID: 1b088e45-c8d3-11da-94f5-00123f3a6b60

Server must be able to write MBR of storage device.
Test Assertion GUID: 1b088e46-c8d3-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Server must be able to reserve the storage device.
Test Assertion GUID: 1b088e47-c8d3-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

A bus reset of the storage device should release any reservations on the storage device.
Test Assertion GUID: 1b088e48-c8d3-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

A server may only realease a reservation that it currently holds.
Test Assertion GUID: 1b088e49-c8d3-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:


Medium Changer Test

Type: Automated Test

Overview

This test verifies that a media changer meets performance standards by passing various packet commands to the media changer.

Details

This test accepts a medium changer device number as input. This is provided by DTM automatically when the test is launched from device console.

Run Time: 72 hours
Log File: mctest.log
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Media and cleaning cartridge.

Running Medium Changer Test

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location
mctest.exe | …\Tests\%PROCESSOR_ARCHITECTURE%\nttest\DriversTest\storage\wdk\

Click to show or hide information. Test Assertions

Test Assertions

Scenario 0 Changer must pass the DoorLockUnlock scenario.
Test Assertion GUID: 960499ef-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Scenario 1 Changer must pass the KeypadEnableDisable scenario.
Test Assertion GUID: 960499f0-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Scenario 2 Changer must pass the IEPortExtendRetract scenario.
Test Assertion GUID: 960499f1-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Scenario 3 Changer must pass the PositionTransport scenario.
Test Assertion GUID: 960499f2-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Scenario 4 Changer must pass the HomeUnit scenario.
Test Assertion GUID: 960499f3-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Scenario 5 Changer must pass the LoadUnloadMedium scenario.
Test Assertion GUID: 960499f4-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Scenario 6 Changer must pass the InitializeElementStatus scenario.
Test Assertion GUID: 960499f5-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Scenario 7 Changer must pass the MoveMedium scenario.
Test Assertion GUID: 960499f6-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Scenario 8 Changer must pass the NegativeMoveMedium scenario.
Test Assertion GUID: 960499f7-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Scenario 9 Changer must pass the FlipMedium scenario.
Test Assertion GUID: 960499f8-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Scenario 10 Changer must pass the ExchangeMedium scenario.
Test Assertion GUID: 960499f9-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Scenario 11 Changer must pass the NegativeExchangeMedium scenario.
Test Assertion GUID: 960499fa-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Scenario 12 Changer must pass the MultipleIEPort scenario.
Test Assertion GUID: 960499fb-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Scenario 13 Changer must pass the VolumeLabel scenario.
Test Assertion GUID: 960499fc-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Scenario 14 Changer must pass the QueryVolumeTags scenario.
Test Assertion GUID: 960499fd-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Scenario 15 Changer must pass the ReadWrite scenario.
Test Assertion GUID: 960499fe-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Scenario 16 Changer must pass the MultiThreadReadWrite scenario.
Test Assertion GUID: 960499ff-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Scenario 17 Changer must pass the MoveDuringReadWrite scenario.
Test Assertion GUID: 96049a00-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Scenario 18 Changer must pass the ExchangeDuringReadWrite scenario.
Test Assertion GUID: 96049a01-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Scenario 19 Changer must pass the FlipDuringReadWrite scenario.
Test Assertion GUID: 96049a02-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Scenario 20 Changer must pass the TransportSameLocation scenario.
Test Assertion GUID: 96049a03-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Scenario 21 Changer must pass the VolumeIDAfterFlip scenario.
Test Assertion GUID: 96049a04-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Scenario 22 Changer must pass the MoveFromSameLocation scenario.
Test Assertion GUID: 96049a05-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Scenario 23 Changer must pass the CheckNonBarcodedMedia scenario.
Test Assertion GUID: 96049a06-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Scenario 24 Changer must pass the AbsentSlot scenario.
Test Assertion GUID: 96049a07-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Scenario 25 Changer must pass the InitializeElementStatusWithMediaInDrive scenario.
Test Assertion GUID: 96049a08-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Scenario 26 Changer must pass the CleanerAccess scenario.
Test Assertion GUID: 96049a09-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Scenario 27 Changer must pass the MultipleChangerMoveMedium scenario.
Test Assertion GUID: 96049a0a-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Scenario 28 Changer must pass the MultipleChangerReadWrite scenario.
Test Assertion GUID: 96049a0b-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Setup Changer must be correctly setup.
Test Assertion GUID: 96049a0c-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Cleanup Changer must perform cleanup operations.
Test Assertion GUID: 96049a0d-c67a-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:


Media Status Notification test

Type: Manual Test

Overview

This is the Media Status Notification specification v1.03 test. This test contains two scenarios, one to test the ejectability of a device, the second to test the media status bits.

Details

If the device also supports the Removable Media Feature set, the test will check that the Lock, Unlock, and Eject behave correctly with MSN enabled.
The test checks the media status bits. It checks the response to GetMediaStatus when MSN is disabled, and checks each that each bit is activated correctly with MSN enabled.
Run Time: 20 min
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Removable drive with eject option

Running Media Status Notification test

Command Syntax

Command option | Description
MEDIASN.EXE <drive> |

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location
mediasn.exe | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk

Click to show or hide information. Test Assertions

Test Assertions

Device must expose a drive letter and permit the test to open a handle to the drive.
Test Assertion GUID: 0ad01f0c-c51a-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device must support ATA or ATAPI Identify, and set the Media Status Notification bits (word 127[1:0] = 0b01)
Test Assertion GUID: 0ad01f0d-c51a-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

If the Removable Media feature set is supported, it must not interfere with Media Status Notification.
Test Assertion GUID: 0ad01f0e-c51a-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device must support enabling of MSN (95h) and report this in the IDENTIFY DEVICE response. (word 86[4] = 1)
Test Assertion GUID: 0ad01f0f-c51a-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device must support disabling of MSN (31h) and report this in the IDENTIFY DEVICE response. (word 86[4] = 0)
Test Assertion GUID: 0ad01f10-c51a-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

If the Removable Media feature set is implemented the device should support the Media Lock command.
Test Assertion GUID: 0ad01f11-c51a-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

If the Removable Media feature set is implemented the device should support the Media Eject command, regardless of locked/unlocked state.
Test Assertion GUID: 0ad01f12-c51a-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

The following ATA commands must return the no media bit when media is ejected: Unlock, Eject, Read Verify Sector, Lock, Read Sector, and Write Sector.
Test Assertion GUID: 0ad01f13-c51a-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

If the Removable Media feature set is implemented the device should support the Media Unlock command.
Test Assertion GUID: 0ad01f14-c51a-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

User must insert media when prompted and media must become available within 7.5 seconds after user clicks ok.
Test Assertion GUID: 0ad01f15-c51a-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Media must remain available after user presses eject button.
Test Assertion GUID: 0ad01f16-c51a-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device must suppourt Get Media Status command.
Test Assertion GUID: 0ad01f17-c51a-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Get Media Status should return 0 for WP, MC, MCR and NM when MSN is disabled.
Test Assertion GUID: 0ad01f18-c51a-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Media Change Request bit should be asserted when eject button is pressed.
Test Assertion GUID: 0ad01f19-c51a-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

No media bit should be asserted when media is not present.
Test Assertion GUID: 0ad01f1a-c51a-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Write protect bit should be asserted when write-protected media present.
Test Assertion GUID: 0ad01f1b-c51a-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Media Change bit should be asserted when media is inserted.
Test Assertion GUID: 0ad01f1c-c51a-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Media Change bit should be cleared when Get Media Status is called.
Test Assertion GUID: 0ad01f1d-c51a-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device must properly implement Media Status Notification.
Test Assertion GUID: 0ad01f1e-c51a-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:


iSCSI Oneway CHAP (Target)

Type: Automated Test

Overview

The iSCSI Oneway CHAP (Target) test verifies that the target device (disk, tape, or optical storage device) can use the Challenge Handshake Authentication Protocol (CHAP) authentication mechanism.

Details

The test uses multiple variations to verify that a target properly supports one-way CHAP. The first variation performs a login similar to the user logging in through iSCSI Initiator Control Panel Applet. The rest of the variations perform login outside of the MS initiator using the iSCSI protocol. Each variation receives the challenge from the target and responds to the target's with a calculated response. The target is then expected to either continue with the iSCSI login or return the appropriate status code depending on the response received. The four different variations are as follows:
  • Valid response is returned using Hex Encoding
  • Valid response is returned using Base64 Encoding
  • Invalid response is returned using Hex Encoding
  • Invalid response is returned using Base64 Encoding

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running iSCSI Oneway CHAP (Target)

Run the test as a DTM job
Fill the required data in the configuration UI that pops up when this job is scheduled

Command Syntax

Command option | Description
iscsi_targetchap -oneway -hct |

Cautions

Troubleshooting

  1. Look at the job results log file for test failures
  2. Verify the data entered in the configuration dialog (Popup Dialog box when the job is scheduled from device console)

Reference Documentation

Code Tour

File Manifest

File | Location
iscsi_targetchap.exe | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\iscsi

Click to show or hide information. Test Assertions

Test Assertions

0 Login using CHAP must succeed.
Test Assertion GUID: 5cfdfc45-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

1 The target must only return iSCSI logon response protocol data units (PDUs).
Test Assertion GUID: 5cfdfc1d-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The target can only use logon response PDUs during iSCSI logon. Apply: iSCSI logon request PDUs are sent to the target. Expect: Each PDU received by the test has the opcode field set to 0x23.

2 iSCSI logon response packets must have NULL-terminated data segments.
Test Assertion GUID: 5cfdfc1e-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: Any response PDU returned by the target, with the data segment length greater than 0, must have a NULL terminator in the last valid byte (non-pad byte) of the data segment. Only key = value pairs are allowed in the response PDU, and the last byte must indicate the end of the last key = value pair. Apply: iSCSI logon request PDUs are sent to the target. Expect: Each PDU, received by the target, has the last non-padding byte of the PDU set to 0.

3 The target must return successful status in response to the initial logon request.
Test Assertion GUID: 5cfdfc21-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test checks that the iSCSI target accepts the initial logon request by returning successful status to the initiator. Apply: An initial iSCSI logon PDU is sent with AuthMethod = CHAP. Expect: The returned logon response PDU must have the status code and status detail fields set to 0.

4 The target must remain in the security negotiation phase during CHAP authentication.
Test Assertion GUID: 5cfdfc22-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test checks that an iSCSI target does not request transition out of the security negotiation stage during authentication. Apply: Two iSCSI logon request PDUs are sent to the target as part of the security negotiation stage. Expect: The target’s response to the first two PDUs has the CSG and NSG fields of the response PDU set to 0 and the T (transit) bit set to 0.

5 The response PDU to the first logon request PDU must not have an empty data segment.
Test Assertion GUID: 5cfdfc23-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that the response PDU that is returned in response to the initial logon does not have an empty data segment. Apply: An initial iSCSI logon PDU is sent with AuthMethod = CHAP. Expect: The target’s response PDU Data Segment Length field must not be 0.

6 The initial logon response PDU must contain at least one TargetPortalGroupTag key.
Test Assertion GUID: 5cfdfc30-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test verifies that the initial response PDU returned to the initiator contains at least one TargetPortalGroupTag key. For more information, see section 5.3 of the iSCSI specification. Apply: An initial iSCSI logon PDU is sent with AuthMethod = CHAP. Expect: The target’s response PDU includes a TargetPortalGroupTag key.

7 The target must return only one AuthMethod key in the initial logon response PDU.
Test Assertion GUID: 5cfdfc31-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test verifies that the target returns one AuthMethod key in response to the initial logon request. Apply: An initial iSCSI logon PDU is sent with AuthMethod = CHAP. Expect: The target’s response PDU has one AuthMethod key.

8 The target must return only one value for the AuthMethod key in the initial logon response PDU.
Test Assertion GUID: 5cfdfc32-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test verifies that the target does not return a list of values for the AuthMethod key. Apply: An initial iSCSI logon PDU is sent with AuthMethod = CHAP. Expect: The target’s response PDU AuthMethod key does not contain a comma-delimited value list.

9 The target must accept CHAP when proposed by the initiator.
Test Assertion GUID: 5cfdfc33-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test checks that an iSCSI target accepts a proposal to use CHAP as an authentication method. Apply: An initial iSCSI logon PDU is sent with AuthMethod = CHAP. Expect: The target’s response to the initial logon request returns AuthMethod = CHAP.

10 The target must not return any invalid keys in the initial logon response.
Test Assertion GUID: 5cfdfc24-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test checks that only the AuthMethod and TargetPortalGroupTag keys are returned in the initial logon response. Apply: An initial iSCSI logon PDU is sent with AuthMethod = CHAP. Expect: The target’s response contains only the AuthMethod or TargetPortalGroupTag key.

11 The target must return successful status in response to the initiator CHAP_A proposal.
Test Assertion GUID: 5cfdfc25-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test checks that the iSCSI target accepts the CHAP_A proposal and returns a successful status to the initiator. Apply: The second iSCSI logon PDU that the initiator sends contains the CHAP_A = 5 key. Expect: The returned logon response PDU must have the status code and status detail fields set to zero (0).

12 The response PDU to the second logon request PDU must not have an empty data segment.
Test Assertion GUID: 5cfdfc27-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test verifies that the response PDU, returned in response to the second logon, does not have an empty data segment. Apply: The second iSCSI logon PDU that the initiator sends contains the CHAP_A = 5 key. Expect: The target’s response PDU Data Segment Length field must not be 0.

13 The target must return only one CHAP_A key in the second logon response PDU.
Test Assertion GUID: 5cfdfc34-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test verifies that the target returns one CHAP_A = key in response to the second logon request. Apply: The second iSCSI logon PDU that the initiator sends contains the CHAP_A = 5 key. Expect: The target’s response PDU has one CHAP_A = key.

14 The target must return only one value for the CHAP_A key in the second logon response PDU.
Test Assertion GUID: 5cfdfc35-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test verifies that the target does not return a list of values in the CHAP_A= key. Apply: The second iSCSI logon PDU sent by the initiator contains the CHAP_A = 5 key. Expect: The target’s response PDU CHAP_A does not contain a comma-delimited value list.

15 The CHAP_A key returned in the second logon response must be a valid numeric value.
Test Assertion GUID: 5cfdfc36-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that the value returned in the CHAP_A = key is a properly encoded numeric value. Apply: The second iSCSI logon PDU sent by the initiator contains the CHAP_A = 5 key. Expect: The value of the target’s response PDU CHAP_A key is properly encoded as a numerical value as defined in section 5.1 of the iSCSI specification (For more information, see the IETF IP Storage Working Group Internet Draft: draft-ietf-ips-iscsi-20.txt). The value may be encoded as a decimal or hexadecimal value.

16 The target must accept the MD5 hash algorithm.
Test Assertion GUID: 5cfdfc37-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test checks that an iSCSI target accepts the MD5 algorithm when proposed by the initiator. Apply: The second iSCSI logon PDU sent by the initiator contains the CHAP_A = 5 key. Expect: The target logon response returns the iSCSI logon response PDU with the CHAP_A value equivalent to 5.

17 The target must return only one CHAP_I key in the second logon response PDU.
Test Assertion GUID: 5cfdfc38-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that the target returns one CHAP_I key in response to the second logon request. Apply: The second iSCSI logon PDU sent by the initiator contains the CHAP_A=5 key. Expect: The target’s response PDU has one CHAP_I key.

18 The target must return only one value for the CHAP_I key in the second logon response PDU.
Test Assertion GUID: 5cfdfc39-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that the target does not return a list of values in the CHAP_I= key. Apply: The second iSCSI logon PDU sent by the initiator contains the CHAP_A=5 key. Expect: The target’s response PDU CHAP_I = does not contain a comma-delimited value list.

19 The CHAP_I key returned in the second logon response must be a valid numeric value.
Test Assertion GUID: 5cfdfc3a-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: The target must return a valid numeric value for the CHAP_I key in the second logon response PDU. Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that the value returned in the CHAP_I= key is a properly encoded numeric value. Apply: The second iSCSI logon PDU sent by the initiator contains the CHAP_A=5 key. 4/14/04 crobbins: In theory, should say "by the test" not specific to our initiator. Expect: The value of the target’s response PDU CHAP_I must be properly encoded as a numerical value as defined in section 5.1 of the iSCSI Specification. The value may be encoded as a decimal or hexadecimal value.

20 The value of the CHAP_I key must be less than or equal to 255.
Test Assertion GUID: 5cfdfc3b-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test checks that the CHAP_I key value is only one byte in its unencoded form. Apply: The second iSCSI logon PDU sent by the initiator contains the CHAP_A = 5 key. Expect: The target logon response returns an iSCSI logon response PDU with a CHAP_i value less than or equal to 255 after it is decoded.

21 The target must return only one CHAP_C key in the second logon response PDU.
Test Assertion GUID: 5cfdfc3c-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that the target returns one CHAP_C = key in response to the second logon request. Apply: The second iSCSI logon PDU sent by the initiator contains the CHAP_A = 5 key. Expect: The target’s response PDU has one CHAP_C key.

22 The target must return only one value for the CHAP_C key in the second logon response PDU.
Test Assertion GUID: 5cfdfc3d-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that the target does not return a list of values in the CHAP_C key. Apply: The second iSCSI logon PDU sent by the initiator contains the CHAP_A=5 key. Expect: The target’s response PDU CHAP_C= does not contain a comma-delimited value list.

23 The CHAP_C key returned in the second login response must be a valid binary value.
Test Assertion GUID: 5cfdfc3e-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that the value returned in the CHAP_C = key is a properly encoded binary value. Apply: The second iSCSI logon PDU sent by the initiator contains the CHAP_A=5 key. Expect: The value of the target’s response PDU CHAP_C key must be properly encoded as a binary value as defined in section 5.1 of the iSCSI specification. The value may be encoded as a decimal, hexadecimal , or base 64 constant.

24 The CHAP_C key must not be longer than the maximum allowed length.
Test Assertion GUID: 5cfdfc3f-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test checks that the CHAP_C = key value is not longer than the maximum length allowed. For those values encoded in hexadecimal or base 64 encoding, the maximum byte length is 1024 bytes. For values encoded in decimal encoding, the maximum byte length is 8 bytes. Apply: The second iSCSI logon PDU sent by the initiator contains the CHAP_A = 5 key. Expect: The target logon response returns an iSCSI logon response PDU with a CHAP_i key value that is less than or equal to 255 after it is decoded.

25 The target must not return any invalid keys in the second logon response.
Test Assertion GUID: 5cfdfc28-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test checks that only CHAP_A, CHAP_I, and CHAP_C values are included in the second logon response. Apply: The second iSCSI logon PDU sent by the initiator contains the CHAP_A=5 key. Expect: The target’s response PDU contains only the CHAP_A = 5, a valid CHAP_I and a valid CHAP_C key. Any other included keys are considered an error.

26 The target must return authentication failure status when an invalid response is returned by the initiator.
Test Assertion GUID: 5cfdfc2a-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that a target properly rejects a logon when the initiator returns an invalid response to a CHAP challenge. Apply: The final logon PDU with the CHAP response is sent to the target with an invalid CHAP_R value. Expect: The target must return a logon response packet with its status class set to initiator error and the status detail set to authentication failure.

27 The target must accept a logon request when a valid response is returned by the initiator.
Test Assertion GUID: 5cfdfc29-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that a target properly recognizes when the initiator returns a valid response to a CHAP challenge. Apply: The final logon PDU with the CHAP response is sent to the target with a valid CHAP_R value. Expect: The target must return a logon response packet with its status class and status detail set to 0.

28 The target must indicate that it is ready to transition to the operation negotiation stage after indicating that the logon authentication succeeded.
Test Assertion GUID: 5cfdfc2d-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that a target indicates that it is ready to proceed to the operation negotiation stage after successfully authenticating the initiator. This condition is checked in both one-way and mutual CHAP. Apply: The final logon PDU with the CHAP response is sent to the target and indicates that the initiator wants to transition to the operation negotiation stage. Expect: The target must return a logon response packet with the CSG field set to 0x01 and the T (transit) bit set to 1.

29 The target must not return any key = value pairs in the final response packet when the initiator is not performing mutual CHAP.
Test Assertion GUID: 5cfdfc2b-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test verifies that the final response packet, returned by the initiator during one-way CHAP, does not contain any key=value pairs. Apply: The final logon PDU with the CHAP response is sent to the target with a valid CHAP_R value. Expect: The target must return a logon response packet with no additional data included in the data segment.

30 When the target is performing mutual CHAP, the target must return a logon response packet with a nonzero data segment length.
Test Assertion GUID: 5cfdfc2c-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that the final response packet, returned by the initiator during mutual CHAP, contains key = value pairs in the data segment. Apply: The final logon PDU with the CHAP response is sent to the target with a valid CHAP_R value, a CHAP_I value, and a CHAP_C value. Expect: The target must return a logon response packet with a nonzero data segment length.

31 The target must return only one CHAP_N key in the second logon response PDU.
Test Assertion GUID: 5cfdfc40-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that the target returns one CHAP_N = key in response to the final logon request. Apply: The final logon PDU with the CHAP response is sent to the target with a valid CHAP_R value, a CHAP_I value, and a CHAP_C value. Expect: The target’s response PDU has one CHAP_N = key.

32 The target must return only one CHAP_R key in the second logon response PDU.
Test Assertion GUID: 5cfdfc41-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that the target returns one CHAP_R = key in response to the final logon request. Apply: The final logon PDU with the CHAP response is sent to the target with a valid CHAP_R value, a CHAP_I value, and a CHAP_C value. Expect: The target’s response PDU has one CHAP_R = key.

33 During mutual CHAP, the target must return only one value for the CHAP_R key in the final logon response PDU.
Test Assertion GUID: 5cfdfc42-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that the target does not return a list of values in the CHAP_R = key. Apply: The final iSCSI logon PDU sent by the initiator contains CHAP_I and CHAP_C values that indicate mutual CHAP. Expect: The target’s response PDU CHAP_R = does not contain a comma-delimited value list.

34 The CHAP_R key returned in the final logon response must be a valid large-binary value.
Test Assertion GUID: 5cfdfc43-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that the value returned in the CHAP_R key is a properly encoded binary value. Although the CHAP_R response may be a binary value, for MD5, the required length exceeds the 8-byte limit for decimal-encoded responses. Therefore, the encoding may only be hexadecimal or base 64. Apply: The final iSCSI logon PDU sent by the initiator contains CHAP_I and CHAP_C values that indicate mutual CHAP. Expect: The value of the target’s response PDU CHAP_R must be properly encoded as a large-binary value as defined in section 5.1 of the iSCSI specification. The value can be encoded either as a hexadecimal or base 64constant.

35 The CHAP_R key must be 16 bytes long in its non-encoded form
Test Assertion GUID: 5cfdfc44-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test checks that the CHAP_R key value is equal to 16 bytes, which is the required length for responses returned as part of the MD5 algorithm. Apply: The final iSCSI logon PDU sent by the initiator contains CHAP_I and CHAP_C values that indicate mutual CHAP. Expect: The target logon response returns a iSCSI logon response PDU and the decode CHAP_R response must be 16 bytes long.

36 The target must compute the CHAP response correctly based on the MD5 algorithm.
Test Assertion GUID: 5cfdfc2e-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test checks that the CHAP response, returned by the target, is equivalent to the expected response based on the initiator secret and the CHAP_I and CHAP_C values sent to the target. Apply: The final iSCSI logon PDU sent by the initiator contains CHAP_I and CHAP_C values to indicate mutual CHAP. Expect: The target returns a CHAP_R response key with the correct response value after decoding the CHAP_R key.

37 When performing mutual CHAP, the target must not return any invalid keys in the final logon response.
Test Assertion GUID: 5cfdfc2f-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: This test checks that CHAP_N and CHAP_R are the only values included in the final logon response. Apply: The final iSCSI logon PDU sent by the initiator contains CHAP_I and CHAP_C values that indicate mutual CHAP. Expect: The target’s response contains only the CHAP_N and CHAP_R above keys. Any other keys included are considered an error.

100 A target must allow connections at the IP address and port number specified for the target.
Test Assertion GUID: 5cfdfc1c-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that a TCP connection with the target being tested can be properly established. Apply: The test attempts to connect to the target using TCP/IP. Expect: The connection is properly established.

101 A target that supports logon redirection must include a data segment in the logon packet that redirects the test.
Test Assertion GUID: 5cfdfc1f-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that a logon response PDU with the status class set to 0x01 includes a data segment. Apply: The initial logon PDU is sent to the target device. Expect: If the target needs to redirect the test, it must contain a data segment so that it can specify a new target address.

102 A target that supports logon redirection must include at least one TargetAddress key in the returned data segment.
Test Assertion GUID: 5cfdfc20-c4fe-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (Target) test verifies that a logon response PDU with the status class set to 0x01 includes a TargetAddress key. Apply: The initial logon PDU is sent to the target device. Expect: If the target needs to redirect the test, the returned data segment that indicates redirection contains a TargetAddress key.


Tape I/O Test

Type: Automated Test

Overview

The target component for this test utility is the tape drive and driver. This test writes to and reads from the tape to verify that the tape drive is operating properly.

Details

This utility will query the tape drive for supported operating parameters and cycle through a subset of supported block modes in fixed and variable modes. Additionally, it will also attempt to enable compression and other features as reported by the drive.
Run Time: 1 hour
Log File: tapeapi.log.xml
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Tape media

Running Tape I/O Test

This test requires a system with at least one tape drive (device under test). The test requires writable media in the tape drive, which will be overwritten.

Command Syntax

Command option | Description
dtape.exe /test /tape \\.\tape# | Standard single partition variation
dtape.exe /test /pt /tape \\.\tape# | Multiple partition variation

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location
dtape.exe | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk

Click to show or hide information. Test Assertions

Test Assertions

Tape drive should support Short Filemarks if applicable.
Test Assertion GUID: 135481d0-c8f7-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Content will be published

Tape drive should support Long Filemarks if applicable.
Test Assertion GUID: 135481d1-c8f7-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Tape drive should support Filemarks if applicable.
Test Assertion GUID: 135481d2-c8f7-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Tape drive should support Setmarks if applicable.
Test Assertion GUID: 135481d3-c8f7-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device should support Short NON immediate tape erase
Test Assertion GUID: 135481d4-c8f7-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device should support Short immediate tape erase
Test Assertion GUID: 135481d5-c8f7-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

If supported tape drive should be capable of erasing in the middle of data.
Test Assertion GUID: 135481d6-c8f7-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device should support Long NON immediate tape erase
Test Assertion GUID: 135481d7-c8f7-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device should support Long immediate tape erase
Test Assertion GUID: 135481d8-c8f7-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

If supported tape drive should be capable of erasing in the middle of the tape.
Test Assertion GUID: 135481d9-c8f7-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Tape drive should support TAPE_INITIATOR_PARTITIONS.
Test Assertion GUID: 135481da-c8f7-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Tape drive should support TAPE_SELECT_PARTITIONS.
Test Assertion GUID: 135481db-c8f7-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Tape drive should support TAPE_FIXED_PARTITIONS.
Test Assertion GUID: 135481dc-c8f7-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Erasing a partition should not effect any other partitions.
Test Assertion GUID: 135481dd-c8f7-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

All partitions should pass postitioning test.
Test Assertion GUID: 135481de-c8f7-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

All partitions should pass postitioning to marks test.
Test Assertion GUID: 135481df-c8f7-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device should support TAPE_DRIVE_LOGICAL_BLK position.
Test Assertion GUID: 135481e0-c8f7-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device should support TAPE_DRIVE_LOGICAL_BLK_IMMED position.
Test Assertion GUID: 135481e1-c8f7-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device should support TAPE_DRIVE_ABSOLUTE_BLK position.
Test Assertion GUID: 135481e2c8f7-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device should support TAPE_DRIVE_ABS_BLK_IMMED position.
Test Assertion GUID: 135481e3-c8f7-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device should support TAPE_DRIVE_RELATIVE_BLKS position.
Test Assertion GUID: 135481e4-c8f7-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device should support TAPE_DRIVE_REVERSE_POSITION with TAPE_SPACE_RELATIVE_BLOCKS
Test Assertion GUID: 135481e5-c8f7-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device should support TAPE_DRIVE_REWIND_IMMEDIATE position.
Test Assertion GUID: 135481e6-c8f7-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device should support TAPE_DRIVE_END_OF_DATA position.
Test Assertion GUID: 135481e7-c8f7-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device should support TAPE_DRIVE_SET_COMPRESSION
Test Assertion GUID: 135481e8-c8f7-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device should support TAPE_DRIVE_SET_ECC
Test Assertion GUID: 135481e9-c8f7-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device should support TAPE_DRIVE_SET_PADDING
Test Assertion GUID: 135481ea-c8f7-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device should support TAPE_DRIVE_REPORT_SMKS
Test Assertion GUID: 135481eb-c8f7-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device should support variable blocks
Test Assertion GUID: 135481ec-c8f7-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device should support reading data in the same block size as was written
Test Assertion GUID: 135481ed-c8f7-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device should support reading data in the smaller block size than was written
Test Assertion GUID: 7f3a37f5-c8fd-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device should support reading data in the larger block size than was written
Test Assertion GUID: 7f3a37f6-c8fd-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:


SATA IO Sig Test

Type: Automated Test

Overview

This test is designed to collect the SATA IO Signature certification from the user.

Details

The test will prompt the user for their SATA IO certification key. This must be provided and will be reviewed for validity.
Run Time: 1 minute
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running SATA IO Sig Test

Command Syntax

Command option | Description
cscript satasig.vbs [deviceID] |

Code Tour

File Manifest

File | Location
satasig.vbs | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


NTBackup test

Type: Automated Test

Overview

The target component for this test utility is the tape drive and driver and its interoperation with the NTBackup application. This test backs up and restores generated data and verifies that the copies match.

Details

This utility uses RSM calls to enumerate and select media for the tape drive and window messages to control the NTBackup application.
This test checks the NTBACKUP utility. It first creates a tree of data files, then backs up the tree of files to the tape, restores the files, and compares the checksums of the original and restored file trees.
This test requires 4 GB of free disk space on the system drive to complete properly.
The test requires the number of the tape drive. This is provided automatically by DTM when run from the device console.

Run Time: 1 hour
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Tape media

Running NTBackup test

This test requires a system with at least one tape drive (device under test). The test requires writable media in the tape drive, which will be overwritten. The test also requires at least 4 Gb of free hard drive space for temporary files.

Command Syntax

Command option | Description
bkup50 -d:\\.\tape# -v |

Cautions

Troubleshooting

You may see failures if you are using bad media. Please use new media and ensure that the drive is clean.

Reference Documentation

Code Tour

File Manifest

File | Location
bkup50.exe | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk

Click to show or hide information. Test Assertions

Test Assertions

NT Backup must not currently be running.
Test Assertion GUID: 65a799d2-c6a4-11da-94f5-00123f3a6b60

System must permit configuration of media, and temporary folders.
Test Assertion GUID: 65a799d3-c6a4-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

System must have NT Backup application installed and configured correctly.
Test Assertion GUID: 65a799d4-c6a4-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Device must backup data by using NT Backup.
Test Assertion GUID: 65a799d5-c6a4-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

Data restored from backup using NT Backup must match original data.
Test Assertion GUID: 65a799d6-c6a4-11da-94f5-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

The user must not press control-c during execution.
Test Assertion GUID: 65a799d7-c6a4-11da-94f5-00123f3a6b60


iSCSI iSNS Compliance Test

Type: Automated Test

Overview

The iSCSI iSNS Compliance test verifies that target devices (for example, disk, tape, and media changer devices) can properly register with and be discovered by an Internet Storage Name Service (iSNS) server.

Details

This iSNS Compliance test verifies that the MS initiator can log on to the device under test using the information that the target registers with the iSNS server. The test begins by clearing all existing discovery information on the initiator and adding the iSNS server as the only discovery mechanism. The test then verifies that the device under test is found using the iSNS server. The test the verifies it can log on to the target.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running iSCSI iSNS Compliance Test

Prior to running the test, the tester must register the device under test with the iSNS server.
Run the test as a DTM job.
Fill the required data in the configuration UI that pops up when this job is scheduled

Command Syntax

Command option | Description
iscsi_targetisns -hct |

Code Tour

File Manifest

File | Location
iscsi_targetisns.exe | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\iscsi

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


iSCSI Digest - Tape (HBA)

Type: Automated Test

Overview

This test verifies that the host-bus adapter (HBA) supports header and data digests as negotiated during the logon phase.

Details

The iSCSI Digest - Tape (HBA) test follows this algorithm:
  1. Prepares the system for iSCSI operations
    • If the target used for testing is already logged on, the session information is saved so the session can be restored later.
    • The target tape device is added as a static iSCSI target.
  2. Performs iSCSI operations
    • If the target used for testing is already logged on, the current session to the target is logged out.
    • The target is logged on using the HBA under test with header digests enabled.
    • After logging on to the target, the test waits for the tape device to be enumerated on the test system.
    • The test will perform tape I/O operations using the current target session.
    • The test repeats the above steps with data digests only enabled and header and data digests enabled.
    • The HBA under test must properly logon using all three digest combinations with no I/O failures detected during I/O operations.
  3. Restores any previous iSCSI target sessions.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Combination iSCSI tape and media changer device or iSCSI bridge with combination tape and media changer device attached

Running iSCSI Digest - Tape (HBA)

Logon to the tape target and format the target.
Run the test as a DTM job
Fill the required data in the configuration UI that pops up when this job is scheduled

Command Syntax

Command option | Description
iscsi_digest -hct -l tape -a -c hba |

Cautions

Troubleshooting

  1. Look at the job results log file for test failures
  2. Verify the iSCSI configuration information is entered correctly in the configuration dialog (Popup Dialog box when the job is scheduled from device console)

Reference Documentation

Code Tour

File Manifest

File | Location
iscsi_digest.exe | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\iscsi

Click to show or hide information. Test Assertions

Test Assertions

1.1 Setting up test, and saving open sessions.
Test Assertion GUID: 0df19e9d-c42e-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: The setup stage is responsible for getting the current sessions to the target and then persistenting that information so it can be used to reestablish these sessions during the cleanup stage.

2.1 The HBA must be able to log into the target successfully with digests enabled.
Test Assertion GUID: 7f102024-c42e-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

3.1 The HBA must successfully logout from target.
Test Assertion GUID: 7f102026-c42e-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4.1 Cleaning up test, restoring sessions.
Test Assertion GUID: 7f102028-c42e-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: The cleanup stage is responsible for restoring the sessions that were persisted during the setup stage.


iSCSI HBA Oneway CHAP

Type: Automated Test

Overview

The iSCSI HBA Oneway CHAP test verifies that the initiator, that is, the host system that initiates the block storage transfer, can use the Challenge Handshake Authentication Protocol (CHAP) authentication mechanism. The test verifies one-way CHAP.

Details

The Oneway CHAP test implements a simple test target and does not require a separate iSCSI target device. The test initiates a login to the test target specifying one-way CHAP. The target verifies that the initiator follows the CHAP protocol specifics detailed in the iSCSI specification. Different test variations will use different encodings (Base16 or Base64) for CHAP challenges. In addition, the test verifies that the HBA handles an authentication error correctly and returns the appropriate status to the user.
Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • 1-GB network adapter.

Running iSCSI HBA Oneway CHAP

Run the test as a DTM job

Fill the required data in the configuration UI that pops up when this job is scheduled

Command Syntax

Command option | Description
iscsi_initchap -oneway -hct |

Cautions

Troubleshooting

  1. Look at the job results log file for test failures
  2. Verify the iSCSI configuration information is entered correctly in the configuration dialog (Popup Dialog box when the job is scheduled from device console)

Reference Documentation

Code Tour

File Manifest

File | Location
iscsi_initchap.exe | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\iscsi

Click to show or hide information. Test Assertions

Test Assertions

1 Received PDU is a valid login request PDU.
Test Assertion GUID: ef76110a-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The initiator can only use logon request PDUs during iSCSI logon. Apply: The test initiates a CHAP logon by using the LoginIScsiTarget routine. Expect: Each PDU that the test receives has the opcode field set to 0x03.

2 Login request data segment must be NULL terminated.
Test Assertion GUID: ef76110b-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: All logon request PDUs with the data segment length greater than zero must have a NULL terminator in the last valid byte (non-pad byte) of the data segment. Only key = value pairs are allowed in the request-PDU data segments, and the last byte must indicate the end of the last key = value pair. Apply: The test initiates a Challenge Handshake Authentication Protocol (CHAP) logon to the test target by using the LoginIScsiTarget routine. Expect: Each PDU that a test target receives with a data segment must have the last non-padding byte of the PDU set to zero.

3 Bit one of the first byte in a login request PDU must be set to one.
Test Assertion GUID: ef76110c-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI oneway/Mutual CHAP (HBA) test checks that the HBA sets bit one of the first byte of the logon request PDU. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. Expect: For any logon request PDU sent by the HBA to the test target address, bit one of the first byte must be set to 1.

100 Initial login request must specify the security negotation stage as the current stage.
Test Assertion GUID: ef76110d-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the iSCSI HBA does not request transition out of the security negotiation stage while authentication is being performed. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. Expect: The logon request PDU sent by the HBA must set the current stage (CSG) field of the PDU to 0x00 and the T (transit) bit must be set to 0.

101 Initial login request must contain a data segment.
Test Assertion GUID: ef76110e-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test validates that the length of the data segment in the initial logon-request PDU is nonzero. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. Expect: The HBA sends an iSCSI logon request PDU to the test target address. The data segment of this request must contain a data segment since required key = value pairs for the initial logon request are present.

102 The initial login request must contain one and only one TargetName key.
Test Assertion GUID: ef76111c-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the initial request PDU from the HBA contains only one TargetName key. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. Expect: The initial logon request PDU from the HBA contains a TargetName key. Only one TargetName key is required.

103 The TargetName specified in the initial login request must be the same as the target name specified by the login API.
Test Assertion GUID: ef76111d-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the HBA uses the correct target name as specified by the iSCSI service during logon. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. Expect: The initial logon request PDU must contain the name of the test target in the TargetName key.

104 The initial login request must contain one and only one InitiatorName key.
Test Assertion GUID: ef76111e-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the initial request PDU from the HBA contains only one InitiatorName key. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. Expect: The initial logon request PDU from the HBA contains an InitiatorName key. Only one of these keys can be used.

105 The initial login request may only specify one SessionType key, if any, when performing a full login.
Test Assertion GUID: ef76111f-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the initial request PDU from the HBA contains zero or one SessionType key. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. Expect: The initial logon request PDU from the HBA contains either one SessionType key or none at all. When performing a nondiscovery logon, the SessionType key is optional because the default value is normal.

106 The SessionType key in the initial login must specify Normal as the session type.
Test Assertion GUID: ef761120-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the value of the SessionType key specifies that the current session type is a non-discovery session. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. Expect: If the SessionType key is included in the initial logon request PDU from the HBA, it must be SessionType = Normal.

107 The initial login request must contain one and only one AuthMethod key.
Test Assertion GUID: ef761121-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the initial request PDU from the HBA contains only one AuthMethod key. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. Expect: The initial logon request PDU from the HBA contains an AuthMethod key. Only one AuthMethod key is used.

108 The AuthMethod key must specify CHAP as the first value in the list of supported values.
Test Assertion GUID: ef761122-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the initial request PDU from the HBA specifies CHAP as the preferred value for security authentication. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. Expect: The initial logon request PDU from the HBA specifies CHAP as the first value in a list of possible AuthMethod values.

109 Initial login request must not contain any invalid text keys.
Test Assertion GUID: ef76110f-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test checks that the initial logon request received from the HBA contains only the valid keys for this PDU. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. Expect: The initiator may only include the following keys in the first logon request: InitiatorName, TargetName, SessionType, and AuthMethod.

200 The iSCSI login request that proposes the CHAP algorithm must specify the correct iSCSI stage.
Test Assertion GUID: ef761110-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the iSCSI HBA does not request transition out of the security negotiation stage while authentication is being performed. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The target responds to the initial logon request by selecting CHAP as the AuthMethod. Expect: The logon request PDU sent by the HBA must set the current stage (CSG) field of the PDU to 0x00 and the T (transit) bit must be set to zero (0).

201 The iSCSI login request that proposes the CHAP algorithm must contain a data segment.
Test Assertion GUID: ef761111-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test validates that the length of the data segment in the logon request PDU is nonzero. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The target responds to the initial logon request by selecting CHAP as the AuthMethod. Expect: The logon request PDU sent as part of the CHAP algorithm proposal must contain a data segment that carries the proposed CHAP algorithms.

203 The iSCSI login request that proposes the CHAP algorithm must contain one and only one CHAP_A key.
Test Assertion GUID: 03515b59-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the initial request PDU from the HBA contains only one CHAP_A key. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The target responds to the initial logon request by selecting CHAP as the AuthMethod. Expect: The logon request PDU sent from the HBA must contain the CHAP_A key.

204 Each value included in the CHAP_A key must be a valid numeric value.
Test Assertion GUID: 03515b5a-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that all values specified in the CHAP_A key must be valid numeric values. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The target responds to the initial logon request by selecting CHAP as the AuthMethod. Expect: Each value in the list of supported CHAP_A values must be a valid numeric value.

205 The list of supported CHAP_A values must contain one and only one value specifying MD5.
Test Assertion GUID: 03515b5b-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that one of the values included in the list of CHAP algorithms is MD5. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The target responds to the initial logon request by selecting CHAP as the AuthMethod. Expect: One value in the list of CHAP_A values must be equal to 5.

206 The iSCSI login request that proposes the CHAP algorithm must contain no invalid text keys.
Test Assertion GUID: ef761112-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test checks that the logon request PDU with the CHAP_A algorithms contains only valid keys for this stage of CHAP authentication. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The target responds to the initial logon request by selecting CHAP as the AuthMethod. Expect: The HBA must include the CHAP_A key in this logon request PDU.

300 The iSCSI login request that includes the CHAP response must specify the security negotiation stage as the current stage.
Test Assertion GUID: ef761113-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test checks that the iSCSI HBA specifies the current stage as the security negotiation stage when returning a CHAP response to the target. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm. Expect: The logon request PDU sent by the HBA must set the current stage (CSG) field of the PDU to 0x00.

301 The iSCSI login request that includes the CHAP response must specify a valid stage when the transit bit is set.
Test Assertion GUID: ef761114-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test checks whether the transit bit is set in the CHAP response logon request. If it is set in the CHAP response, then the next stage field of the PDU must be valid and greater than the current stage field. This check is not made if the T (transit) bit is not set as the next stage field is irrelevant. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget target. The target selects MD5 as the CHAP algorithm. Expect: The HBA sends an iSCSI logon request PDU to the test target address. If the transit bit is set, the next stage field must be valid and greater than the current stage. The next stage must be set to either logon operation negotiation (0x01), or full feature phase (0x03).

302 The iSCSI login request that includes the CHAP response must contain a data segment.
Test Assertion GUID: ef761115-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test validates that the logon request PDU with the CHAP response contains a data segment. Apply: The test initiates a CHAP logon to the test target by using LoginIScsiTarget. The target selects MD5 as the CHAP algorithm. Expect: The logon request PDU sent with the CHAP response must contain a data segment.

303 The iSCSI login request that includes the CHAP response must contain one and only one CHAP_N key.
Test Assertion GUID: 03515b64-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the HBA returns only one CHAP_N key with the CHAP response. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm. Expect: The logon request PDU sent from the HBA must contain the CHAP_N key.

304 The CHAP_N key must contain the user name that was specified by the iSCSI Login API.
Test Assertion GUID: 03515b65-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the HBA returns only one CHAP_N key with the CHAP response logon request PDU. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. During the logon, it provides a specific user name for the HBA to use for CHAP logon. Expect: The logon request PDU sent with the user name (CHAP_N key) contains the same user name as specified in the Login API.

305 The iSCSI login request that includes the CHAP response must contain one and only one CHAP_R key.
Test Assertion GUID: 03515b66-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the HBA returns only one CHAP_R key with the CHAP response logon request PDU. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm and includes a CHAP_I and CHAP_C key to use in computing the CHAP response. Expect: The logon request PDU sent from the HBA must contain the CHAP_R key.

306 The CHAP_R key must contain only one value.
Test Assertion GUID: 03515b67-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the CHAP_R key returned as part of the CHAP response logon request PDU does not contain a list of values. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm and includes a CHAP_I and CHAP_C key for use in computing the CHAP response. Expect: The CHAP_R key may only contain one value.

307 The CHAP_R value must be a valid large binary value.
Test Assertion GUID: 03515b68-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the value returned in the CHAP_R key is a properly encoded binary value. Although the CHAP_R response may be a binary value, for MD5, the required length exceeds the 8-byte limit for decimal encoded responses. Therefore, the encoding may only be hexadecimal or base 64. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm and includes a CHAP_I and CHAP_C key for use in computing the CHAP response. Expect: The value of the target’s response PDU CHAP_R is properly encoded as a large-binary-value as defined in section 5.1 of the iSCSI Specification. The value can be encoded either as a hex constant or as a base 64 constant.

308 The CHAP_R value must be 16 bytes in length (unencoded).
Test Assertion GUID: 03515b69-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test checks that the CHAP_R key value is equal to 16 bytes, which is the required length for responses returned as part of the MD5 algorithm. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm and includes a CHAP_I and CHAP_C key to use in computing the CHAP response. Expect: The decoded length of the HBA’s CHAP response must be 16 bytes.

309 The CHAP response must be computed correctly.
Test Assertion GUID: ef761116-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the CHAP response returned by the HBA is equivalent to the expected response based on the target secret and the CHAP_I and CHAP_C values sent by the target. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm and includes a CHAP_I and CHAP_C key to use in computing the CHAP response. Expect: The HBA returns a CHAP_R response key with the correct response value.

310 The iSCSI login request that contains the CHAP response must not contain invalid keys.
Test Assertion GUID: ef761117-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that only valid keys are contained in the CHAP response packet. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm and includes a CHAP_I and CHAP_C key to use in computing the CHAP response. Expect: The logon request packet with HBA contains only the CHAP_N and CHAP_R keys when doing one-way CHAP. When mutual CHAP is performed, the CHAP_I and CHAP_C keys are also considered valid. Any other keys are considered errors.

311 The iSCSI login request that includes a mutual CHAP response must contan one and only CHAP_I key.
Test Assertion GUID: 03515b5c-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the HBA logon request contains only one CHAP_I key when performing mutual CHAP. Apply: The test initiates a mutual CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm and includes a CHAP_I and CHAP_C key to use in computing the CHAP response. Expect: The HBA logon request packet PDU must contain one CHAP_I key with the same logon request PDU that contains the CHAP response for the target.

312 The CHAP_I key must contain only one value in the key.
Test Assertion GUID: 03515b5d-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the HBA does not return a list of values in the CHAP_I key when performing mutual CHAP. Apply: The test initiates a mutual CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm and includes a CHAP_I and CHAP_C key for use in computing the CHAP response. Expect: The HBA logon request packet PDU must contain one CHAP_I key and must not contain more than one value for this key.

313 The value specified for the CHAP_I key must be valid numeric value.
Test Assertion GUID: 03515b5e-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the value provided in the CHAP_I= key is a properly encoded numeric value. Apply: The test initiates a mutual CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm and includes a CHAP_I and CHAP_C key for use in computing the CHAP response. Expect: The value of the HBA’s CHAP_I key must be properly encoded as a numerical value as defined in section 5.1 of the iSCSI specification. The value may be encoded as a decimal or hexadecimal value.

314 The specified CHAP_I value must not be greater than 255.
Test Assertion GUID: 03515b5f-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the CHAP_I key value is only one byte in its unencoded form. Apply: The test initiates a mutual CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm and includes a CHAP_I and CHAP_C key to use in computing the CHAP response. Expect: The HBA logon request PDU must have a CHAP_I value that is not greater than 255 after it is decoded.

315 The iSCSI login request that includes a mutual CHAP response must contan one and only CHAP_C key.
Test Assertion GUID: 03515b60-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the HBA logon request contains only one CHAP_C key when performing mutual CHAP. Apply: The test initiates a mutual CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm and includes a CHAP_I and CHAP_C key to use in computing the CHAP response. Expect: The HBA logon request packet PDU has one CHAP_C key.

316 The CHAP_C key must contain only one value.
Test Assertion GUID: 03515b61-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the HBA does not return a list of values in the CHAP_C key when performing mutual CHAP. Apply: The test initiates a mutual CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm and includes a CHAP_I and CHAP_C key for use in computing the CHAP response. Expect: The HBA logon request packet PDU must contain one CHAP_C key and must not contain more than one value for this key.

317 The CHAP_C value must be a valid large binary value.
Test Assertion GUID: 03515b62-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the value provided in the CHAP_C key is a properly encoded large binary value. Apply: The test initiates a mutual CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm and includes a CHAP_I and CHAP_C key to use in computing the CHAP response. Expect: The value of the HBA’s CHAP_C key must be properly encoded as a large-binary value as defined in section 5.1 of the iSCSI specification. The value may be encoded as a hexadecimal or base 64 constant.

318 The CHAP_C value must not be longer than 1024 bytes (unencoded).
Test Assertion GUID: 03515b63-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test checks that CHAP_C= key value is not longer than the maximum length allowed. The maximum byte length is 1024 bytes. Apply: The test initiates a mutual CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm and includes a CHAP_I and CHAP_C key to use in computing the CHAP response. Expect: The nonencoded length of the CHAP_C key must be less than or equal to 1024 bytes.

400 The final login request of the security stage must set the current stage to the security stage.
Test Assertion GUID: ef761118-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test checks that the iSCSI HBA specifies the current stage as the security negotiation stage when requesting transition from that stage. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The test target checks the CHAP response that the HBA returns. The logon response PDU indicates that the authentication was successful. If mutual CHAP is tested, this packet also includes the computed CHAP response. This packet does not set the T (transit) bit, and therefore, the HBA must send another packet requesting transition to the next stage. Expect: The logon request PDU sent by the HBA must set the current stage (CSG) field of the PDU to 0x00.

401 The final login request of the security stage must set the Transit bit in the PDU.
Test Assertion GUID: ef761119-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that an HBA indicates it is ready to proceed to another stage after security negotiation has been completed. This condition is checked in both one-way and mutual CHAP. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The test target checks the CHAP response returned by the HBA. The logon response PDU indicates that authentication was successful. If mutual CHAP is tested, this packet also includes the computed CHAP response. This packet does not set the T (transit) bit, and, therefore, the HBA must send another packet requesting transition to the next stage. Expect: The HBA returns a logon request PDU with the T (transit) bit set to 1.

402 The final login request of the security stage must specify a valid next stage.
Test Assertion GUID: ef76111a-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that an HBA sets the next stage field of the iSCSI logon request PDU to a valid value. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The test target checks the CHAP response returned by the HBA. The logon response PDU indicates that authentication was successful. If mutual CHAP is tested, this packet also includes the computed CHAP response. This packet does not set the T (transit) bit and therefore the HBA must send another packet that requests a transition to the next stage. Expect: The next stage field of the logon request PDU is set to either the operational negotiation stage (0x01) or the full-feature stage (0x03).

403 The final login request of the security stage must not contain a data segment.
Test Assertion GUID: ef76111b-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that an HBA does not include a data segment in the logon request PDU. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The test target checks the CHAP response that is returned by the HBA. The logon response PDU indicates that authentication was successful. If mutual CHAP is tested, this packet also includes the computed CHAP response. This packet does not set the T (transit) bit, and, therefore, the HBA must send another packet that requests a transition to the next stage. Expect: The data segment should not contain any data. The security negotiation has been completed, and, therefore, the HBA and target must transition to the next stage before any more items can be negotiated.

1000 The HBA must connect to the test target.
Test Assertion GUID: ef761105-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test checks that the HBA establishes a connection with the test target. Apply: The test uses the LoginIScsiTarget routine to connect to the test target. Expect: The HBA establishes a TCP/IP connection with the test target.

1001 Connection must remain established during login.
Test Assertion GUID: ef761108-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test checks that the HBA maintains the connection with the test target until the logon process is completed. Apply: The test uses the LoginIScsiTarget routine to connect to the test target. During testing, the test target either returns an error status code in a logon response PDU or returns an invalid CHAP_R response to the initiator during mutual CHAP. Expect: The connection between the HBA and the test target must be maintained until the logon process is terminated by an error status code returned by the test target or an inappropriate response. A failure indicates that the HBA terminated the connection prematurely.

1002 iSCSI Login function must not complete while the HBA is still performing the iSCSI login phase.
Test Assertion GUID: ef761109-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test checks that the HBA driver does not complete the iSCSI logon request from the iSCSI service until the final status of the logon with the test target is completed. Apply: The test uses the LoginIScsiTarget routine to connect to the test target. Expect: The iSCSI logon request sent by the iSCSI service to the target must succeed after the logon process is terminated or the logon process succeeds. A failure indicates that control was returned to the service while the logon process was not yet terminated in error or was successfully completed.

1004 HBA must not send data after target ends login.
Test Assertion GUID: ef761106-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test checks that the HBA does not send any more data to the test target after the test target aborts the logon process. Apply: The test uses the LoginIScsiTarget routine to connect to the test target. The test target, upon completion of CHAP validation, returns an error to terminate the logon. Expect: The HBA honors the error code returned and does not send more data to the target.

1005 HBA must return ISDSC_AUTHENTICATION_FAILURE when the target rejects the CHAP response.
Test Assertion GUID: ef761107-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test checks that the HBA driver returns the ISDSC_AUTHENTICATION_FAILURE code to the iSCSI service when an authentication failure occurs. Apply: The test uses the LoginIScsiTarget routine to connect to the test target. The test target either fails the first stage during one-way CHAP or returns an invalid CHAP response during mutual CHAP. Expect: The HBA driver must properly indicate the authentication failure by returning ISDSC_AUTHENTICATION_FAILURE to the service.


iSCSI HBA Mutual CHAP

Type: Automated Test

Overview

The iSCSI HBA Mutual CHAP test verifies that the initiator, that is, the host system that initiates the block storage transfer, can use the Challenge Handshake Authentication Protocol (CHAP) authentication mechanism. The test verifies mutual CHAP.

Details

The Mutual CHAP test implements a simple test target and does not require a separate iSCSI target device. The test initiates a login to the test target specifying mutual CHAP. The target verifies that the initiator follows the CHAP protocol specifics detailed in the iSCSI specification. Different test variations will use different encodings (Base16 or Base64) for CHAP responses. In addition, the test returns both valid and invalid responses to the initiator's challenge in order to verify that the HBA properly authenticates the target and returns the appropriate status to the user.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • 1-GB network adapter.

Running iSCSI HBA Mutual CHAP

Run the test as a DTM job

Fill the required data in the configuration UI that pops up when this job is scheduled

Command Syntax

Command option | Description
iscsi_initchap -mutual -hct |

Cautions

Troubleshooting

  1. Look at the job results log file for test failures
  2. Verify the iSCSI configuration information is entered correctly in the configuration dialog (Popup Dialog box when the job is scheduled from device console)

Reference Documentation

Code Tour

File Manifest

File | Location
iscsi_initchap.exe | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\iscsi

Click to show or hide information. Test Assertions

Test Assertions

1 Received PDU is a valid login request PDU.
Test Assertion GUID: ef76110a-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The initiator can only use logon request PDUs during iSCSI logon. Apply: The test initiates a CHAP logon by using the LoginIScsiTarget routine. Expect: Each PDU that the test receives has the opcode field set to 0x03.

2 Login request data segment must be NULL terminated.
Test Assertion GUID: ef76110b-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: All logon request PDUs with the data segment length greater than zero must have a NULL terminator in the last valid byte (non-pad byte) of the data segment. Only key = value pairs are allowed in the request-PDU data segments, and the last byte must indicate the end of the last key = value pair. Apply: The test initiates a Challenge Handshake Authentication Protocol (CHAP) logon to the test target by using the LoginIScsiTarget routine. Expect: Each PDU that a test target receives with a data segment must have the last non-padding byte of the PDU set to zero.

3 Bit one of the first byte in a login request PDU must be set to one.
Test Assertion GUID: ef76110c-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI oneway/Mutual CHAP (HBA) test checks that the HBA sets bit one of the first byte of the logon request PDU. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. Expect: For any logon request PDU sent by the HBA to the test target address, bit one of the first byte must be set to 1.

100 Initial login request must specify the security negotation stage as the current stage.
Test Assertion GUID: ef76110d-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the iSCSI HBA does not request transition out of the security negotiation stage while authentication is being performed. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. Expect: The logon request PDU sent by the HBA must set the current stage (CSG) field of the PDU to 0x00 and the T (transit) bit must be set to 0.

101 Initial login request must contain a data segment.
Test Assertion GUID: ef76110e-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test validates that the length of the data segment in the initial logon-request PDU is nonzero. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. Expect: The HBA sends an iSCSI logon request PDU to the test target address. The data segment of this request must contain a data segment since required key = value pairs for the initial logon request are present.

102 The initial login request must contain one and only one TargetName key.
Test Assertion GUID: ef76111c-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the initial request PDU from the HBA contains only one TargetName key. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. Expect: The initial logon request PDU from the HBA contains a TargetName key. Only one TargetName key is required.

103 The TargetName specified in the initial login request must be the same as the target name specified by the login API.
Test Assertion GUID: ef76111d-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the HBA uses the correct target name as specified by the iSCSI service during logon. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. Expect: The initial logon request PDU must contain the name of the test target in the TargetName key.

104 The initial login request must contain one and only one InitiatorName key.
Test Assertion GUID: ef76111e-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the initial request PDU from the HBA contains only one InitiatorName key. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. Expect: The initial logon request PDU from the HBA contains an InitiatorName key. Only one of these keys can be used.

105 The initial login request may only specify one SessionType key, if any, when performing a full login.
Test Assertion GUID: ef76111f-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the initial request PDU from the HBA contains zero or one SessionType key. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. Expect: The initial logon request PDU from the HBA contains either one SessionType key or none at all. When performing a nondiscovery logon, the SessionType key is optional because the default value is normal.

106 The SessionType key in the initial login must specify Normal as the session type.
Test Assertion GUID: ef761120-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the value of the SessionType key specifies that the current session type is a non-discovery session. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. Expect: If the SessionType key is included in the initial logon request PDU from the HBA, it must be SessionType = Normal.

107 The initial login request must contain one and only one AuthMethod key.
Test Assertion GUID: ef761121-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the initial request PDU from the HBA contains only one AuthMethod key. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. Expect: The initial logon request PDU from the HBA contains an AuthMethod key. Only one AuthMethod key is used.

108 The AuthMethod key must specify CHAP as the first value in the list of supported values.
Test Assertion GUID: ef761122-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the initial request PDU from the HBA specifies CHAP as the preferred value for security authentication. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. Expect: The initial logon request PDU from the HBA specifies CHAP as the first value in a list of possible AuthMethod values.

109 Initial login request must not contain any invalid text keys.
Test Assertion GUID: ef76110f-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test checks that the initial logon request received from the HBA contains only the valid keys for this PDU. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. Expect: The initiator may only include the following keys in the first logon request: InitiatorName, TargetName, SessionType, and AuthMethod.

200 The iSCSI login request that proposes the CHAP algorithm must specify the correct iSCSI stage.
Test Assertion GUID: ef761110-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the iSCSI HBA does not request transition out of the security negotiation stage while authentication is being performed. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The target responds to the initial logon request by selecting CHAP as the AuthMethod. Expect: The logon request PDU sent by the HBA must set the current stage (CSG) field of the PDU to 0x00 and the T (transit) bit must be set to zero (0).

201 The iSCSI login request that proposes the CHAP algorithm must contain a data segment.
Test Assertion GUID: ef761111-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test validates that the length of the data segment in the logon request PDU is nonzero. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The target responds to the initial logon request by selecting CHAP as the AuthMethod. Expect: The logon request PDU sent as part of the CHAP algorithm proposal must contain a data segment that carries the proposed CHAP algorithms.

203 The iSCSI login request that proposes the CHAP algorithm must contain one and only one CHAP_A key.
Test Assertion GUID: 03515b59-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the initial request PDU from the HBA contains only one CHAP_A key. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The target responds to the initial logon request by selecting CHAP as the AuthMethod. Expect: The logon request PDU sent from the HBA must contain the CHAP_A key.

204 Each value included in the CHAP_A key must be a valid numeric value.
Test Assertion GUID: 03515b5a-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that all values specified in the CHAP_A key must be valid numeric values. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The target responds to the initial logon request by selecting CHAP as the AuthMethod. Expect: Each value in the list of supported CHAP_A values must be a valid numeric value.

205 The list of supported CHAP_A values must contain one and only one value specifying MD5.
Test Assertion GUID: 03515b5b-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that one of the values included in the list of CHAP algorithms is MD5. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The target responds to the initial logon request by selecting CHAP as the AuthMethod. Expect: One value in the list of CHAP_A values must be equal to 5.

206 The iSCSI login request that proposes the CHAP algorithm must contain no invalid text keys.
Test Assertion GUID: ef761112-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test checks that the logon request PDU with the CHAP_A algorithms contains only valid keys for this stage of CHAP authentication. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The target responds to the initial logon request by selecting CHAP as the AuthMethod. Expect: The HBA must include the CHAP_A key in this logon request PDU.

300 The iSCSI login request that includes the CHAP response must specify the security negotiation stage as the current stage.
Test Assertion GUID: ef761113-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test checks that the iSCSI HBA specifies the current stage as the security negotiation stage when returning a CHAP response to the target. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm. Expect: The logon request PDU sent by the HBA must set the current stage (CSG) field of the PDU to 0x00.

301 The iSCSI login request that includes the CHAP response must specify a valid stage when the transit bit is set.
Test Assertion GUID: ef761114-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test checks whether the transit bit is set in the CHAP response logon request. If it is set in the CHAP response, then the next stage field of the PDU must be valid and greater than the current stage field. This check is not made if the T (transit) bit is not set as the next stage field is irrelevant. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget target. The target selects MD5 as the CHAP algorithm. Expect: The HBA sends an iSCSI logon request PDU to the test target address. If the transit bit is set, the next stage field must be valid and greater than the current stage. The next stage must be set to either logon operation negotiation (0x01), or full feature phase (0x03).

302 The iSCSI login request that includes the CHAP response must contain a data segment.
Test Assertion GUID: ef761115-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test validates that the logon request PDU with the CHAP response contains a data segment. Apply: The test initiates a CHAP logon to the test target by using LoginIScsiTarget. The target selects MD5 as the CHAP algorithm. Expect: The logon request PDU sent with the CHAP response must contain a data segment.

303 The iSCSI login request that includes the CHAP response must contain one and only one CHAP_N key.
Test Assertion GUID: 03515b64-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the HBA returns only one CHAP_N key with the CHAP response. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm. Expect: The logon request PDU sent from the HBA must contain the CHAP_N key.

304 The CHAP_N key must contain the user name that was specified by the iSCSI Login API.
Test Assertion GUID: 03515b65-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the HBA returns only one CHAP_N key with the CHAP response logon request PDU. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. During the logon, it provides a specific user name for the HBA to use for CHAP logon. Expect: The logon request PDU sent with the user name (CHAP_N key) contains the same user name as specified in the Login API.

305 The iSCSI login request that includes the CHAP response must contain one and only one CHAP_R key.
Test Assertion GUID: 03515b66-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the HBA returns only one CHAP_R key with the CHAP response logon request PDU. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm and includes a CHAP_I and CHAP_C key to use in computing the CHAP response. Expect: The logon request PDU sent from the HBA must contain the CHAP_R key.

306 The CHAP_R key must contain only one value.
Test Assertion GUID: 03515b67-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the CHAP_R key returned as part of the CHAP response logon request PDU does not contain a list of values. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm and includes a CHAP_I and CHAP_C key for use in computing the CHAP response. Expect: The CHAP_R key may only contain one value.

307 The CHAP_R value must be a valid large binary value.
Test Assertion GUID: 03515b68-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the value returned in the CHAP_R key is a properly encoded binary value. Although the CHAP_R response may be a binary value, for MD5, the required length exceeds the 8-byte limit for decimal encoded responses. Therefore, the encoding may only be hexadecimal or base 64. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm and includes a CHAP_I and CHAP_C key for use in computing the CHAP response. Expect: The value of the target’s response PDU CHAP_R is properly encoded as a large-binary-value as defined in section 5.1 of the iSCSI Specification. The value can be encoded either as a hex constant or as a base 64 constant.

308 The CHAP_R value must be 16 bytes in length (unencoded).
Test Assertion GUID: 03515b69-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test checks that the CHAP_R key value is equal to 16 bytes, which is the required length for responses returned as part of the MD5 algorithm. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm and includes a CHAP_I and CHAP_C key to use in computing the CHAP response. Expect: The decoded length of the HBA’s CHAP response must be 16 bytes.

309 The CHAP response must be computed correctly.
Test Assertion GUID: ef761116-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the CHAP response returned by the HBA is equivalent to the expected response based on the target secret and the CHAP_I and CHAP_C values sent by the target. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm and includes a CHAP_I and CHAP_C key to use in computing the CHAP response. Expect: The HBA returns a CHAP_R response key with the correct response value.

310 The iSCSI login request that contains the CHAP response must not contain invalid keys.
Test Assertion GUID: ef761117-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that only valid keys are contained in the CHAP response packet. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm and includes a CHAP_I and CHAP_C key to use in computing the CHAP response. Expect: The logon request packet with HBA contains only the CHAP_N and CHAP_R keys when doing one-way CHAP. When mutual CHAP is performed, the CHAP_I and CHAP_C keys are also considered valid. Any other keys are considered errors.

311 The iSCSI login request that includes a mutual CHAP response must contan one and only CHAP_I key.
Test Assertion GUID: 03515b5c-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the HBA logon request contains only one CHAP_I key when performing mutual CHAP. Apply: The test initiates a mutual CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm and includes a CHAP_I and CHAP_C key to use in computing the CHAP response. Expect: The HBA logon request packet PDU must contain one CHAP_I key with the same logon request PDU that contains the CHAP response for the target.

312 The CHAP_I key must contain only one value in the key.
Test Assertion GUID: 03515b5d-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the HBA does not return a list of values in the CHAP_I key when performing mutual CHAP. Apply: The test initiates a mutual CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm and includes a CHAP_I and CHAP_C key for use in computing the CHAP response. Expect: The HBA logon request packet PDU must contain one CHAP_I key and must not contain more than one value for this key.

313 The value specified for the CHAP_I key must be valid numeric value.
Test Assertion GUID: 03515b5e-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the value provided in the CHAP_I= key is a properly encoded numeric value. Apply: The test initiates a mutual CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm and includes a CHAP_I and CHAP_C key for use in computing the CHAP response. Expect: The value of the HBA’s CHAP_I key must be properly encoded as a numerical value as defined in section 5.1 of the iSCSI specification. The value may be encoded as a decimal or hexadecimal value.

314 The specified CHAP_I value must not be greater than 255.
Test Assertion GUID: 03515b5f-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the CHAP_I key value is only one byte in its unencoded form. Apply: The test initiates a mutual CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm and includes a CHAP_I and CHAP_C key to use in computing the CHAP response. Expect: The HBA logon request PDU must have a CHAP_I value that is not greater than 255 after it is decoded.

315 The iSCSI login request that includes a mutual CHAP response must contan one and only CHAP_C key.
Test Assertion GUID: 03515b60-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the HBA logon request contains only one CHAP_C key when performing mutual CHAP. Apply: The test initiates a mutual CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm and includes a CHAP_I and CHAP_C key to use in computing the CHAP response. Expect: The HBA logon request packet PDU has one CHAP_C key.

316 The CHAP_C key must contain only one value.
Test Assertion GUID: 03515b61-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the HBA does not return a list of values in the CHAP_C key when performing mutual CHAP. Apply: The test initiates a mutual CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm and includes a CHAP_I and CHAP_C key for use in computing the CHAP response. Expect: The HBA logon request packet PDU must contain one CHAP_C key and must not contain more than one value for this key.

317 The CHAP_C value must be a valid large binary value.
Test Assertion GUID: 03515b62-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that the value provided in the CHAP_C key is a properly encoded large binary value. Apply: The test initiates a mutual CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm and includes a CHAP_I and CHAP_C key to use in computing the CHAP response. Expect: The value of the HBA’s CHAP_C key must be properly encoded as a large-binary value as defined in section 5.1 of the iSCSI specification. The value may be encoded as a hexadecimal or base 64 constant.

318 The CHAP_C value must not be longer than 1024 bytes (unencoded).
Test Assertion GUID: 03515b63-c4c9-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test checks that CHAP_C= key value is not longer than the maximum length allowed. The maximum byte length is 1024 bytes. Apply: The test initiates a mutual CHAP logon to the test target by using the LoginIScsiTarget routine. The target selects MD5 as the CHAP algorithm and includes a CHAP_I and CHAP_C key to use in computing the CHAP response. Expect: The nonencoded length of the CHAP_C key must be less than or equal to 1024 bytes.

400 The final login request of the security stage must set the current stage to the security stage.
Test Assertion GUID: ef761118-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test checks that the iSCSI HBA specifies the current stage as the security negotiation stage when requesting transition from that stage. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The test target checks the CHAP response that the HBA returns. The logon response PDU indicates that the authentication was successful. If mutual CHAP is tested, this packet also includes the computed CHAP response. This packet does not set the T (transit) bit, and therefore, the HBA must send another packet requesting transition to the next stage. Expect: The logon request PDU sent by the HBA must set the current stage (CSG) field of the PDU to 0x00.

401 The final login request of the security stage must set the Transit bit in the PDU.
Test Assertion GUID: ef761119-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that an HBA indicates it is ready to proceed to another stage after security negotiation has been completed. This condition is checked in both one-way and mutual CHAP. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The test target checks the CHAP response returned by the HBA. The logon response PDU indicates that authentication was successful. If mutual CHAP is tested, this packet also includes the computed CHAP response. This packet does not set the T (transit) bit, and, therefore, the HBA must send another packet requesting transition to the next stage. Expect: The HBA returns a logon request PDU with the T (transit) bit set to 1.

402 The final login request of the security stage must specify a valid next stage.
Test Assertion GUID: ef76111a-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that an HBA sets the next stage field of the iSCSI logon request PDU to a valid value. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The test target checks the CHAP response returned by the HBA. The logon response PDU indicates that authentication was successful. If mutual CHAP is tested, this packet also includes the computed CHAP response. This packet does not set the T (transit) bit and therefore the HBA must send another packet that requests a transition to the next stage. Expect: The next stage field of the logon request PDU is set to either the operational negotiation stage (0x01) or the full-feature stage (0x03).

403 The final login request of the security stage must not contain a data segment.
Test Assertion GUID: ef76111b-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test verifies that an HBA does not include a data segment in the logon request PDU. Apply: The test initiates a CHAP logon to the test target by using the LoginIScsiTarget routine. The test target checks the CHAP response that is returned by the HBA. The logon response PDU indicates that authentication was successful. If mutual CHAP is tested, this packet also includes the computed CHAP response. This packet does not set the T (transit) bit, and, therefore, the HBA must send another packet that requests a transition to the next stage. Expect: The data segment should not contain any data. The security negotiation has been completed, and, therefore, the HBA and target must transition to the next stage before any more items can be negotiated.

1000 The HBA must connect to the test target.
Test Assertion GUID: ef761105-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test checks that the HBA establishes a connection with the test target. Apply: The test uses the LoginIScsiTarget routine to connect to the test target. Expect: The HBA establishes a TCP/IP connection with the test target.

1001 Connection must remain established during login.
Test Assertion GUID: ef761108-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test checks that the HBA maintains the connection with the test target until the logon process is completed. Apply: The test uses the LoginIScsiTarget routine to connect to the test target. During testing, the test target either returns an error status code in a logon response PDU or returns an invalid CHAP_R response to the initiator during mutual CHAP. Expect: The connection between the HBA and the test target must be maintained until the logon process is terminated by an error status code returned by the test target or an inappropriate response. A failure indicates that the HBA terminated the connection prematurely.

1002 iSCSI Login function must not complete while the HBA is still performing the iSCSI login phase.
Test Assertion GUID: ef761109-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test checks that the HBA driver does not complete the iSCSI logon request from the iSCSI service until the final status of the logon with the test target is completed. Apply: The test uses the LoginIScsiTarget routine to connect to the test target. Expect: The iSCSI logon request sent by the iSCSI service to the target must succeed after the logon process is terminated or the logon process succeeds. A failure indicates that control was returned to the service while the logon process was not yet terminated in error or was successfully completed.

1004 HBA must not send data after target ends login.
Test Assertion GUID: ef761106-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test checks that the HBA does not send any more data to the test target after the test target aborts the logon process. Apply: The test uses the LoginIScsiTarget routine to connect to the test target. The test target, upon completion of CHAP validation, returns an error to terminate the logon. Expect: The HBA honors the error code returned and does not send more data to the target.

1005 HBA must return ISDSC_AUTHENTICATION_FAILURE when the target rejects the CHAP response.
Test Assertion GUID: ef761107-c4c5-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Oneway/Mutual CHAP (HBA) test checks that the HBA driver returns the ISDSC_AUTHENTICATION_FAILURE code to the iSCSI service when an authentication failure occurs. Apply: The test uses the LoginIScsiTarget routine to connect to the test target. The test target either fails the first stage during one-way CHAP or returns an invalid CHAP response during mutual CHAP. Expect: The HBA driver must properly indicate the authentication failure by returning ISDSC_AUTHENTICATION_FAILURE to the service.


iSCSI Boot

Type: Automated Test

Overview

The test verifies that the host-bus adapter (HBA) properly reports the presence of a boot session to the Microsoft iSCSI initiator service.

Details

The iSCSI Boot test follows this algorithm:
  1. Determines the current system boot drive.
  2. Retrieves the currently active iSCSI sessions on the system by using the ISCSI_SessionStaticInfo Windows Management Instrumentation (WMI) class.
  3. For every active iSCSI session found, it does the following:
    • Checks the Type field of the session class to determine if it is a boot session
    • If the iSCSI session is a boot session, the test determines the drive letter associated with that session.
    • If the associated drive letter matches the system boot drive letter, the system boots from the iSCSI device.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • iSCSI disk storage system or iSCSI bridge with disk storage system attached

Running iSCSI Boot

Install OS on a target disk device
Run the test as a DTM job from device console
Fill the required data in the configuration UI that pops up when this job is scheduled

Command Syntax

Command option | Description
iscsi_boot_test |

Cautions

Troubleshooting

  1. Look at the job results log file for test failures
  2. Check if the target has a drive letter
  3. Verify the data entered in the configuration dialog (Popup Dialog box when the job is scheduled from device console)

Reference Documentation

Code Tour

File Manifest

File | Location
iscsi_boot_test.exe | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\iscsi

Click to show or hide information. Test Assertions

Test Assertions

1.1 At least one iSCSI session must be active on this system.
Test Assertion GUID: f1283af2-c428-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Boot test validates that at least one active iSCSI session has been established on the system. Expect: One or more active iSCSI sessions on the system.

1.2 There must be one and only one iSCSI session with the boot flag set and the system must be booted from this session.
Test Assertion GUID: f1283af3-c428-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Test: The iSCSI Boot test validates that only one active iSCSI session has the boot flag set Expect: Only one active iSCSI session has the boot flag set Test: The iSCSI Boot test validates that the system was booted through the volume associated with the iSCSI session marked as bootable. Expect: The system was booted through the volume associated with the iSCSI session marked as bootable


UDF Formatter Tests

Type: Manual Test

Overview

The UDF Formatter Tests are used to verify that a device can format all of its supported media types as a UDF volume.

Details

The UDF Formatter tests will format a volume multiple times, each time with different arguments. All applicable UDF revisions shall be attempted and both the command-line interface as well as the FMIFS interface are tested.
Run Time:
Log File: Can be specified with the /log command line parameter
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running UDF Formatter Tests

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Int 13h Extensions test

Type: Manual Test

Overview

The Int 13h Extensions test verifies proper implementation of the Phoenix Int 13h extensions.

Details

The Phoenix Int 13h Extensions allow the BIOS to access disks by using a 64-bit logical block address (LBA), rather than the cylinder, head, and sector addressing scheme. This allows the BIOS to fully utilize very large disks.
The test is based on the Phoenix BIOS Enhanced Disk Drive Specification, version 1.1. The specification defines additional Int 13h functions and their implementation.

The tool must run in a tree on the test system that looks like this:

└─── ExtInt13Test (folder)

 │ ExtInt13Wrap.exe

│ image.exe

│ int13bt.im

│

└─── ExtInt13DosBin (folder)

 AUTOEXEC.BAT

CHOICE.COM

CONFIG.SYS

DISPLAY.SYS

DOSKEY.COM

EDIT.COM

EGA.CPI

EGA2.CPI

EGA3.CPI

EXTINT13.EXE

JFIND16.EXE

KEYB.COM

KEYBOARD.SYS

KEYBRD2.SYS

KEYBRD3.SYS

KEYBRD4.SYS

MODE.COM

NTLOG.DLL

REBOOT.COM

SETRAMD.BAT

TEST.BAT
How the test works:
  • User runs ExtInt13Wrap (from command line or by scheduling ExtInt13 Test DTM job)
  • User is prompted to:
    • Insert a floppy disk into drive A (x86 operating system) or
    • Insert a bootable floppy disk into drive A (x64 operating system)
  • After ExtInt13Wrap copies test binaries to the floppy disk, it reboots the computer in DOS mode using the bootable floppy disk.
  • ExtInt13.exe runs. (This is the Int 13h Extensions Test.)
  • After the test runs, user is prompted to press any key to reboot the computer.
  • User must remove the floppy disk from drive A during reboot.
  • After computer reboots in Windows, ExtInt13Wrap.exe runs automatically.
  • During the second run, ExtInt13Wrap.exe reads and parses the ExtInt13.exe log.

Run Time: 30 Minutes
Log File:
System Restart Required: Yes
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Windows 2000
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Test system with maximum 2 GB of RAM and a floppy disk drive

Running Int 13h Extensions test

  • Install "ExtInt13 Test"
  • Run "ExtInt13 Test" DTM job.

Command Syntax

Command option | Description
ExtInt13Wrap.exe /RunAsWttTask | Only used when the test is going to be run as a DTM Job using DTM. DTM will be responsible for running ExtInt13Wrap.exe again after the system reboots back into Windows. DO NOT use this variation unless the test is launched using DTM.
ExtInt13Wrap.exe | Used when the test going to be run from a command line. ExtInt13Wrap.exe will add itself into RUN registry key so it will be launched again after the reboot to read log file.

Cautions

Troubleshooting

Reference Documentation

http://www.phoenix.com/NR/rdonlyres/9BEDED98-6B3F-4DAC-BBB7-FA89FA5C30F0/0/specsedd11.pdf

Code Tour

File Manifest

File | Location
ExtInt13Wrap.exe | storage\wdk\ExtInt13Test
image.exe | storage\wdk\ExtInt13Test
INT13BT.IM | storage\wdk\ExtInt13Test
EXTINT13.EXE | storage\wdk\ExtInt13Test\ExtInt13DosBin
AUTOEXEC.BAT | storage\wdk\ExtInt13Test\ExtInt13DosBin
CHOICE.COM | storage\wdk\ExtInt13Test\ExtInt13DosBin
CONFIG.SYS | storage\wdk\ExtInt13Test\ExtInt13DosBin
DISPLAY.SYS | storage\wdk\ExtInt13Test\ExtInt13DosBin
DOSKEY.COM | storage\wdk\ExtInt13Test\ExtInt13DosBin
EDIT.COM | storage\wdk\ExtInt13Test\ExtInt13DosBin
EGA.CPI | storage\wdk\ExtInt13Test\ExtInt13DosBin
EGA2.CPI | storage\wdk\ExtInt13Test\ExtInt13DosBin
EGA3.CPI | storage\wdk\ExtInt13Test\ExtInt13DosBin
JFIND16.EXE | storage\wdk\ExtInt13Test\ExtInt13DosBin
KEYB.COM | storage\wdk\ExtInt13Test\ExtInt13DosBin
KEYBOARD.SYS | storage\wdk\ExtInt13Test\ExtInt13DosBin
KEYBRD2.SYS | storage\wdk\ExtInt13Test\ExtInt13DosBin
KEYBRD3.SYS | storage\wdk\ExtInt13Test\ExtInt13DosBin
KEYBRD4.SYS | storage\wdk\ExtInt13Test\ExtInt13DosBin
MODE.COM | storage\wdk\ExtInt13Test\ExtInt13DosBin
NTLOG.DLL | storage\wdk\ExtInt13Test\ExtInt13DosBin
REBOOT.COM | storage\wdk\ExtInt13Test\ExtInt13DosBin
SETRAMD.BAT | storage\wdk\ExtInt13Test\ExtInt13DosBin
TEST.BAT | storage\wdk\ExtInt13Test\ExtInt13DosBin

Click to show or hide information. Test Assertions

Test Assertions

ExtInt13 Storage controller must properly implement Phoenix Int 13h Extensions.
Test Assertion GUID: efeab1b6-8ab9-4e7d-b7cd-0d8396d8efb1

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: Please see Phoenix BIOS Enhanced Disk Drive Specification, version 1.1.

ExtInt13 System must properly implement Phoenix Int 13h Extensions.
Test Assertion GUID: Phoenix BIOS Enhanced Disk Drive Specification, version 1.1

Windows Logo Program: DEVFUND-0015 Software-initiated device-installs use Plug and Play APIs to install device drivers

Additional Information:


iSCSI Digest - Disk (HBA)

Type: Automated Test

Overview

This test verifies that the host-bus adapter (HBA) supports header and data digests as negotiated during the logon phase.

Details

The iSCSI Digest - Disk (HBA) test follows this algorithm:
  1. Prepares the system for iSCSI operations
    • If the target used for testing is already logged on, the session information is saved so the session can be restored later.
    • The target disk device is added as a static iSCSI target.
  2. Performs iSCSI operations
    • If the target used for testing is already logged on, the current session to the target is logged out.
    • The target is logged on using the HBA under test with header digests enabled.
    • After logging on to the target, the test waits for all disk devices to be enumerated on the test system.
    • The test will perform I/O read and write operations with the current target session.
    • The test repeats the above steps with data digests only enabled and header and data digests enabled.
    • The HBA under test must properly logon using all three digest combinations with no I/O failures detected during I/O operations.
  3. Restores any previous iSCSI target sessions.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • iSCSI disk storage system or iSCSI bridge with disk storage system attached

Running iSCSI Digest - Disk (HBA)

Logon to the disk target and format the drive. The disk target should have a drive letter before running the test
Run the test as DTM job from device console
Fill the required data in the configuration UI that pops up when this job is scheduled

Command Syntax

Command option | Description
iscsi_digest -hct -l disk -a -c hba |

Cautions

Troubleshooting

  1. Look at the job results log file for test failures
  2. Verify the target has been formatted and assigned a drive letter.
  3. Verify the iSCSI configuration information is entered correctly in the configuration dialog (Popup Dialog box when the job is scheduled from device console)

Reference Documentation

Code Tour

File Manifest

File | Location
iscsi_digest.exe | …\tests\%ARCHITECTURE%\nttest\driverstest\storage\wdk\iscsi

Click to show or hide information. Test Assertions

Test Assertions

1.1 Setting up test, and saving open sessions.
Test Assertion GUID: 0df19e9d-c42e-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: The setup stage is responsible for getting the current sessions to the target and then persistenting that information so it can be used to reestablish these sessions during the cleanup stage.

2.1 The HBA must be able to log into the target successfully with digests enabled.
Test Assertion GUID: 7f102024-c42e-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

3.1 The HBA must successfully logout from target.
Test Assertion GUID: 7f102026-c42e-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information:

4.1 Cleaning up test, restoring sessions.
Test Assertion GUID: 7f102028-c42e-11da-94f4-00123f3a6b60

Windows Logo Program: STORAGE-0005 FUTURE (June 1, 2007 for Mobile systems): Hybrid Disk Drives support industry standards and Windows requirements

Additional Information: The cleanup stage is responsible for restoring the sessions that were persisted during the setup stage.


Streaming Media and Broadcast Testing

This section describes how to test display devices in order to qualify them for the "Designed for Windows" logo.

DVD Decoder

Broadcast Receiver


DVD Playback Testing Overview

The procedures presented in this section outline the process for testing your DVD Playback for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as requried for the device. If your product provides bus-specific support, you must run the

DVD Playback Tests

The list of test you need to run depend upon the capabilities of the device or system being tested. To see the complete list of tests that could be required for your device, see the DVD Playback Tests.

Run time: approximately <TBD> hours

Hardware requirements

The following hardware is required for DVD Playback testing. Additional hardware may be required if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

  • Test DVD software or hardware decoder solution

    • or –

    Test Moving Picture Expert Group-2 (MPEG-2) software or hardware decoder solution

  • One computer with the following:
    • x86, Itanium-2-based, or x64 processor with a minimum speed of 450 MHz
    • x86, Itanium-2-based, or x64 processor with a minimum speed of 450 MHz
    • AGP or PCI display adapter

  • 17-inch monitor with minimum 1024x768x24 bpp resolution
  • One display adapter/driver combination
  • One keyboard
  • One mouse (or any pointing or drawing device)
  • One IDE hard disk drive with a 4 GB capacity (minimum), and PIO-4 or DMA capability
  • One DVD-ROM drive
  • One audio adapter

Software requirements

The following software is required to run the DVD Playback tests:

  • One of the following operating systems:
    • Microsoft Windows XP Professional with Service Pack 2 (SP2)
    • Microsoft Windows Server 2003, Standard Edition, with Service Pack 1 (SP1)
    • Microsoft Windows Server 2003, Enterprise Edition, with SP1
    • Microsoft Windows XP Professional x64 Edition
    • Microsoft Windows Server 2003, Standard x64 Edition
    • Microsoft Windows Server 2003, Enterprise x64 Edition
    • Microsoft Windows Server 2003, Enterprise Edition with SP1 for Itanium-based Systems

  • Any drivers that are not shipped with the operating system
  • The current release of the WDK on DVD
  • WHQL DVD Test Annex 3.0

You can order this DVD from [image] Windows Hardware Compatibility Test Kits

Tester knowledge requirements

To run the DVD Playback tests, testers must know how to accomplish the following tasks:

To run the Windows WDK for DVD Playback, testers must know how to accomplish the following tasks:

  • Install the DVD playback decoder solution hardware or software
  • Install the manufacturer-supplied device driver, if necessary
  • Install the operating system from the product DVD
  • Install the Windows WDK

Development resources

Microsoft DirectX Software Development Kit (SDK) application programming interface and software


Preparing for DVD Playback Testing

Before running the tests, you must configure the system and install the operating system. This section summarizes the related procedures.

For a complete list of required hardware, software, and tester knowledge, see the DVD Playback Testing Overview.

Many of the tests in the Windows Driver Kit require a test system to restart (often more than once) to complete a test run. The test description and the running instructions specify whether a test requires a system restart. Although these tests programmatically restart the test system, you must manually log on to the test system after each system restart so that the test run can resume. You can avoid this requirement by enabling autologon functionality on the test system. For more information about autologon, see Running with autologon enabled.

Test system configuration

To configure the test system for DVD Playback testing

  1. Install the appropriate Microsoft Windows operating system from the product DVD on the test system.
  2. Install the hardware or software solution on the test system.
  3. Install the manufacturer-supplied device driver, if necessary, on the test system.
  4. If appropriate, enable autologon functionality.
  5. Install the HCT kit on the test system.


Running the DVD Playback Tests

List of Jobs that should show up:

Name:Copy Binaries for DVD Annex Tests

Name:DVD Annex - NTSC Playback Test

Name:DXVA2 Decoder Test

Name:DVD Annex - PAL Playback Test

Name:DVD Annex - Audio Test (Manual)

Name:DVD Annex - Decode Test (Manual)

Name:DVD Annex - Graphics Test

Name:DVD Annex - Sequence Test (Manual)

Name:DVD Annex - Subpicture Test

Name:DVD Annex - Video Automated Test

Name:DVD Annex - Video Format Test

Name:DVD Annex - Video Manual Test (Manual)

Name:MPEG-2 Decoder Test - WHQL Check Test


Broadcast Receiver Testing Overview

The procedures presented in this section outline the process for testing your Broadcast Receiver for proper functionality with the Microsoft Windows operating system. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as required for the device. If your product provides bus-specific support, you must run the appropriate bus-specific tests in addition to the standard tests.

What Is a Broadcast Receiver?

Broadcast Receivers are TV tuner cards. This includes both analog receives, digital receivers, and combo/hybrid cards.

Analog Broadcast Receivers covered in this test kit include:

NTSC, PAL, SECAM

Digital Broadcast Receivers covered in this test kit include:

DVB-T, ATSC

Hybrid tuner cards fall into both categories. Both sides must be logo’ed (How?)

Standard vs. Premium Programs

There are two levels of testing, standard and premium. The standard program tests just the most basic functionality of the tuner card. The premium program tests more specific capability and performance requirements to ensure Media Center works well with the card.

A premium logo is required for qualifying the card to work with Media Center.

Program Contents

The Broadcast Receiver Program tests some common programs in addition to specific tune card tests. The entire suite of programs must be run to pass the logo.

The categories included in the Broadcast Receiver Program are:

Driver Reliability Signature Tests

Bus Tests (as appropriate)

PCI Bus Tests

USB Bus Tests

CardBus Tests

1394 Bus Tests

Codec Tests- see ‘Codec API Tests’

http://windows/sites/ldk/LDKContent/LDKToolDocumentationDepot/F431C363-9432-4D7F-BA09-FABBB7E61690.xml

Standard Tuner Tests-see ‘TVWLPTest : ehome - Standard Tuner Tests’

http://windows/sites/ldk/LDKContent/LDKToolDocumentationDepot/3E6AFC3D-9FFB-4A1F-B37D-33226DED31F3.xml

Premium Tuner Tests-see ‘TVWLPTest ehome - Premium Tuner Tests’

http://windows/sites/ldk/LDKContent/LDKToolDocumentationDepot/651CDBED-343B-4E89-BFA7-D1040C1195D5.xml

Broadcast Receiver Tests

The list of test you need to run depend upon the capabilities of the device or system being tested. To see the complete list of tests that could be required for your device, see the Broadcast Receiver Tests

Run time: approximately 15 minutes including the manual steps.

Hardware requirements

The following hardware is required for Broadcast Receiver testing. Additional hardware may be required if the test device provides bus-specific support. See the test description for each bus-specific test to determine if there are additional hardware requirements.

A DTM server, controller, and test machine are required to run long the tests. It is highly recommended that these are separate machines. See the general DTM instructions for how to configure these.

The most important piece of hardware is the Broadcast Receiver (tuner) card to be tested. Install one or more on the test machine.

The test machine must also include a reasonable quality display card to verify the functioning of the receiver card.

The next main requirement for testing is multiple sources of broadcast TV input. Since as many input forms are tested as the card supports, all forms (RF, composite, S-Video, and FM radio) should be available, for whatever broadcast format (NTSC, PAL, SECAM, DVB-T, ATSC) the card supports.

For analog tuner cards, an external DVD or VCR player with a switch-able composite/RF and S-Video output is pretty much required to create composite and S-Video signals on demand, in particular ones with protected signals. A multi-standard VCR or DVD player is recommended if your card supports multiple input types.

Some source of protected content is required. The Microsoft Windows DVD Test Annex, Version 3.0 played on the DVD player is one alternative, although many commercially available movies are also protected as well as some broadcast data streams.

Some set-top boxes on cable feeds with constant protected channels may also work.

Software requirements

Other than the WDK, the Microsoft Mpeg2 Decoder provided with Vista, and your drivers, there is no other software required to run the Broadcast Receiver tests. Another Mpeg2 decode may be registered rather than the Microsoft one, but the Microsoft one must be used in a true premium logo path.

Tester knowledge requirements

To run the Broadcast Receiver tests, testers must know how to accomplish the following tasks:

  • Testers must be familiar with the DTM.
  • Testers must be able to provide the required video input streams to their capture cards. This not only includes the various flavors of RF the capture card is able to handle, but also Svideo, Composite, and FM the card may also handle.
  • An ability to read English to follow manual prompts or the output logs, is required.


Preparing for Broadcast Receiver Testing

Before running the broadcast receiver tests on a test system or systems, you must install and configure the system hardware, choose the target Windows operating system and install and configure the Device Test Manager (DTM). This section summarizes the broadcast receiver related requirements and procedures. For information about installing and configuring the DTM, see Driver Test Manager .

For a complete list of required hardware, software, and tester knowledge, see the Broadcast Receiver Testing Overview above.

Test system configuration

This documentation assumes you have already set up your DTM test environment. We’ll assume you have at installed at least 3 machines: a DTM server with the WDK installed on it, a controller to run the test with the DTM ‘Studio’ installed on it, and one or more test machines which we’ll want to install the DTM ‘Client’ on in Step 3 below. Each client machine must have a monitor and keyboard on it (perhaps though a switch box) to interact with manual tests, as well as the target Windows operating system.

To setup your test configuration, :

  1. RF, S-Video, Composite, and FM signals appropriate to the broadcast receiver cards being tested should be provided to all test machines, and access to a DVD or VCR player should be available, and a source of protected content provided.
  2. Install the broadcast receiver cards you are attempting to logo on the client machines. Access to the card’s video inputs and outputs should be easily available, since you will need to switch cables during the tests.
  3. Install the DTM client software on each test machine.


Running the Broadcast Receiver Tests

This section discusses how to logo your broadcast receiver card. It assumes you have already set up working DTM system with at least one client machine with a broadcast receiver installed on it.

To logo your broadcast receiver card, perform the following steps:

  1. If you have not already done so,
    • Install a full version of the DTM on a server machine.
    • Install the target windows operating system each test machine
    • Install the broadcast receiver hardware in each test machine
    • Install the DTM client on each test machine
    • For more information, see: Driver Test Manager

  2. Start up the DTM Studio on the controller machine.
  3. Open the job monitor (Explorers->Job Monitor).
  4. If you haven’t already done it, create a machine pool to be used for the submission
    • Right click on the machine pool root (defaults to ‘$’) and select ‘Add Machine Pool
    • Give the machine pool a name.(e.g. ‘Mine’).
    • Click ‘Apply’.
    • Repeat as necessary for as many test machines you want to add to this pool.

  5. Click on the machine pool you want to run the tests on
  6. un the Gathers (and run first jobs if still required)
    • After selecting the machine pool, right click on ‘schedule
    • Add System->Gatherer/EHome_Block
    • Run these jobs

  7. Open the Device Console (Select ‘Explorers->Device Console’) and click ‘Submission’ to start the submission wizard.
    • Select one or more Tuners in the machine pool you wish to logo
      • Tuners are under the ‘Sound, video, and game controllers’ device list., and usually labeled ‘xxx Tuner yyy’ or ‘xxx Unified Driver
      • Note you must select an actual tuner device unless it’s a unified driver. Related devices on the same card such as the cross bar or video capture will yield wrong results.
      • You’ll know you selected the right type if TVTuner category is listed in the set of available jobs.

    • Select the logo level (standard or premium).
      Note that the premium logo level is required for Media Center
    • Select ‘Scheduled Jobs’

  8. Follow the steps presented to you in the Submission Wizard, once done a set of jobs will be presented.
  9. Select the main job tree to run all the jobs listed or choose the jobs individually then click on the add selected button.
  10. At this time the jobs that are presented in the bottom pane are the result of the schedulers reviewing the end users answers given in the submission wizard, devices listed in the inf, devices actually in the machine pool, and attributes of the jobs themselves
  11. You should see the results starting to run on the client machines
    • Wait X-Y min for the DRS and Bus tests to run

  12. On the client machines, follow the prompts on the screen asking you to select among the various input media types
    • For more details on tests run during a premium logo pass, see
      • Ehome – Premium Tuner Tests

    • For more details on the tests run during a standard logo pass, see:
      • Ehome - Standard Tuner Tests

  13. Use the Job Monitor on the controller machine to track the progress of jobs as they are executed.
  14. When testing is complete click on the status button in device console and review the information provided correct any issues identified.
  15. After verifying the status information select and right click on the summary icon in the available devices pane of device console and choose create submission package.

To simply run individual jobs in the logo program for debugging:

  1. Start up the DTM Studio
  2. Start up the Device Explorer (Explorers -> Device Explorer)
  3. In the right panel, select just the jobs you want to run.

Use the Job Monitor to track the progress of jobs as they are executed.

Use the Result Explorer to examine the results of jobs that have completed.

Driver Reliability Signature Program

If you are submitting a driver with your device submission, you must also run the Driver Reliability (DRS) tests and tools. For more information, see Driver Reliability Tools and Tests.


Troubleshooting Broadcast Receiver Testing

The tuner jobs run in this program test multiple logo requirements in sequence. Although this makes the logo run efficient, debugging becomes more difficult. For this reason, the individual requirements may be run individually by invoking the main test program through the DTM. To do this:

  1. In DTM in the Job monitor, Schedule a new job
  2. Enter the device ID under ‘WDKDeviceID’. The value here is the full device ID.
    1. An example is:
      PCI\VEN_1002&DEV_4D52&SUBSYS_A3461002&REV_00\4&12699180&0&3848

  3. As the value for ‘Test Suite’, instead of Premium or Standard, enter the requirement ID you want to run.
    1. An example would be Stream-0011 or Graphics-0001.
    2. See below for table of full

  4. Start the test, and perform any manual steps as needed.
  5. Examine the log file (TVWLPTest.xml) for detail on the pass.

Requirements that may be tested this way are:

ID | Type | Requirement Name
GRAPHICS-0001 | Display Tests | Display adapter supports TV-out connector with content protection features
GRAPHICS-0043 | Display Tests | Display driver supports minimum display timings and modes where applicable
GRAPHICS-0055 | Display Tests | Display subsystem supports digital television (EIA/CEA-861B) resolutions and timings over digital interfaces
STREAM-0010 | Tuner Tests | Premium TV tuner supports both audio and video capture
STREAM-0011 | Tuner Tests | Tuner driver uniquely identifies the tuner and its mediums
STREAM-0012 | Tuner Tests | TV tuner supports automatic rendering
STREAM-0013 | Tuner Tests | TV tuner exposes only required pins
STREAM-0014 | Tuner Tests | Resources are not acquired until the Device Acquire state
STREAM-0015 | Tuner Tests | TV tuner properly signals channel changes
STREAM-0016 | Tuner Tests | TV tuner detects signals from all input sources
STREAM-0017 | Tuner Tests | USB TV tuner has a unique serial number
STREAM-0021 | Tuner Tests | Digital TV tuner uses the Broadcast Driver Architecture (BDA)
STREAM-0024 | Tuner Tests | Analog TV tuner implements stereo audio decoding for its intended broadcast region
STREAM-0025 | Tuner Tests | Digital TV tuner provides signal quality and other diagnostic information
STREAM-0028 | Tuner Tests | Analog TV tuner supports content protection
STREAM-0029 | Tuner Tests | Analog TV tuner that relies on host processing of VBI meets minimum requirements
STREAM-0030 | Tuner Tests | Dual-tuners implementations support additional requirements
STREAM-0056 | Tuner Tests | Exhaustive Scanning APIs supported
STREAM-0057 | Tuner Tests | TV tuner capture card supports automated capture graph building with Media Center video control
SYSFUND-0043 | System Tests | Systems implement a minimum of 2 user-accessible, fully powered USB 2.0 ports for desktop systems and 1 for mobile systems
SYSFUND-0064 | System Tests | System that ships a tuner enables DMA
SYSFUND-0065 | System Tests | System that includes multiple TV tuners meets performance and quality requirements during record and playback scenarios


Streaming Media Tests

Test name Target operating system Test description
DVD Annex - Video Manual Test Windows XP
The DVD Annex - Video Manual test includes the following test cases, which are designed to verify that the DVD content can match various playback scenarios and match user experience expectations. Results are evaluated manually. User interaction is required.
  • Pan and Scan
  • Film
  • Video
  • Variations/Speed
  • Variations/Discontinuity
  • Variations/Mixed Mode
  • Chapter Breaks
DVD Annex - Graphics Test Windows XP
The DVD Annex - Graphics & Menu Support test examines DVD drive performance for consistent implementation of freeze frame.
The DVD Annex - Graphics & Menu Support test includes the following test cases:
  • Motion Menu – Menu that Ends
  • Motion Menu – Menu that Loops
  • Field/Frame Freeze Weave
  • Field Freeze Bob
TVWLPTest : ehome - standard tuner tests Windows Vista
This document describes the Vista requirements tested in the 'ehome - standard tuner tests' job. These tests are all invoked by a program called TVWLPTest and up to four DShow filters it invokes.
This job verifies that system is capable of supporting standard TV tuner functionality. Tests STREAM-0011, STREAM-0012, STREAM-0014, STREAM-0021, STREAM-0025, STREAM-0028, STREAM-0029, STREAM-0056, STREAM-0057
DVD Annex - Subpicture Test Windows XP
The DVD Annex - Subpicture test suite verifies the functional specifications for the menu overlay subsystem, including:
  • Running the Subpicture Palette (DCS) test - Tests a range of subpicture palette assignment values.
  • Default Palette Color Index test - Tests three index values on a menu using the default DVD-Video palette.
  • Running the Default Palette Color Index test - Tests three index values on a menu using a custom color palette.
DVD Annex - Sequence Test Windows XP
The DVD Annex - Sequence/Branching test suite includes the following tests:
  • Seamless Multi-Angle
  • Non-seamless Branching
TVWLPTest : ehome - premium tuner tests Windows Vista
This document describes the Vista requirements tested in the 'ehome - premium tuner tests' job. These tests are all enacted by a program called TVWLPTest and up to four DShow filters it invokes.
This job verifies that system is capable of supporting premium Media Center TV tuner functionality. Tests STREAM-0010, STREAM-0011, STREAM-0012, STREAM-0013, STREAM-0014, STREAM-0015, STREAM-0016, STREAM-0017, STREAM-0021, STREAM-0024, STREAM-0025, STREAM-0028, STREAM-0029, STREAM-0056, STREAM-0057
DVD Annex - Decode Test Windows XP
The DVD Annex - Decode test includes test cases that verify the following DVD decode related functionality:
  • Numbers
  • X Parade
  • Title Roll
  • Clock 24 fps and the Clock 60 Hz
  • 24fps Film
  • 60 Hz Video
  • 4Mb and 6Mb
  • 7.95 Mb
  • Highest
  • Low Bit Rate
  • Cycling Bit Rate
  • V-bench
  • Half Horizontal
TVWLPTest - ehome - premium system tests Windows Vista
         This document describes the Vista requirements tested in the 'ehome - premium system tests' job. These tests are all invoked by a program called TVWLPTest and up to four DShow filters it may load.
Verifies that system is capable of supporting premium media center functionality. Tests SYSFUND-0043, and SYSFUND-0064
AV/C Tape Subunit Compliance Test Windows Vista
Windows XP
MSTapeTst is the automated test app for IEEE 1394 AV/C (Audio/Video Control) protocol Video Capture.
Pressure Streaming Device test Windows Vista
Test for Streaming device and driver implementation.
Some test cases check for correct error handling by devices and their drivers.
Incorrect handling of these cases may result in a system hang or crash.
DVD Annex - Video Automated Test Windows XP
The DVD Annex - Video Automated test includes the following test cases, which are designed to verify that the DVD content can match various playback scenarios and match user experience expectations. Results are evaluated automatically. No user interaction is required.
  • Excessive Cropping
  • Aspect Ratio
  • Forced Letterbox
DVD Annex - PAL Playback Test Windows XP
This test verifies that DirectShow application programming interface (API) handling is correct for PAL and that quality is maintained during DVD playback.
Audio or Video Capture and Control (Blink) Windows Vista
Windows XP
Blink is a test for multimedia Video Capture devices.
DVD Annex - Audio Test Windows Vista
The DVD Annex - Audio test suite includes tests for these formats:
  • Running the MPEG-1 Layer 2 test
  • Running the 48 kHz PCM test
  • Running the Dolby Digital test
  • Running the 96-kHz PCM test - Required DVD-Video audio format.
Codec API Test Windows Vista
         Unitest for ICodecAPI implementation.
DVD Annex - NTSC Playback Test Windows XP
This test verifies that DirectShow application programming interface (API) handling is correct and that quality is maintained during DVD playback. It also includes a test case for Line 21 Closed Caption handling.


DVD Annex - Video Manual Test

Overview

The DVD Annex - Video Manual test includes the following test cases, which are designed to verify that the DVD content can match various playback scenarios and match user experience expectations. Results are evaluated manually. User interaction is required.
  • Pan and Scan
  • Film
  • Video
  • Variations/Speed
  • Variations/Discontinuity
  • Variations/Mixed Mode
  • Chapter Breaks

Details

Good scaling distinguishes home theater products from mainstream consumer electronics components. Of the many aspects of scaling performance, several depend heavily on the particulars of the content presented. The encoded picture structure (progressive or interlaced) plays a major role on scaling performance.
The DVD Annex - Video test uses the DVD Test Annex 3.0 disc. This DVD disc includes a variety of test samples to help isolate and test the various issues. To address the issue of variations in commercially encoded film-mode MPEG-2 syntax, the DVD Test Annex disc also includes several samples covering a range of laboratory practices and content types.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running DVD Annex - Video Manual Test

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

DVD playback and MPEG 2 decode is Forced Letterbox - Full Screen compliant.
Test Assertion GUID: 5CC49E1A-902A-40dd-A73B-9F8358ABB379

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

DVD playback and MPEG 2 decode is Film - Basic (USER) compliant
Test Assertion GUID: F5A10ACD-EF07-4d6f-ADCA-977B00F69FB9

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

DVD playback and MPEG 2 decode is Film - Alternate (USER) compliant
Test Assertion GUID: E855FD59-F87E-437c-B442-840BB91F2298

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

DVD playback and MPEG 2 decode is Video (USER) compliant
Test Assertion GUID: 9B9B43BE-B67D-446e-94B4-30C1CACB78EE

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

DVD playback and MPEG 2 decode is Variations: Speed (USER) compliant
Test Assertion GUID: 89AC079B-46C0-4587-BFAE-F20AA1491B75

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

DVD playback and MPEG 2 decode is Mixed Mode: Basic Y (USER) compliant.
Test Assertion GUID: 5BB35F4E-D454-4419-B8DC-B60B861D3F1E

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

DVD playback and MPEG 2 decode is Mixed Mode: Alternate X (USER) compliant
Test Assertion GUID: 9605843A-F59F-4c9b-BE8F-F57E1E19FD95

Windows Logo Program:

Additional Information:

DVD playback and MPEG 2 decode is Chapter Break: Alternate 1 (USER) compliant
Test Assertion GUID: 54B0928B-DFEE-47bc-AF30-039FEFCB97E0

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:


DVD Annex - Graphics Test

Overview

The DVD Annex - Graphics & Menu Support test examines DVD drive performance for consistent implementation of freeze frame.
The DVD Annex - Graphics & Menu Support test includes the following test cases:
  • Motion Menu – Menu that Ends
  • Motion Menu – Menu that Loops
  • Field/Frame Freeze Weave
  • Field Freeze Bob

Details

N/A

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running DVD Annex - Graphics Test

Command Syntax

Command option | Description
DVDAnnex.exe graphics | Launches the test application.

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

6.19.17 DVD playback and MPEG 2 decode is Menu That Ends (AUTO) compliant.
Test Assertion GUID: CFF3E014-0030-4090-B2C1-84C6186F617E

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

6.19.18 DVD playback and MPEG 2 decode is Menu That Loops Short (AUTO) compliant.
Test Assertion GUID: BECB7344-5A2A-402f-90EE-AD53115FB557

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

6.19.19 DVD playback and MPEG 2 decode is Field/Frame Freeze - Bob (AUTO) compliant.
Test Assertion GUID: E225BEB6-F912-496a-9342-59F8B0D1168F

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

6.19.20 DVD playback and MPEG 2 decode is Field/Frame Freeze - Weave (AUTO) compliant.
Test Assertion GUID: E618D287-DF4E-4f7a-BC96-6879468B8F14

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

6.19.21 DVD playback and MPEG 2 decode is 16x9 Menu (AUTO) compliant.
Test Assertion GUID: C0D4FB01-FD85-44ca-B809-E6DDA8950B92

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:


TVWLPTest : ehome - standard tuner tests

Type: Automated Test

Overview

This document describes the Vista requirements tested in the 'ehome - standard tuner tests' job. These tests are all invoked by a program called TVWLPTest and up to four DShow filters it invokes.
This job verifies that system is capable of supporting standard TV tuner functionality. Tests STREAM-0011, STREAM-0012, STREAM-0014, STREAM-0021, STREAM-0025, STREAM-0028, STREAM-0029, STREAM-0056, STREAM-0057

Details

See 'ehome - premium tuner tests' for more details, but restrict to just the jobs listed above.
Run Time: 2-3 min
Log File: TVWLPTest.xml
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Input Video sources per supported broadcast type (PAL, SEACAM, NTSC, ATSC, DVB-T, ...) and format (RF, FM, and Composite, SVideo)

Running TVWLPTest : ehome - standard tuner tests

1) Install the video capture cards on the machine or connect via USB
2) Run the 3 RunMeFirst jobs.
3) Connect a valid RF signal to the card of the appropriate broadcast format (NSTC, SECAM, ATSC, …)
4) Run the job
- this will iterate through the requirements listed above
5) Provide video input sources as requested.

Command Syntax

Command option | Description
tvwlptest <test case ID> “<Device ID of device you want to test>” |

Cautions

Expect a reasonable quality video / FM connections to the machine. Poor quality video feed may impact tests.

Troubleshooting

If the jobs are too big and hence difficult to debug, run the individual requirement through the DTM as manually scheduled job using the WDKDeviceID parameter and the requirement name (e.g. STREAM-0011) and PnP-ID (50+ character name) as described above in the Alternate Installation Steps.
None known.

Code Tour

File Manifest

File | Location
TVWLPTest.exe |
TVWLPAudioMonitor.ax |
TVWLPSourceFilter.ax |
TVWLPMPeg2Monitor.ax |
TVWLPVBIMonitor.ax |

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


DVD Annex - Subpicture Test

Overview

The DVD Annex - Subpicture test suite verifies the functional specifications for the menu overlay subsystem, including:
  • Running the Subpicture Palette (DCS) test - Tests a range of subpicture palette assignment values.
  • Default Palette Color Index test - Tests three index values on a menu using the default DVD-Video palette.
  • Running the Default Palette Color Index test - Tests three index values on a menu using a custom color palette.

Details

N/A

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running DVD Annex - Subpicture Test

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

6.19.7 DVD playback and MPEG 2 decode is Blue Transparency: 100% compliant.
Test Assertion GUID: E39B17FF-5700-4690-8461-50F39F3C3091

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

6.19.8 DVD playback and MPEG 2 decode is Blue Transparency: 20% compliant.
Test Assertion GUID: 252ED3C1-D283-4269-BFE1-CC6E6914A7E4

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

6.19.9 DVD playback and MPEG 2 decode is Index 1 Selection Colors compliant.
Test Assertion GUID: CB755C60-9D3C-4f8f-A3C7-7ECFACF2BA6E

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

6.19.10 DVD playback and MPEG 2 decode is Index 1 Action Colors compliant.
Test Assertion GUID: 75E25DDA-2E6B-47c9-8185-984987CFD4CA

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

6.19.11 DVD playback and MPEG 2 decode is Index 2 Selection Colors compliant.
Test Assertion GUID: AD624432-C92E-4c4f-A886-F27AF6CF8359

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

6.19.12 DVD playback and MPEG 2 decode is Index 2 Action Colors compliant.
Test Assertion GUID: 47E2FDD0-557C-4cad-96C9-B38154426BDC

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:


DVD Annex - Sequence Test

Overview

The DVD Annex - Sequence/Branching test suite includes the following tests:
  • Seamless Multi-Angle
  • Non-seamless Branching

Details

This test suite tests the two methods supported by the DVD-Video standard for user-selectable scenarios for interactive source material. These test sequences address navigation and buffer management subsystems and, to some extent, measure the usable throughput of the device under test.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running DVD Annex - Sequence Test

Command Syntax

Command option | Description
DVDAnnex.exe sequence | Launches the test application for sequence profile.

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

6.19.13 DVD playback and MPEG 2 decode is Seamless Multi-Angle #1 compliant.
Test Assertion GUID: 11922AF1-2B5B-43a4-B165-CC73AC7B1B74

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

6.19.14 DVD playback and MPEG 2 decode is Seamless Multi-Angle #2 compliant.
Test Assertion GUID: 840FBC14-4D3C-44da-B206-5C60EC71869C

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

6.19.15 DVD playback and MPEG 2 decode is Non-Seamless Multi-Angle #1 compliant.
Test Assertion GUID: F0660063-1ADF-455f-8676-B2BEB55A98EA

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

6.19.16 DVD playback and MPEG 2 decode is Non-Seamless Multi-Angle #2 compliant.
Test Assertion GUID: A9287189-8CAA-4191-BA0E-938EDFF2AE97

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:


TVWLPTest : ehome - premium tuner tests

Type: Automated Test

Overview

This document describes the Vista requirements tested in the 'ehome - premium tuner tests' job. These tests are all enacted by a program called TVWLPTest and up to four DShow filters it invokes.
This job verifies that system is capable of supporting premium Media Center TV tuner functionality. Tests STREAM-0010, STREAM-0011, STREAM-0012, STREAM-0013, STREAM-0014, STREAM-0015, STREAM-0016, STREAM-0017, STREAM-0021, STREAM-0024, STREAM-0025, STREAM-0028, STREAM-0029, STREAM-0056, STREAM-0057

Details

There is a single program called TVWLPTest that iterates through all the requirements for this job listed below. Any failures will fail the whole job.
Depending on the number of inputs to the capture card, it takes 5-10 minutes. Most of the tests run in less than 5 seconds, but there is one series of manual step for STREAM-00 for requiring the user to provide all possible
STREAM-0010
Title: Test Tuner Supports both Audio and Video Capture
Success:
This test will succeed if all of the following steps are successful:
  • Build a filter graph with the specified analog Tuner (the graph is not run)
  • Locate the Capture filter associated with the Tuner
  • Locate at least one output pin on the Capture filter that supports MEDIATYPE_Video
  • Locate at least one output pin on the Capture filter that supports MEDIATYPE_Audio.

    Note: It is valid for the Video and Audio to be on the same pin.
Failure:
This test will fail if any of the steps described above fail.
STREAM-0011
Title: Test Tuner Driver Uniquely Identifies Tuner and Its Mediums
Success:
This test will succeed if all the following steps are successful:
  • The specified analog Tuner’s UniqueID from the IGetCapabilitiesKey interface is unique from other devices on the system
  • The Tuner’s Video and Audio Mediums are not NULL and have different values
  • The test is able to locate one and only one output pin on the tuner that matches the Video Medium in both the Filter’s “FilterData” registration and pin’s KsQueryMedium() information.
  • The test is able to locate one and only one output pin on the tuner that matches the Audio Medium in both the Filter’s “FilterData” registration and pin’s KsQueryMedium() information.

    Note: It is valid for a single pin to match the Video and Audio Mediums in both steps 3 and 4.
  • The test is able to locate at least one TvAudio Filter and Crossbar Filter that with pins that match the Tuner’s Video and Audio Mediums in both the Filter’s “FilterData” registration and pin’s KsQueryMedium() information.
Failure:
This test will fail if any of the steps described above fail.
Also tests: <TODO: Merge with above>
Title: Test Dual Tuner Supports Additional Requirements
Success:
This test will succeed if all the following steps are successful:
  • Does not find multiple analog or digital Tuner instances of the same type and hardware id (hardware id not PnpId or DeviceInstanceId)
  • Finds multiple analog or digital Tuner instances of the same type and hardware id
  • The Tuner’s UniqueID from the IGetCapabilitiesKey interface is unique from other devices on the system
  • The Tuner’s Video and Audio Mediums are not NULL and have different values
  • The Tuner’s Video and Audio Medium GUIDs matches the Video and Audio Medium GUIDs for the other Tuner instances with the same type and hardware id
  • The Tuner’s Video and Audio Medium Ids do not match the Video and Audio Medium Ids for other Tuner instances with the same type and hardware id
Failure:
This test will fail there are multiple analog or digital Tuner instances of the same type and hardware id any of the following fail:
  • The specified Tuner’s UniqueID from the IGetCapabilitiesKey interface is not unique from other devices on the system
  • The Tuner’s Video and Audio Mediums are NULL or have the same values
  • The Tuner’s Video and Audio Medium GUIDs do not match the Video and Audio Medium GUIDs for the other Tuner instances with the same type and hardware id
  • The Tuner’s Video and Audio Medium Ids match the Video and Audio Medium Ids for other Tuner instances with the same type and hardware id
STREAM-0012
Title: Test Tuner Supports Automatic Rendering
Success:
This test will succeed if:
  • The analog tuner’s Capture filter and, if necessary, Mux filter can be inserted into a filter graph
And
  • A RenderPin() call on the Capture Filter’s capture pin is successful. If an Encoder filter (or multiple Encoder Filters) are required, it (they) must have been automatically inserted into the graph and connected between the Capture and Mux filters.
Failure:
This test will fail if either of the steps described above fail.
STREAM-0013
Title: Test Tuner Exposes Only Required Pins
Success:
This test will succeed if all of the following steps are successful:
  • Build analog and / or digital Tuner filter graphs for each tuner type supported by the specified Tuner device (the graph is not run)
  • For analog Tuner graphs, check that each of the following filters do not have any unconnected output pins:
    1. TV Audio Filter(s)
    2. Crossbar Filter(s)
    3. Capture Filter
    4. Encoder Filter(s) (valid if not in filter graph)
    5. Mux Filter (valid if not in filter graph)
    6. Demux Filter
  • For digital Tuner graphs, check that each of the following filters do not have any unconnected output pins:
    1. BDA Tuner Filter
    2. BDA Demod Filter (valid if not in filter graph)
    3. BDA Capture Filter
    4. Demux Filter
Failure:
This test will fail if any of the following steps fail:
  • Building analog and / or digital Tuner filter graphs for each Tuner Instance types supported by the specified Tuner device fails, or no Tuner Instance types are found for the specified PnpId
  • For analog Tuner graphs, if any of the following filter components have an unconnected output pin:
    1. TV Audio Filter(s)
    2. Crossbar Filter(s)
    3. Capture Filter
    4. Encoder Filter(s) (valid if not in filter graph)
    5. Mux Filter (valid if not in filter graph)
    6. Demux Filter
  • For digital Tuner graphs, if any of the following filter components have an unconnected output pin:
    1. BDA Tuner Filter
    2. BDA Demod Filter (valid if not in filter graph)
    3. BDA Capture Filter
    4. Demux Filter
Discussion:
Graph building for generic filters runs as approximately N-factorial in the number of exposed pins. Extra pins for card-specific features hence can seriously impact generic graph build times. Filters which wish to expose pins for unique features should start their name with a '~'. Such pins are ignored generic graph building so will not impact performance. The tests above also ignore such pins.
STREAM-0014
Title: Test Tuner Resources Are Not Acquired Until the Device Acquired State
Success:
This test will succeed if all the following steps are successful:
  • Build two separate analog or digital tuner graphs using the specified tuner
  • Run and stop one of the tuner graphs
  • While the first graph is still built; run and stop a second analog or digital tuner graph
Failure:
This test will fail if any of the steps described above fail.
Discussion:
Failure of this tests usually means that a filter has acquired a particular singleton hardware resource prior to being told to enter the acquire state. This block multiple graphs being left in the stop state, which seriously degrades performance when changing tasks.
However, to test this, the code creates and run several tuner graphs which acquire a large amount of video memory. It is highly recommended you turn of Desk Top Compositing before running this test to
STREAM-0015
Title: Test Tuner Properly Signals Channel Change
Success:
This test will succeed if all the following steps are successful:
  • The analog or digital graph is built and run
  • The channel is changed by the test case
  • For analog graphs, the TvWLPVBIMonitor detects both the IBroadcastEvent channel change event and the channel change flags in the filter graph media sample properties.
  • For digital graphs, the TvWLPMpeg2Monitor detects the IBroadcastEvent change change event
Failure:
This test will fail if:
  • The analog or digital graph fails to build and run
  • The channel fails to change
  • For analog tuners, if the TvWLPVBIMonitor does not detect both the IBroadcastEvent channel change event and the channel change flags in the filter graph media sample properties.
  • For digital tuners, if the TvWLPMpeg2Monitor does not detect IBroadcastEvent channel change event.
STREAM-0016
Title: Test Tuner Detects Signals from All Input Sources
Success:
The user is successively requested to supply an input signal on each of the inputs of the specified Tuner. This test will succeed if an input signal is detected on all the input sources.
Failure:
This test will fail if:
  • The analog and / or digital tuner graph does not successfully build and run
Or
  • A signal is not detected all the input sources.
Discussion
This is a very manual test. S-Video, Composite, and RF signals of the appropriate broadcast medium should made available to test with.
STREAM-0017
Title: Test USB TV Tuner Has a Unique Serial Number
Success:
This test will succeed if the USB TV tuner is a USB 2.0 compatible tuner. This tuner has the same PnP Device ID when it is moved to another USB connection. A tuner that is inserted into system from the same vendor will have unique serial number compared to the tuner that is already present in the system.
Failure:
This test will fail if the USB TV tuner is not a USB 2.0 compatible tuner. This tuner does not have same PnP Device ID when the user moves it to another USB connector. Also, it will fail if a tuner inserted by user from the same vendor does not have a unique serial number compared to a tuner that already present in the system. This test will fail if the tuner does not have a serial number. It will fail if the user aborts the test or will not follow instruction like when he or she is asked to insert additional tuner from same vendor.
Discussion:
If the tuner's connector is moved to another port, Media Center users this unique ID to recognize it's the same tuner. Without this, the system thinks a new tuner is installed and will require the user to go through first-run again, which is a serious performance and usability hit.
STREAM-0021
Title: Test Digital Tuner Uses Broadcast Driver Architecture
Success:
This test will succeed if all the following steps are successful:
  • Build a digital filter graph with the tuner
  • Tune to channel 3 in the default tuning space
  • Run the graph and wait 3 seconds to let data move through the graph
  • Locate the BDA Network Provider Filter
  • Query the BDA Network Provider filter for the following interfaces and call various methods on the interfaces:
    1. IFrequencyMap
    2. IMPEG2_TIF_CONTROL
    3. IBDA_NetworkProvider
    4. IScanningTuner
    5. ITuner
    6. IBDA_TIF_REGISTRATION
  • Locate the BDA Network Tuner Filter
  • Query the BDA Network Tuner filter for the following interfaces and call various methods on the interfaces:
    1. IBDA_DeviceControl
    2. IBDA_SignalStatistics
    3. IBDA_FrequencyFilter
    4. IBDA_AutoDemodulate
    5. IBDA_DigitalDemodulator
    6. IBDA_LNBInfo
  • Locate the optional BDA Demod Filter
  • Locate the BDA Capture Filter
  • Stop and deconstruct the digital filter graph
Failure:
This test will fail if any of the steps described above fail.
STREAM-0024
Title: Test Analog Tuner for Audio Decoding for Broadcast Region
Success:
This test will succeed if the analog tuner’s audio decoding supports; stereo, the main audio channel, and if the Country Code / Broadcast Region requires it, the secondary audio channel
Failure:
This test will fail if:
  • The analog tuner graph does not successfully build (the graph is not run)
Or
  • The analog tuner’s audio decoding does not support; stereo, the main audio channel, and if the Country Code / Broadcast Region requires it, the secondary audio channel
STREAM-0025
Title: Test Digital Tuner Provides Signal Quality and Diag Info
Success:
This test will succeed if all the following steps are successful:
  • Build a digital filter graph with the tuner
  • Tune to channel 3 in the default tuning space
  • Run the graph a wait 3 seconds to let data move through the graph
  • Locate the BDA Network Provider Filter
  • Query the BDA Network Provider filter for the ITuner interface
  • Call the ITuner->get_SignalStrength() method
  • Stop and deconstruct the digital filter graph
Failure:
This test will fail if any of the steps described above fail.
STREAM-0028
Title: Test Analog Tuner for Content Protection
Success:
This test will succeed if the analog tuner’s VBI stream from the analog tuner contains Macrovision/APS and CGMS content protection bits
Failure:
This test will fail if:
  • The analog tuner graph does not successfully build and run.
Or
  • If the analog tuner’s VBI stream from the analog tuner does not contain Macrovision/APS and CGMS content protection bits
Discussion:
This test will currently pass if at least one source of content protection is provided.
STREAM-0029
Title: Test Analog Tuner supports VBI Pass-thru
Success:
This test will succeed if the analog tuner and capture filters pass through VBI streams with the following characteristics:
NTSC:
Frame lines 10 through 21
Sampling rate frequency of 4.7 x NABTS (~26918000) or 5 x NABTS (~28636000)
At least 1400 samples per line
The stride is at least as large as the samples per line
The buffer size is at least as large required by the number of lines times the stride
PAL:
Frame lines 6 through 23
Sampling rate frequency greater then 4.7 x NABTS (~26918000)
At least 1400 samples per line
The stride is at least as large as the samples per line
The buffer size is at least as large required by the number of lines times the stride
Failure:
This test will fail if:
  • The analog tuner graph does not successfully build and run
Or
  • Any of the above specified NTSC or PAL VBI characteristics fail
Discussion:
Code is being updated to warn rather than fail if line 6 on PAL isn't supported.
STREAM-0056
Title: Test Tuner Supports Exhaustive Scanning API
Success:
This test will succeed if all the following steps are successful:
  • Build a PAL analog filter graph with the tuner
  • Locate the IScanningTunerEx interface
  • Query the number of standards supported
  • For each standard supported, query the Broadcast GUID, settling time and tvStandardsSupported
  • Set default values using SetScanSignalTypeFilter()
  • Begin PerformExhaustiveScan()
  • Get estimated scan duration from QueryTunerStatus(). The estimated scan duration must be between 5 seconds and 3 minutes
  • Wait for estimated scan duration and ensure at least 1 scanning event occurs
  • After 3 seconds of waiting, terminate the scan with TerminateCurrentScan() and then resume the current scan with ResumeCurrentScan()
  • Wait for exhaustive scan to successfully complete
  • Check that requested higher frequency was reached by the scan
Failure:
This test will fail if any of the steps described above fail.
STREAM-0057
Title: Test Tuner Video Control Graph Building
Success:
This test will succeed if the Microsoft VideoControl ActiveX object can be used to:
  • Build, run and stop a DirectShow graphs using the analog and / or digital Tuner instances of the specified Tuner device
And
  • For each of the filter graphs containing a distinct Tuner instance (FM, TV Analog, BDA, …) of the specified Tuner device, while the first graph is still built; build, run and stop a second analog and / or digital tuner graph using a second Tuner instance of the same type and Tuner device.
Failure:
This test will fail if any of the steps described above fail

Run Time: 5-10 min
Log File: TVWLPTest.xml
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Input Video sources per supported broadcast type (PAL, NTSC, ATSC, DVB-T, ...) and format (RF, FM, and Composite, SVideo)

Running TVWLPTest : ehome - premium tuner tests

1) Insert the video cards into the machine or connect via USB
2) Run the 3 Run-First jobs
3) Connect a valid RF signal to the card of the appropriate broadcast format (NSTC, SECAM, ATSC, …)
4) Run the job
- this will iterate and test each of the requirements listed above
5) Provide video input sources as requested in the manual tests.

Command Syntax

Command option | Description
tvwlptest <test case ID> “<Device ID of device you want to test>” |

Cautions

Expect a reasonable quality video / FM connections to the machine. Poor quality video feed may impact tests.

Troubleshooting

If the jobs are too big and hence difficult to debug, run the individual requirement through the DTM as manually scheduled job using the WDKDeviceID parameter and the requirement name (e.g. STREAM-0011) and PnP-ID (50+ character name) as described above in the Alternate Installation Steps.
None known.

Code Tour

File Manifest

File | Location
TVWLPTest.exe |
TVWLPAudioMonitor.ax |
TVWLPSourceFilter.ax |
TVWLPMPeg2Monitor.ax |
TVWLPVBIMonitor.ax |

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:

Windows Logo Program: STREAM-0010 Premium TV tuner supports both audio and video capture

Additional Information:

Test Assertion GUID:

Windows Logo Program: STREAM-0012 Premium TV tuner supports both audio and video capture

Additional Information:

Test Assertion GUID:

Windows Logo Program: STREAM-0013 Premium TV tuner supports both audio and video capture

Additional Information:

Test Assertion GUID:

Windows Logo Program: STREAM-0014 Premium TV tuner supports both audio and video capture

Additional Information:

Test Assertion GUID:

Windows Logo Program: STREAM-0015 Premium TV tuner supports both audio and video capture

Additional Information:

Test Assertion GUID:

Windows Logo Program: STREAM-0016 Premium TV tuner supports both audio and video capture

Additional Information:

Test Assertion GUID:

Windows Logo Program: STREAM-0017 Premium TV tuner supports both audio and video capture

Additional Information:

Test Assertion GUID:

Windows Logo Program: STREAM-0021 Premium TV tuner supports both audio and video capture

Additional Information:

Test Assertion GUID:

Windows Logo Program: STREAM-0024 Premium TV tuner supports both audio and video capture

Additional Information:

Test Assertion GUID:

Windows Logo Program: STREAM-0025 Premium TV tuner supports both audio and video capture

Additional Information:

Test Assertion GUID:

Windows Logo Program: STREAM-0028 Premium TV tuner supports both audio and video capture

Additional Information:

Test Assertion GUID:

Windows Logo Program: STREAM-0029 Premium TV tuner supports both audio and video capture

Additional Information:

STREAM-0056 STREAM-0056
Test Assertion GUID: STREAM-0056

Test Assertion GUID: STREAM-0057


DVD Annex - Decode Test

Overview

The DVD Annex - Decode test includes test cases that verify the following DVD decode related functionality:
  • Numbers
  • X Parade
  • Title Roll
  • Clock 24 fps and the Clock 60 Hz
  • 24fps Film
  • 60 Hz Video
  • 4Mb and 6Mb
  • 7.95 Mb
  • Highest
  • Low Bit Rate
  • Cycling Bit Rate
  • V-bench
  • Half Horizontal

Details

These test cases verify the DVD player’s ability to successfully perform its basic function, video playback. Although it is important to watch for DVD playback solutions that distort edge detail and contour intensity gradients (both of which are symptoms of inadequate iDCT precision), the most important issue during DVD video playback is motion portrayal.
Unfortunately, it is difficult to visually discern whether the device under test is delivering smooth motion. Sometimes it’s easy to identify a skipped picture, but it is also important to watch for other defects such as uneven delivery of images. For example, if a playback system repeats or “holds” an image eight times a second, then it is just as broken as a system that periodically skips an image. Unfortunately, it can be difficult to train your eye to recognize this kind of problem, known as jitter.
Therefore, for each of the four bit rates under consideration, the test disc provides four different test pattern sequences. The disc also provides continuous tone real images in both 24 fps film and 60 Hz video. As mentioned earlier, your best eye training might be to watch these sequences on an ordinary TV and learn how they look normally.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running DVD Annex - Decode Test

Command Syntax

Command option | Description
DVDAnnex.exe decode | Launches the test application for decode profile.

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

6.19.22 DVD playback and MPEG 2 decode is High Bit Rate: 4mB - X - Parade - 60Hz compliant.
Test Assertion GUID: 1793A9DB-4D72-4b71-A281-AD729319AF45

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

6.19.23 DVD playback and MPEG 2 decode is High Bit Rate: 7.95mB - Clock - 60Hz compliant.
Test Assertion GUID: 496F7D4E-5DD5-4fea-8774-74605000DC5A

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

6.19.24 DVD playback and MPEG 2 decode is High Bit Rate: 7.95mB - 24 fps Film compliant.
Test Assertion GUID: 1B88542B-5558-4963-A7D7-B61DBB23B3E4

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

6.19.25 DVD playback and MPEG 2 decode is High Bit Rate: Highest - 60 Hz Video compliant.
Test Assertion GUID: 06AB5A6B-7FB9-4c54-9647-0AE7175BCB49

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

6.19.26 DVD playback and MPEG 2 decode is Low Bit Rate: Clock - 60Hz compliant.
Test Assertion GUID: C3D74B71-BE6E-453e-8111-F25558366B07

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

6.19.27 DVD playback and MPEG 2 decode is Low Bit Rate: Jazz Montage compliant.
Test Assertion GUID: 2C895F09-70D2-42d6-90AF-50155AB1CF52

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

6.19.28 DVD playback and MPEG 2 decode is Cycling Bit Rate compliant.
Test Assertion GUID: 593E0C2B-0B00-4631-8C92-749C89039E63

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

6.19.29 DVD playback and MPEG 2 decode is V-Bench compliant.
Test Assertion GUID: 22103464-09BF-4ad0-826A-26A5092851D4

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

6.19.30 DVD playback and MPEG 2 decode is Half-Horizontal: X Parade (60) compliant.
Test Assertion GUID: 5BF11160-C1EC-40c3-ACF4-F242F686AB16

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

6.19.31 DVD playback and MPEG 2 decode is Half-Horizontal: 24 fps Film compliant.
Test Assertion GUID: BBF87A5E-3B22-42fb-B2BE-83A6CFA518CF

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:


TVWLPTest - ehome - premium system tests

Type: Automated Test

Overview

This document describes the Vista requirements tested in the 'ehome - premium system tests' job. These tests are all invoked by a program called TVWLPTest and up to four DShow filters it may load.
Verifies that system is capable of supporting premium media center functionality. Tests SYSFUND-0043, and SYSFUND-0064

Details

TvWLPTest is a command line program invoked by the DTM that verifies most of the Media Center requirements. Failure of any requirement will cause the entire job to fail.
This job tests the following requirements:

SYSFUND-0043 (SYS-GLD-3)

Title: Test System Has Two User Accessible USB Bus Powered Ports, One for Mobile
Success:
This test will succeed if it successfully finds two (for desktop) or one (for mobile) USB device and if both or one of the devices are connected to USB 2.0 ports.
Failure:
This test will fail if it does not successfully find two (for desktop) or one (for mobile) USB device or if both or one of the devices are not connected to USB 2.0 ports. It will fail if user aborts the test.

SYSFUND-0064 (SYS-GLD-4)

Title: Test System with a Tuner Must Enable DMA On All Storage Devices
Success:
This test will succeed if DMA is enabled on all storage devices that include hard drives and CD/DVD-ROMs.
Failure:
This test will fail if DMA is disabled at least on one of storage devises.

Run Time: 2-3 secs
Log File: TVWLPTest.xml
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running TVWLPTest - ehome - premium system tests

1) Run the 3 RunMeFirst jobs.
2) Run the job
- this will iterate through the requirement(s) listed above

Command Syntax

Command option | Description
tvwlptest <test case ID> “<Device ID of device you want to test>” |

Cautions

none known

Troubleshooting

If the jobs are too big and hence difficult to debug, run the individual requirement through the DTM as manually scheduled job using the WDKDeviceID parameter and the requirement name (e.g. STREAM-0011) and PnP-ID (50+ character name) as described above in the Alternate Installation Steps.
None known.

Code Tour

File Manifest

File | Location
TVWLPTest.exe |
TVWLPAudioMonitor.ax |
TVWLPSourceFilter.ax |
TVWLPMPeg2Monitor.ax |
TVWLPVBIMonitor.ax |

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


AV/C Tape Subunit Compliance Test

Type: Automated Test

Overview

MSTapeTst is the automated test app for IEEE 1394 AV/C (Audio/Video Control) protocol Video Capture.

Details

IEEE 1394 Trade Association defined the AV/C protocol to control external audio/video devices. The full details of the AV/C protocol are available on the 1394 Trade Association's website.
In Windows XP and later operating systems, Microsoft supplies the driver to support AV/C subunit drivers. Microsoft also supplies a different lower-filter driver to assists subunits that stream DV or MPEG2TS data.
MSTapeTst uses the Windows Multimedia API DirectShow to enumerated Video Capture devices which are IEEE1394 AV/C compliant.
The MSTapeDV.pro test case profile tests devices that create streams in the DV format, an international standard for consumer digital video format.
The MSTapeMPEG2.pro test case profile tests devices that create streams in the MPEG2 format, the Motion Picture Expert Group Level-2 compression standard.
The test cases exercise the automated functions of the devices and their adherence to the specifications noted above.

Run Time: 15 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running AV/C Tape Subunit Compliance Test

The test log will provide details on any failures, including system hangs or crashes.

Command Syntax

Command option | Description
mstapetst.exe | Without any options, the test enumerates devices
-c [string] | starts the app and runs the tesetcases specified in the .pro file
-h [string] | specifies the PnP ID of the device to be tested
mstapedv.pro | the .profile of testcases to be run for the DV format
mstapempeg2.pro | the .profile of testcases to be run for the MPEG2 format

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location
mstapetst.exe | [testbinroot]\nttest\multimediatest\avcore\vidcap\external

Click to show or hide information. Test Assertions

Test Assertions

B11.4.4.9 IEEE 1394 DV camcorder and digital tape device comply with IEEE 1394
Test Assertion GUID: 455EC1BB-7F4B-4C3C-A427-92B24734811B

Windows Logo Program: STREAM-0051 IEEE 1394 DV camcorder and digital tape device comply with IEEE 1394

Additional Information: The test verifies that the device is compliant with the 1EEE1394 AV/C specification available from http://www/1394ta.org.


Pressure Streaming Device test

Type: Automated Test

Overview

Test for Streaming device and driver implementation.
Some test cases check for correct error handling by devices and their drivers.
Incorrect handling of these cases may result in a system hang or crash.

Details

PressureTest is a quality assurance test for multimedia device drivers.
When the test starts, it automatically enumerates all devices with one of these KSCATEGORYs, which are defined in the WDK’s KSMEDIA.H header file.
KSCATEGORY_AUDIO,
KSCATEGORY_VIDEO,
KSCATEGORY_CAPTURE,
KSCATEGORY_RENDER,
KSCATEGORY_CLOCK,
KSCATEGORY_MIXER,
KSCATEGORY_PROXY,
KSCATEGORY_DATACOMPRESSOR,
KSCATEGORY_DATADECOMPRESSOR,
KSCATEGORY_ENCODER,
KSCATEGORY_TVAUDIO,
KSCATEGORY_TVTUNER,
KSCATEGORY_CROSSBAR,
KSCATEGORY_VBICODEC
The test then enumerates the devices found in each category
Here’s a subset of the enumeration display, with device “Friendly Name” preceding the internal device name.
Class KSCATEGORY_CAPTURE
Device #27 [SB Audigy MIDI Port [1000]]: \\?\pci#ven_1102&dev_0004&subsys_00531102&rev_03#3&61aaa01&0&48#{65e8773d-8f56-11d0-a3b9-00a0c9223196}\uart1
Device #28 [SB Audigy Audio [1000]]: \\?\pci#ven_1102&dev_0004&subsys_00531102&rev_03#3&61aaa01&0&48#{65e8773d-8f56-11d0-a3b9-00a0c9223196}\wavepci
Device #29 [TestCap Capture]: \\?\root#media#0000#{65e8773d-8f56-11d0-a3b9-00a0c9223196}\global
Device #30 [avshws Source]: \\?\root#media#0001#{65e8773d-8f56-11d0-a3b9-00a0c9223196}\global
Most of the test cases are run against one or more selected devices. The first test case, ”1.1 Enumerate devices” does not need a device. The device selection UI is launched from the menu item /Options/Select Devices (hotkey is <control> D). You can select none, one, some or all devices. All selected test cases are run sequentially against the first device selected in the list (which is in order of enumeration). Then the test cases are run against the next device in list, and the next, until all test cases have been run against all devices.
The security test cases enumerate multimedia drivers and attempts to verify the driver’s ability to survive when sent malformed and invalid data. Drivers which fail this testing will typically either crash or hang the system (hanging is rare, but has been seen).
All test cases return PASS or FAIL. If a driver fails a security test case by crashing or hanging, the test case will not complete. This is considered a driver FAIL.

Run Time: 15 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running Pressure Streaming Device test

The test log will provide details on any failures, including system hangs or crashes.

Command Syntax

Command option | Description
pressuretest.exe | Without any options, the test enumerates devices
-c [string] | starts the app and runs the testcases specified in the .profile
-h [string] | specifies the PnP ID of the device to be tested
pressurestandard.pro | the .profile of testcases to be run

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location
pressuretest.exe | [testbinroot]\nttest\multimediatest\avcore\vidcap\external\

Click to show or hide information. Test Assertions

Test Assertions

GRFX-72 Display device exposes integrated tuner functionality through WDDM capture infrastructure
Test Assertion GUID: 2e7b2d1f-43ba-464a-885a-58be93841ce7

Windows Logo Program: GRAPHICS-0053 Display device exposes integrated tuner functionality through WDDM capture infrastructure

Additional Information: The test verifies that if a system is using a WDDM (Windows Display Driver Model) display; and system has a Capture device; and that Capture device is a child device of the WDDM display; then the child device must use the WDDMCapture driver model, as documented in the WDK.

STR-0015 Streaming Media device handles error conditions without hanging, crashing, or causing a blue screen on the system
Test Assertion GUID: 7F7279E3-8492-4A4A-B8E5-0D8C9089D5DF

Windows Logo Program: STREAM-0002 Streaming media device handles error conditions without hanging, crashing, or causing a blue screen on the system

Additional Information: The test verifies that the selected driver can handle errors conditions including (but are not limited to) forced invalid pin connections, invalid property sets, buffers with invalid data, null pointers, and error conditions from drivers above or below on the stack. This is done by sending a limited set of invalid commands from user level.

STREAM-0052 Video Capture device does not expose a preview pin
Test Assertion GUID: faf0532f-a9f2-4157-8e12-a617b7a8acb5

Windows Logo Program: ERROR ERROR

Additional Information: Video capture devices must expose a capture pin that can be used to create multiple streams that allow both preview and capture. This test determines that if a device is a video capture device, that it has a Capture pin and does not have a Preview pin.

STR-0019 UVC-capable device complies with USB Video Class specifications
Test Assertion GUID: 12E86C83-D25A-459E-A499-78690E57D6B6

Windows Logo Program: STREAM-0008 UVC-capable device complies with USB Video Class specifications

Additional Information: USB streaming video cameras must comply with the USB Video Class specifications. At a minimum, all mandatory properties and commands must be implemented. All commands implemented must comply with the specifications. USB streaming video cameras that use MJPEG, YUY2, or MPEG-2 TS for capture, or DV for capture or render, must also work with the Microsoft-provided USB Video Class driver. This test determines that if a device is a video capture device; and it is on the USB bus; that device must use the USB Video Class driver.

B11.1.1.1.2 Streaming media device driver is based on AVStream class and WDM
Test Assertion GUID: 5AFFF2F7-D99A-4DFD-B2E0-E52953B47E2C

Windows Logo Program: STREAM-0001 Streaming media device driver is based on AVStream class and WDM

Additional Information: Device drivers for any streaming media device must use the AVStream class WDM device driver model as defined in the Windows Driver Kit. AVStream is the replacement technology for the older Stream class driver model, which is outdated and will no longer be enhanced. Drivers for streaming media devices must also support all of the required pins, properties, and settings as defined in the Windows Driver Kit. This test determines that if a device is a multimedia device, the device driver uses the AVStream Class driver as documented in the WDK.


DVD Annex - Video Automated Test

Overview

The DVD Annex - Video Automated test includes the following test cases, which are designed to verify that the DVD content can match various playback scenarios and match user experience expectations. Results are evaluated automatically. No user interaction is required.
  • Excessive Cropping
  • Aspect Ratio
  • Forced Letterbox

Details

N/A

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running DVD Annex - Video Automated Test

Command Syntax

Command option | Description
DVDAnnex.exe | Launches the test application.

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

6.19.123 DVD playback and MPEG 2 decode is Excessive Cropping: 352x240 compliant.
Test Assertion GUID: B5BF2C02-7E88-4bab-B301-2DCCB68C02DF

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

6.19.126 DVD playback and MPEG 2 decode is Excessive Cropping: 720x480 compliant.
Test Assertion GUID: 0BBE980C-6F64-49d5-991B-417C1FE822E3

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

6.19.129 DVD playback and MPEG 2 decode is Excessive Cropping: 704x480 compliant.
Test Assertion GUID: 812DC590-7B65-4110-A4ED-1BD584215EDA

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

6.19.132 DVD playback and MPEG 2 decode is Excessive Cropping: 352x480 compliant.
Test Assertion GUID: DFBB2467-532A-4925-8AAE-3E33D5507244

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

6.19.137 DVD playback and MPEG 2 decode is Forced Letterbox - Window compliant.
Test Assertion GUID: D1CA2174-C178-4703-BBAA-F1A544378BBD

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:


DVD Annex - PAL Playback Test

Overview

This test verifies that DirectShow application programming interface (API) handling is correct for PAL and that quality is maintained during DVD playback.

Details

N/A

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running DVD Annex - PAL Playback Test

Command Syntax

Command option | Description
TBD |

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

DVD playback and MPEG 2 decode can do playback (PAL)
Test Assertion GUID: E69483F6-4A2D-4599-9ECA-CBA2BA4186BA

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

DVD playback and MPEG 2 decode can select and activate 2 (PAL)
Test Assertion GUID: 8B23F3A4-06F2-44c1-9770-D2E4E99987CC

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

DVD playback and MPEG 2 decode can select and activate 1 (PAL)
Test Assertion GUID: EB3FED4F-A0E9-4aef-8F9B-B9B6207D3F81

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

DVD playback and MPEG 2 decode can fast forward (PAL)
Test Assertion GUID: 0BE8CC89-7AEA-4a7f-9975-7A4199839A23

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

DVD playback and MPEG 2 decode can rewind (PAL)
Test Assertion GUID: 0A551F15-4BAD-49f6-A8F5-11574A03D3E8

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

DVD playback and MPEG 2 decode can do timeplay (PAL)
Test Assertion GUID: 8C5B08CA-C299-4f9d-A8AB-B485B9203BCD

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:


Audio or Video Capture and Control (Blink)

Type: Automated Test

Overview

Blink is a test for multimedia Video Capture devices.

Details

Video Capture devices are cameras and A/V input devices which bring streaming multimedia data into a PC and provides that video in a format usable by the Windows operating system and its client applications.
Video Capture devices physically come in two major categories. Cameras receive data with a Lens (a transparent device to receive and focus light). Lens-less devices receive their data with a different mechanism, such as an S-Video cable or an antenna.
In the Windows operating system, Cameras are installed by the Image Class installer and Lens-less Video Capture devices are installed by the Media Class installer. If you install a USB Video Class (UVC) device and a TV Tuner into Windows and check Device Manager, you’ll see each device show up under a different class (even though they are both Video Capture devices).
Cameras in turn can be categorized as either Still Image or Streaming Image. The difference is that Still Image cameras are designed to capture single frames at a high resolution for use, while Streaming Image Video Capture cameras are designed to capture a series of frames intended to be used sequentially.
The Video Capture logo program is primarily intended for simple A/V input devices, tethered webcams and portable camcorders.
Webcams are simple cameras which are attached (tethered) to a PC with an IEEE 1394 or USB cable that provides both power and I/O. There is a small number of USB webcams which include batteries and simple onboard storage for still pictures so that they can function independently.
Camcorders are fully functional whether attached to the PC or not. Camcorders have sophisticated on board storage for recording streaming audio and video. Tape is the usual storage medium, though a few devices record to a writeable DVD. Camcorders are Audio / Video capture devices. DV and MPEG2 are the most common streaming media supported.
There are two types of Video Capture devices which are important enough to merit their own logo program.
Cameras which are designed for single frame image capture are covered by a different logo program.
Broadcast Receivers (also called TV Tuners) are hardware and software which bring broadcast signals (via cable, satellite and over the air) into a PC. Broadcast audio/video includes FM radio; analog television tuners (NTSC, PAL, SECAM); and digital television tuners (ARIB, ATSC, DVB, DSS). Broadcast Receivers are covered by a different logo program.
When the Blink test starts, it automatically enumerates all devices which are Audio and / or Video Capture using the DirectShow API. DirectShow is the Microsoft Windows operating system Multimedia API and its use is required for the logo program.

Run Time: 15 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running Audio or Video Capture and Control (Blink)

The test log will provide details on any failures, including system hangs or crashes.

Command Syntax

Command option | Description
blink.exe | Without any options, the test enumerates devices
-c [string] | starts the app and runs the tesetcases specified in the .pro file
-h [string] | specifies the PnP ID of the device to be tested
BlinkStandard.pro | the .profile of testcases to be run

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location
blink.exe | [testbinroot]\nttest\multimediatest\avcore\vidcap\external

Click to show or hide information. Test Assertions

Test Assertions

STREAM-0003 Streaming Media device supports multiple client applications using a single device
Test Assertion GUID:

Windows Logo Program: STREAM-0003 Streaming media device supports multiple client applications by using a single device

Additional Information: This test verifies that a video capture device driver is able to support multiple clients at once, with only one client actively using the device at a time and the other clients merely acquiring the device.


DVD Annex - Audio Test

Type: Automated Test

Overview

The DVD Annex - Audio test suite includes tests for these formats:
  • Running the MPEG-1 Layer 2 test
  • Running the 48 kHz PCM test
  • Running the Dolby Digital test
  • Running the 96-kHz PCM test - Required DVD-Video audio format.

Details

N/A
Run Time: 10 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86

Running DVD Annex - Audio Test

Command Syntax

Command option | Description
DVDAnnex.exe audio | Launches the test application for audio profile.

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

6.19.1 DVD playback and MPEG 2 decode is Mpeg1 Layer2 Audio compliant.
Test Assertion GUID: {E4F3783A-132E-44e6-9A3A-C13B22B8B227}

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information: Content will be published

6.19.2 DVD playback and MPEG 2 decode is 48 kHz PCM Audio compliant.
Test Assertion GUID: {A96A9DBD-898B-4071-816E-1F59AEA66626}

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information: Content will be published

6.19.3 DVD playback and MPEG 2 decode is 96 kHz PCM Audio compliant.
Test Assertion GUID: {B9D3112F-448E-44ee-BC6B-111F3E832076}

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information: Content will be published

6.19.4 DVD playback and MPEG 2 decode is AC3 Stereo compliant(Audio Track 1).
Test Assertion GUID: {6FF480D7-0206-4fa5-9264-9B3588F022DF}

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information: Content will be published

6.19.5 DVD playback and MPEG 2 decode is AC3 Stereo compliant(Audio Track 3).
Test Assertion GUID: {A8368226-2DA3-46c7-96AA-04D6E3837A75}

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information: Content will be published

6.19.6 DVD playback and MPEG 2 decode is AC3 Stereo 5.1 Channel compliant.
Test Assertion GUID: {436B6436-8FCC-4c3c-AECA-8E439A995FF5}

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information: Content will be published


Codec API Test

Type: Automated Test

Overview

Unitest for ICodecAPI implementation.

Details

Test starts with building the DirectShow graph as described below.
For scenarios using mux filter:
  1. Create filter graph;
  2. Add AV source filter (AVSource.dll, part of WDK, clsid is CLSID_AVSource);
  3. Add mux filter:
    4. Create device enumerator ICreateDevEnum (CLSID_SystemDeviceEnum) and CreateClassEnumerator(CLSID_MediaMultiplexerCategory). Verify there is only one fetched object and bind it to IBaseFilter with name "Mux/Enc". ATTENTION! Test will fail if there are more than one devices satisfying mentioned conditions. To resolve this conflict, unregister all software mux filters except for the one being tested.
  4. Connect AVSource to mux filter;
  5. Add PS analyzer filter (CLSID_MpegStreamAnalyzer, part of WDK as PSAnalyzerFilter.dll). This filter intercepts and analyzes MPEG stream and Program Stream.
  6. Connect mux filter and PS analyzer;
  7. Add dump filter (CLSID_Dump, part of WDK as dump.dll)
    8. This is a generic renderer that can be attached to any data stream that uses IMemInputPin data transport. For each sample it receives, it writes its content including its properties into a dump file. Such file is specified when the dump filter is created. GraphEdit creates a file open dialog automatically when it sees a filter being created that supports the IFileSinkFilter interface.
  8. Connect PS analyzer to dump filter.
For scenarios using non-mux filter: same as above, except for test creates class enumerator for CLSID_LegacyAmFilterCategory at step 3.
Once filter graph has been initialized and your encoder is identified, test queries it for ICodecAPI and performs series of functional tests as follows.
Common parameters:

Create encoder graph

Set Mux Stream Format DVD_V

Set Video format Mpeg2

Set Audio format Mpeg1

Set Audio format Mpeg2

Set Video bitrate Mode CBR

Set Video bitrate Mode PeakConstrainedVBR

Set Video bitrate Mode UnconstrainedVBR

Set Video bitrate Mode Quality

Set low latency true

Set low latency false

Set multipass mode equal to 1

Set multipass mode greater than 1

Invalid: Set multipass mode equal to zero

Invalid: Set multipass mode equal to huge number

Set Encode real time default

Encode quality get default value

Encode quality set default value

Encode QualityVsSpeed get default value

Encode QualityVsSpeed set default value

Encode Mean bitrate Get default value

Encode Mean bitrate set default value

Invalid: Encode Mean bitrate set invalid value

Encode Mean bitrate Interval Get default value

Encode Max bitrate Interval Get default value

Encode Max bitrate Interval set default value

Invalid: Encode Max bitrate Interval set invalid value

Encode Buffer Size Get default value

Encode Buffer Size set default value

Encode Buffer In Level Get default value

Encode Buffer In Level set default value

Invalid: Encode Buffer In Level set invalid value

Encode Buffer OutLevel Get default value

Encode Buffer OutLevel set default value

Invalid: Encode Buffer OutLevel set invalid value

Encode stream end handling Get default value

Encode stream end handling set default value

Invalid: Encode stream end handling set invalid value

Encode get completed passes default
Common audio (if applicable)

get audio stats average bitrate value

get audio stats average pcm value

get audio stats peak pcm value

set audio input content Invalid

set audio input content Music

set audio input content Voice

set audio input content Unknown

set audio channel mapping invalid

set audio channel mapping default

set audio interval to skip default

set audio interval to encode = valid limit

set audio interval to encode = no limit

set audio input channel config invalid

set audio input channel config default

set audio input channel count invalid

set audio input channel count default

set audio sampling rate invalid

set audio sampling rate default

Common video parameters (if applicable):

get total coded frames

get coded frames

get output frame rate

set motion trade off invalid

set motion trade off default

set motion trade off max

set motion trade off min

set upper field dominant false

set upper field dominant true

set video header time code

set input video system NTSC

set output color range invalid

set output color range 48-208

set output color range 16-235

set output color range 0-255

set output color range SameAsSource

set input color range invalid

set input color range 48-208

set input color range 16-235

set input color range 0-255

set output color lighing Invalid

set output color lighing Dark

set output color lighing Dim

set output color lighing Office

set output color lighing Bright

set output color lighing Unknown

set input color lighing Invalid

set input color lighing Dark

set input color lighing Dim

set input color lighing Office

set input color lighing Bright

set input color lighing Unknown

set output color transfer matrix SMPTE240M

set output color transfer matrix BT601

set output color transfer matrix BT709

set output color transfer matrix same as source

set input color transfer matrix default

set output color transfer function 22_8bit_sRGB

set output color transfer function 22_240M

set output color transfer function 22_709

set output color transfer function 22

set output color transfer function 20

set output color transfer function 18

set output color transfer function 10

set output color transfer function SameAsSource

set input color transfer function default

set output color primaries EBU3231

set output color primaries SMPTE240M

set output color primaries SMPTE170M

set output color primaries BT470_2_SysBG

set output color primaries BT470_2_SysM

set output color primaries BT709

set output color primaries reserved

set output color primaries same as source

set input color primaries default

set output chroma resolution invalid

set output chroma resolution 420

set output chroma resolution 422

set output chroma resolution 444

set output chroma resolution same as source

set input chroma resolution

Donot swap field order in video

swap field order in video

set input source not black and white

set input source black and white

set inverse telecine file content invalid

set inverse telecine file content mixed

set inverse telecine file content film

set inverse telecine file content video

set inverse telecine threshold invalid

set inverse telecine threshold default

set inverse telecine threshold max

set inverse telecine threshold min

set inverse telecine false

set inverse telecine true

set video output scan Invalid

set video output scan Auto

set video output scan SameAsInput

set video output scan Interlaced

set video output scan Progressive

set video display dimension invalid

set video display dimension same as source

set encode offset origin invalid

set encode offset origin valid

set encode offset origin (0,0)

set encode dimension invalid

set encode dimension same as source

set encode dimension default

Number of fields to skip default

Number of fields to encode zero

Number of fields to encode default

Encode set scan type invalid

Encode set scan type default

Encode set scan type progressive

Encode set scan type interlaced

Encode set pixel aspect ratio invalid

Encode set pixel aspect ratio default

Encode disable output frame rate conversion

Encode enable output frame rate conversion

Encode video set output frame rate invalid

Encode video set output frame rate default

Encode video get output frame rate
AC3 Audio (if applicable)

set not original bitstream

set original bitstream

set not copy protected

set copy protected

set ProductionMixLevel default

set production room type small

set production room type large

set ProductionInfoExists false

set ProductionInfoExists true

set no SurroundMode

set SurroundMode

set SurroundDownMixLevel default

set CentreDownMixLevel default

set DialogNormalization default

set service karaoke

set service emergency

set service commentary

set service dialog

set service hearing impaired

set service visually impaired

set service music and effects

set service complete main
Mpeg Audio (if applicable)

set mpeg audio mode surround

set mpeg audio mode joint stereo

set mpeg audio mode dual channel

set mpeg audio mode Stereo

set mpeg audio mode Mono

set mpeg audio invalid layer

set mpeg audio layer 3

set mpeg audio layer 2

set mpeg audio layer 1
Mpeg Video (if applicable)

set mpeg video intra vlc table alternate

set mpeg video intra vlc table mpeg1

set mpeg video quant scale non linear

set mpeg video quant scale linear

set mpeg video intra dc precision zero

set mpeg video intra dc precision default

set mpeg video alternate scan

set mpeg video ZigZag scan

set mpeg video do not add sequence scalable extension

set mpeg video add sequence scalable extension

set mpeg video do not add picture display extension

set mpeg video add picture display extension

set mpeg video do not add picture header extension

set mpeg video add picture header extension

set mpeg video do not generate sequence display extension

set mpeg video generate sequence display extension

set mpeg video generate sequence header extension

set mpeg video on scene change new locatable GOP

set mpeg video on scene change new gop

set mpeg video on scene change insert I picture

set mpeg video on scene change default

set mpeg video do not use concealmeant MVs

set mpeg video use concealmeant MVs

set mpeg video GOPs in Seq non zero

set mpeg video GOPs in Seq zero

set mpeg video do not add sequence end code

set mpeg video add sequence end code

set mpeg video generate interlaced frames

set mpeg video generate fields seprately

set mpeg video invalid level

set mpeg video High level

set mpeg video

set mpeg video Low level

set mpeg video invalid profile

set mpeg video High profile

set mpeg video Main profile

set mpeg video Simple profile

set mpeg video B picture count default

set mpeg video Closed gop

set mpeg video open GOP

set mpeg video GOP size default

Run Time: 15 min
Log File: ShellRunner.wtl
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running Codec API Test

This is a simple automated unitest for ICodecAPI. Test log would contain which particular properties are broken.

Command Syntax

Command option | Description
ShellRunner.exe -c FVT.pro -l "s98wtt.dll" |

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location
[WTT\TestBinRoot]\nttest\multimediatest\common\ShellRunner*.* |
[WTT\TestBinRoot]\nttest\multimediatest\common\s98wtt.dll |
[WTT\TestBinRoot]\nttest\multimediatest\streaming\CodecAPI\*.* |

Click to show or hide information. Test Assertions

Test Assertions

STR-0021 CodecAPI FVT
Test Assertion GUID: 99114456-343A-4c02-A7A4-DC253DD3681F

Windows Logo Program: STREAM-0005 Streaming media device that encodes video streams uses Video Encoder API and ICodecAPI

Additional Information:


DVD Annex - NTSC Playback Test

Overview

This test verifies that DirectShow application programming interface (API) handling is correct and that quality is maintained during DVD playback. It also includes a test case for Line 21 Closed Caption handling.

Details

N/A

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running DVD Annex - NTSC Playback Test

Command Syntax

Command option | Description
DVDAnnex.exe NTSCPlayback | Launches the test application for NTSC playback profile.

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

DVD playback and MPEG 2 decode do playback (NTSC)
Test Assertion GUID: 4BD484E9-3B69-4410-A2F5-D23917973089

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

DVD playback and MPEG 2 decode can show menu (NTSC)
Test Assertion GUID: F2701850-866A-4ce3-A98D-A33731975BEC

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

DVD playback and MPEG 2 decode can display button (NTSC)
Test Assertion GUID: F06E4209-FECD-48bf-9DC1-FD070C030E2C

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

DVD playback and MPEG 2 decode can resume (NTSC)
Test Assertion GUID: 931F212E-A037-4a72-AE1E-DF501BB4AAA2

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

DVD playback and MPEG 2 decode can fast forward (NTSC)
Test Assertion GUID: 3471C820-9892-4a3f-8DAC-AC55FEEDEF4A

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

DVD playback and MPEG 2 decode can rewind (NTSC)
Test Assertion GUID: 07850EBB-EA69-43bd-B69F-009D72565F2E

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

DVD playback and MPEG 2 decode can playback (NTSC) (2)
Test Assertion GUID: E9226ED8-5C57-4f97-B8F5-0D5EC65E1AD8

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

DVD playback and MPEG 2 decode can do time play (NSTC)
Test Assertion GUID: 8CF25E58-5ECF-483d-8A28-476276190561

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

DVD playback and MPEG 2 decode can switch subpicture (NTSC)
Test Assertion GUID: 8981EDA6-E6DA-4f09-A9F9-106A73225082

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

DVD playback and MPEG 2 decode can turn off subpicture (NTSC)
Test Assertion GUID: E096D5CF-9F9B-478e-8E17-45ACE0D42AAA

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:

DVD playback and MPEG 2 decode can handle Closed Caption (NTSC)
Test Assertion GUID: 233D5AB6-E846-4399-8408-CC96D070D030

Windows Logo Program: STREAM-0036 DVD Playback is interoperable with DirectShow components

Additional Information:


DTM System Test Categories

The DTM supports the following system test categories:

  • On Windows Vista:
    • Desktop (Business)
    • Desktop (Consumer)
    • Desktop (Business and Consumer)
    • Mobile (Business)
    • Mobile (Consumer)
    • Mobile (Business and Consumer)
    • Motherboard (Business)
    • Motherboard (Consumer)
    • Motherboard (Business and Consumer)
    • Ultra-Mobile (Business)
    • Ultra-Mobile (Consumer)
    • Ultra-Mobile (Business and Consumer)
    • Ultra-Portable (Business)
    • Ultra-Portable (Consumer)
    • Ultra-Portable (Business and Consumer)
  • On Windows Server 2003:
    • Standard
    • Supported
  • On Windows XP:
    • Desktop
    • Mobile
    • Motherboard

The system test categories for the Windows Vista operating system are categorized in two qualification levels:

Premium
A product that is being tested is deemed compliant when it meets the premium logo requirements as defined in the Windows Logo Program documentation. This level of compliance indicates to a customer that the product enables additional or enhanced capability with the Windows operating system, thereby enabling a premium experience.
Basic
A product that is being tested is deemed compliant when it meets the basic logo requirements as defined in the Windows Logo Program documentation. This level of compliance indicates to a customer that the product works well with the Windows operating system. The basic logo requirements ensure reliability, stability, security, and proper installation, as well as implements functionality that takes advantage of some of the latest Windows innovations.

The system test categories for the Windows Vista operating system are categorized in two market segments:

Business
This segment includes two parts:
  • Information Worker helps workers use their computer more effectively with new tools to help protect their system, easier ways to find and use their information, and better integration across applications, devices, and networks.
  • Small Business helps workers keep their computers running more smoothly and more securely, while giving them powerful new ways to find and use their information. It offers an improved ability to connect technologies and people so that workers can focus on running their business.
Consumer
The operating system designed for digital entertainment and personal productivity around the home or on the go, integrating the widest range of applications, services, and hardware in a familiar way so that each person can easily and confidently use technology to achieve his or her goals and pursue his or her passions.

The system test categories for the Windows Vista operating system are categorized into five form factors:

Desktop
A uniprocessor or multiprocessor system that requires AC power for continuous operation.
Mobile
A uniprocessor or multiprocessor system that can be physically carried, has integrated display and input devices, and has a battery that can provide continuous operation when not plugged in.
Motherboard
The physical arrangement in a computer that contains the system's basic circuitry and components.
Ultra-Mobile
A mobile system that weighs less than 2.5 pounds or 1.134 kilograms in the standard configuration, is battery powered, and has a 7-inch or smaller screen size.
Ultra-Portable
A mobile system that weighs less than 4 pounds or 1.814 kilograms in the standard configuration and is battery powered.


System Requirements for the Targeted Logo System

The test system must meet the following hardware and software requirements:

Hardware Requirements

  • One computer is targeted as the system under test. This system must include the following:
    • x86-based, x64-based, and Itanium-based processor architectures
    • System memory requirements:
      • On Windows Vista:
        • Basic logo: at least 512 MB
        • Premium logo: at least 1 GB
      • On Windows Server 2003:
        • The maximum RAM that the system can support
      • On Windows XP
        • 128 MB minimum
    • Logo-compliant ACPI BIOS with ACPI enabled by default
    • Hard disk drive (with at least 20 GB of storage capacity)
    • Floppy disk drive

      Note If the system does not include a floppy disk drive, a USB floppy disk drive is required for testing purposes.

    • CD-ROM drive or DVD-ROM drive
    • Monitor, keyboard, and mouse (or any pointing or drawing device)
    • Audio device (if the test system supports audio)
    • Audio loopback cable (if the test system supports audio)
    • Network adapter
  • One network hub
  • One additional system (some tests may require an additional system to complete testing)
  • One serial loopback connector that meets the following specifications:

    Connections for a Serial Loopback RS232C Connector

    Connect this pin | To this pin
    Tx | Rx
    RTS | CTS, DCD (Same as CD)
    DTR | DSR, RI

  • Optional (for a Consumer premium logo). Audio Precision system two and connector cables (with associated software installed on a second system).

    Note If the Audio Precision system is not used to complete the Fidelity test, the system will be targeted for audit to meet the Windows Logo Program requirements.

Software Requirements

The following operating systems are supported for logo testing:

  • Windows Vista. If you use Windows Vista, keep the following notes in mind:
    • The Consumer-Premium logo cannot use the Home-Basic SKU of Windows Vista.
    • You must use the Ultimate Edition if you select the Business and Consumer test category.
    • The Ultimate Edition is recommended for testing.
    • The Starter Edition is not supported for logo testing.
  • Windows Server 2003
  • Windows XP


Running Logo Tests for System Submissions

To run the logo tests for a system submission and create a submission package to send to Microsoft for logo approval, perform the following steps:

Note These instructions assume you have followed the DTM setup and installation procedures for both Client and Studio.

To create a new submission and select system logo tests
  1. Switch to the Device Console window, or open a new Device Console window by clicking Explorers and then clicking Device Console.
  2. Select your DTM controller from the list in the upper left corner of the Device Console window.
  3. In the View By field, select the Submission button.

    Note Any submission for qualification through WHQL must select the Submission button.

  4. Select <New Submission> from the Submission list on the right side of the Device Console window, and follow the instructions in the Create New Submission wizard that appears.

    Note If you have an existing submission, you will see the submission name appear in the list. You can select your submission name to continue testing with an existing submission.

  5. Do the following to choose the system logo tests to run:
    1. Select the operating system and processor architecture to test, and then click Next.
    2. Select a submission category, and then click Next.
    3. Select System Submission as your submission category.

      Note For Failover Clusters, please choose Failover Clustering as your submission category. You must have selected a server operating system on the previous screen for the Failover Cluster category to appear.

    4. Select a sub-category of your qualification level (see the following list), and then click Next.
      • Failover Clustering:
        • Failover Cluster Solution
        • Failover Cluster Solution – Geographically Dispersed
        • Failover Cluster Solution – EQP
        • Failover Cluster Solution – EQP – Geographically Dispersed
      • Windows XP:
        • Desktop
        • Mobile
        • Motherboard
      • Windows Server 2003:
        • Standard
        • Supported
      • Windows Vista:
        • Desktop (Business)
        • Desktop (Consumer)
        • Desktop (Business and Consumer)
        • Mobile (Business)
        • Mobile (Consumer)
        • Mobile (Business and Consumer)
        • Motherboard (Business)
        • Motherboard (Consumer)
        • Motherboard (Business and Consumer)
        • Ultra-Mobile (Business)
        • Ultra-Mobile (Consumer)
        • Ultra-Mobile (Business and Consumer)
        • Ultra-Portable (Business)
        • Ultra-Portable (Consumer)
        • Ultra-Portable (Business and Consumer)

        Note After you choose a sub-category for Windows Vista, you must choose a qualification level of Premium or Basic and then click Next.

  6. Enter a name for the submission, and select the machine pool that contains the machine to use for the submission, and then click Next.
  7. Choose the system from the resource pool that will be submitted for a logo, and then click Finish. Any resources that have a matching identifier can be used for testing.

To schedule logo tests
  1. Select the displayed logo tests from the filtered list at the right of the Device Console window.
  2. Click the Add Selected button.
  3. Click the Schedule button.

Note System test that require some manual intervention will have "(Manual)" at the end of the test name.

To monitor logo test progress
  1. Observe logo test progress by using Job Monitor, and manually intervene if required by test. You can force a refresh of the logo tests status in the Device Console window by pressing F5, or clicking View and then Refresh.
  2. Examine the results of a job in the Result Explorer and diagnose the source of any errors. Rerun logo tests if necessary until they pass successfully.
  3. If desired, click on the Submission Status button to apply all applicable Errata and Contingencies through the test results.

After the logo tests have all passed successfully, you can submit the logo test results to Microsoft for approval.


Submitting Logo Test Results

The final step that is required to obtain a “Designed for Microsoft Windows” logo is to submit your successful logo test results to Microsoft’s Windows Hardware Quality Labs (WHQL).

To create a package and submit your logo test results
  1. Right-click the main node in the tree view of the Device Console window and click Create Submission Package.
  2. Select a location and name for the cabinet file (.cab) that contains the results of the successful logo tests.
  3. Click OK to save the file.
  4. Go to the [image] WHQL Web site and follow the instructions to submit your package.

Note You can check on the status of your submission by visiting the WHQL Web site.


System Tests

Test name | Target operating system | Test description
CardBus Bridge Register Test Windows Vista
Windows XP
The CardBus Bridge Register test determines whether the CardBus bridges support all of the registers that are specified in the PCI to PCMCIA CardBus Bridge Register Description standard (Yenta Specification).
RCTester : ehome - Premium System Tests - IR Windows Vista
Verifies that system is capable of supporting premium Media Center IR functionality. Tests SYSFUND-0042.
BitLocker Drive Encryption BIOS Interface Logo Test Windows Vista
         This test validates that the BIOS on this platform meets the Windows Vista BitLocker Drive Encryption feature requirements.
W2K3 MSCS - Run Signed Driver Check | The Signed Driver Check test verifies that all drivers are signed by Windows Hardware Quality Labs (WHQL).
HAL Test Windows Vista
The HALTEST tests high precision event timer (HPET) hardware for logo requirements.
It verifies that:
  • The system under test is using an HPET device.
  • The HPET frequency is between 10 MHz and 500 MHz.
  • The timer does not glitch or run backwards.
You can run the test manually using the command line "haltest.exe timers logo". This is the only supported command line for logo testing.
Debugging test failures requires complete log files. The test will generate a log file called haltest.xml. Please include this file with any questions about failing results. A kernel debugger remote session might also need to be included.
PCI/PCI Express Compliance Test (PCITEST2_1) Windows XP
         The PCI Compliance test (PCITest2.exe) determines whether or not a single PCI device or all relevant PCI devices in a system are compliant with industry standards for PCI devices as well as several specific Microsoft requirements for PCI devices that may exceed requirements in standard PCI related specifications.
System - Common Scenario Stress with IO Windows Vista
Windows XP
The System - Common Scenario Stress with IO job ensures that the system and its devices accept and correctly handle numerous Plug and Play (PnP) and power management state change scenarios. This currently includes disable/enable and suspend/hibernate/wake scenarios. Additionally, it tries to ensure that the devices are still functional after these changes in state through SimpleIO stress testing.
BitLocker Drive Encryption System Partition Validation Test Windows Vista
         This test is required to obtain a logo for Microsoft Windows Vista systems that include the BitLocker Drive Encryption feature. This test makes sure that the disk partitions on the system meet the BitLocker Drive Encryption requirements for Windows Vista.
Storage Device Stress test (SDStress) Windows Vista
Windows XP
         This test stresses the hard disk drives and CD-ROM drives in a system and validates storage API commands.
SCSI Initiator Client Server Windows Vista
Windows XP
Windows 2000
         This test verifies the functionality necessary for Microsoft Cluster Server (MSCS) to change and maintain ownership of the RAID storage disks in the cluster client node. It also verifies the functionality

necessary for multi-initiator host bus adapter (HBA) implementations.
SMBIOS HCT Windows Vista
         Validates system's SMBIOS data.
TVWLPTest - ehome - premium system tests Windows Vista
         This document describes the Vista requirements tested in the 'ehome - premium system tests' job. These tests are all invoked by a program called TVWLPTest and up to four DShow filters it may load.
Verifies that system is capable of supporting premium media center functionality. Tests SYSFUND-0043, and SYSFUND-0064
TVWLPTest - ehome - standard system tests Windows Vista
This document describes the Vista requirements tested in the 'ehome - standard system tests' job. These tests are all invoked by a program called TVWLPTest and up to four DShow filters it may load.
Verifies that system is capable of supporting premium media center functionality. Tests SYSFUND-0043
Data Execution Prevention (DEP) Demo Windows Vista
The Data Execution Prevention (DEP) demo program allows the operator to test if DEP is enabled and supported on the host system.
The DEP demo program does not test system DEP configuration. The DEP demo program simply executes code from a non-executable location causing Microsoft Windows to close the DEP demo program and display a DEP error message.
Additionally, the DEP demo tool accepts a single command-line parameter "/sw" to simulate a software-enforced DEP problem. When the DEP demo program is run with the "/sw" parameter, Windows will close the DEP demo program and display an error message. (Note, software-enforced DEP does not have specific processor requirements.)
Windows support for Data Execution Prevention is available in Windows XP with Service Pack 2 (SP2), Windows Server 2003 with Service Pack 1 (SP1) and Windows Vista.
Hardware-enforced DEP requires one of the above mentioned versions of Windows and a processor that supports the "no-execute" (NX) or "execute disable" (XD) technologies.
DEP can be enabled on Windows using the "/noexecute" boot.ini flag or the "Data Execution Prevention" tab in Performance Options in System under Control Panel.
TCG BIOS DOS Test Tool
This test validates the functions of the TCG Int 1A, sub-function BBh, interface that the BitLocker Drive Encryption (BDE)feature of Microsoft Windows Vista depends on.
NOTE: This test is a test tool intended to speed up TCG BIOS development and does not have to be run to meet a Vista Logo requirement
resstomp Windows Vista
Windows 2000
         This tool ensures that all resources currently in use are correctly reported to the operating system.
W2K3 MSCS - Run MovN
This test verifies that the resource move operation works properly on the cluster.
Resume From Standby Windows Vista
RPAT is a tool that developers, testers and system integrators can use to discover which drivers are creating bottleneck when a system is resuming from S3 standby mode. It analyzes the output from PwrTst and displays statistics for each individual driver.
The tool will help system integrators figure out where to focus their efforts to meet the new Vista resume from standby requirements.
System - Sleep Stress with IO Windows Vista
Windows XP
         This System - Sleep Stress with IO job ensures that the system and its devices can be cycled through all supported sleep states. Additionally, it tries to ensure that the devices is still functional after these changes in state through SimpleIO stress testing.
TCG TPM Integration Test Windows Vista
         This test validates the integration of the Trusted Platform Module (TPM) on the system motherboard and meets the Windows Vista BitLocker Drive Encryption feature requirements.
W2K3 MSCS - Run Phase 1
This tests ensure that drivers, shared hard disks, and other SCSI components correctly implement SCSI Reserve and Release commands. The Cluster service storage device arbitration relies on this mechanism. One initiator will reserve the hard disk, and then commands issued to the hard disk from the other initiator should fail with "Reservation Conflict" status. These tests also ensure that reservations are broken with a bus reset.
WDTF - Common Scenario Stress with IO Windows Vista
Windows XP
         The WDTF - Common Scenario Stress with IO scenario ensures that the system and its devices accept and correctly handle numerous Plug and Play (PnP) and power management state change scenarios. This currently includes disable/enable and suspend/hibernate/wake scenarios. Additionally, it tries to ensure that the devices are still functional after these changes in state through SimpleIO stress testing.
BitLocker Drive Encryption BIOS USB Logo Test Windows Vista
         The BIOS USB Storage test for the BitLocker Driver Encryption (BDE) feature of Microsoft Windows Vista validates that the system BIOS support for USB storage class devices meets the BDE feature requirements.
System - Disable Enable with IO Windows Vista
Windows XP
The System - Disable Enable with IO job disables and then enables every disableable device in the system. Additionally, it tries to ensure that the devices are still functional after these changes in state through SimpleIO stress testing.
Signed Driver Check (CheckLogo) Windows Vista
Windows XP
Windows 2000
         Signed Driver Check (CheckLogo) is a test tool intended to verify drivers that are submitted on logo system submissions have valid logo level signature attributes. This validation ensures that drivers meet the criteria in WLP for the logo program.
Int 13h Extensions test Windows Vista
Windows XP
Windows 2000
The Int 13h Extensions test verifies proper implementation of the Phoenix Int 13h extensions.
Power Management Test Tool (PwrTest) Windows Vista
PwrTest is a test tool that enables developers, testers and system integrators to exercise and record power management information from the system. PwrTest can be used to automate sleep and resume transitions as well as record processor power management and battery information from the system over a period of time.
PwrTest features robust logging and a command-line interface. PwrTest is capable of logging information to both a Windows Test Technologies (WTL) and XML file format.
W2K3 MSCS - Run ValdN | The Validate N Node Cluster test ensures that all cluster operations between nodes, such as move and failover, will work. You need to run this test with all the nodes joined to the cluster intended for validation.


RCTester : ehome - Premium System Tests - IR

Type: Automated Test

Overview

Verifies that system is capable of supporting premium Media Center IR functionality. Tests SYSFUND-0042.

Details

The MCE Remote Control Certification Tool allows the user to test and certify Media Center remote controls. For a remote to be certified, it must satisfy two criteria: All the buttons on the remote must work; all the required buttons must be on the remote.
This test allows users to test individual buttons on their remote, so they can figure out which ones work and which ones don’t. When a button on the remote control is pressed, it checks for the Hid usage and the key associated with it and populate a row with the proper values, as indicated by the column names. If a key fails it populates the name as unassigned (which was not in the design shown here.).

Run Time:
Log File: RCTester.xml ????
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Media Center IR remote control and receiver

Running RCTester : ehome - Premium System Tests - IR

Command Syntax

Command option | Description
RCTester | ???

Code Tour

File Manifest

File | Location
RCTester.exe |

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


BitLocker Drive Encryption BIOS Interface Logo Test

Type: Automated Test

Overview

This test validates that the BIOS on this platform meets the Windows Vista BitLocker Drive Encryption feature requirements.

Details

This is a test of pre-OS functionality.
This test is executed in the pre-OS environment and not on Windows in order to get access to the TCG BIOS interface. The binary Tcgtest.exe is responsible for setting up the test result files and scheduling the Tcgpreos.exe binary in the boot configuration data.
This test will run after a manual reboot. This execution phase might not be visible. As a result, the Boot Manager will display the list of all possible operating systems to start. Proceed back to the operating system in which the test was started, and then call Tcgtest.exe again. The first run of Tcgtest.exe will generate the log with the filename TCGTestPre.xml; the second run of Tcgtest.exe (after the reboot) will generate the log with the filename TCGTestPost.xml. To see which test assertion results are in TCGTestPre.xml and which are in TCGTestPost.xml, see "Test Tool Assertions."
NOTE: BitLocker Drive Encryption has to be turned off or at least cannot be bound to the TPM. Otherwise, the start of the operating system will fail until the system is restarted after the test has been performed.

Run Time: 4 minutes
Log File: TCGTestPre.xml and TCGTestPost.xml (see "Full Description and Theory of Operation")
System Restart Required: Yes
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86

Running BitLocker Drive Encryption BIOS Interface Logo Test

Execute the Job from the DTM framework.
As an alternative, run this test without DTM by following these steps:
1. Make sure that Tcgpreos.exe is in the same directory as Tcgtest.exe.
2. To start the test and initialize the test environment, type the following in the command line:
Tcgtest.exe
3. Upon return to the command line prompt, manually restart the system; test results are determined in the pre-OS phase of this restart.
4. After the system restarts, you can see test results by typing the following in the command line:
Tcgtest.exe

Command Syntax

Command option | Description
tcgtest.exe |
tcgtest.exe | Enter this after system restarts.

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location
tcgtest.exe | [WTT\TestBinRoot]\nttest\basetest\ngscb\biosif
tcgpreos.exe | [WTT\TestBinRoot]\nttest\basetest\ngscb\tools

Click to show or hide information. Test Assertions

Test Assertions

1 Validate that PCR[4] and PCR[5] was extended
Test Assertion GUID: b91958d1-c67c-4ec1-8b0e-e86f74bf6da9

Windows Logo Program: SYSFUND-0031 Systems implementing TPM support BitLocker(TM) Drive Encryption by using system firmware security enhancements

Additional Information:

2 Validate correct recovery from S4 (Hibernate)
Test Assertion GUID: 48c4ebbb-0f73-4e9a-bd8a-9bdc96f7b7da

Windows Logo Program: SYSFUND-0031 Systems implementing TPM support BitLocker(TM) Drive Encryption by using system firmware security enhancements

Additional Information: As part of this test, the system transitions to S4 state for 2 minutes and then resumes from S4.

3 Validate correct recovery from S3 (Suspend)
Test Assertion GUID: 458ba7ac-e574-4109-adcb-5b066ecced31

Windows Logo Program: SYSFUND-0031 Systems implementing TPM support BitLocker(TM) Drive Encryption by using system firmware security enhancements

Additional Information: As part of this test, the system transitions to S3 state for 2 minutes and then resumes from S3.

4 Prepare Environment for PreOS Tests
Test Assertion GUID: E3B099A1-92FA-4491-A611-9BAA4070C970

Windows Logo Program: SYSFUND-0031 Systems implementing TPM support BitLocker(TM) Drive Encryption by using system firmware security enhancements

Additional Information:

5 Validate that TCG Firmware complies with minimum BDE requirements
Test Assertion GUID: d1449ffd-3014-4bc4-8fa5-415bee5f27d0

Windows Logo Program: SYSFUND-0031 Systems implementing TPM support BitLocker(TM) Drive Encryption by using system firmware security enhancements

Additional Information: If this test assertion passes, the following minimum BDE requirements are successful: The platform BIOS implements the TCG-specified INT 1Ah, sub-function BBh interface (BIOS successfully performs TCG_StatusCheck function) The platform BIOS includes a Memory Present driver (BIOS successfully performs TCG_PassThroughToTPM function) BIOS INT 1Ah, sub-function BBh interface successfully reads PCR [16] when commanded to do so BIOS INT 1Ah, sub-function BBh interface successfully resets PCR [16]

6 TCPA ACPI Table Test
Test Assertion GUID: 26af1a0d-2b96-4929-86b6-ee57f4ef0653

Windows Logo Program: SYSFUND-0031 Systems implementing TPM support BitLocker(TM) Drive Encryption by using system firmware security enhancements

Additional Information: If this test assertion passes, the following TCPA ACPI Table requirements are met by the platform BIOS ACPI tables: TCPA ACPI table exists at offset 0x1f701f07 TCPA ACPI table entries are correct (LAML = 0x00010000 and LASA = 0x1f76b000)

7 Validate the consistency of the TCPA EventLog
Test Assertion GUID: 234f708f-296b-4d5b-af7d-41110562808e

Windows Logo Program: SYSFUND-0031 Systems implementing TPM support BitLocker(TM) Drive Encryption by using system firmware security enhancements

Additional Information: The following tests are used to validate the consistency of the TCPA Event Log; all these tests must pass for the test assertion above to pass: Event Log exists and is not empty At least one measurement was made into PCR [4] and that measurement is reflected in the Event Log At least one measurement was made into PCR [5] and that measurement is reflected in the Event Log The values in the digest fields of Event Log entries for PCR [0] through and including PCR [15] successfully lead to the value extended into the matching PCR


W2K3 MSCS - Run Signed Driver Check

Overview

The Signed Driver Check test verifies that all drivers are signed by Windows Hardware Quality Labs (WHQL).

Details

This test runs on the cluster nodes.
Run duration: Approx. 20-30 min

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows 2003
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running W2K3 MSCS - Run Signed Driver Check

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


HAL Test

Type: Automated Test

Overview

The HALTEST tests high precision event timer (HPET) hardware for logo requirements.
It verifies that:
  • The system under test is using an HPET device.
  • The HPET frequency is between 10 MHz and 500 MHz.
  • The timer does not glitch or run backwards.
You can run the test manually using the command line "haltest.exe timers logo". This is the only supported command line for logo testing.
Debugging test failures requires complete log files. The test will generate a log file called haltest.xml. Please include this file with any questions about failing results. A kernel debugger remote session might also need to be included.

Details

Success or failure of the test is determined by the pass/failure count rollup at the end of the haltest.xml log file produced by running the "haltest.exe timers logo" command line. Each subtest within the log file must pass in order for the overall result to be "pass."
Run Time: 5 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running HAL Test

Install test, start test, wait for the test to finish, examine haltest.xml log file for results.

Command Syntax

Command option | Description
haltest timers logo | timers only - HPET validation

Cautions

The system time increment must be set to the default when the test is run. Otherwise, the test will fail. Applications like Windows Media Player or other multimedia applications will interfere with the test.

Troubleshooting

If necessary, dump the stack to see if the test is stuck. It may be possible for the test to hang if the HPET or any other hardware fails to generate interrupts when expected. This is highly unlikely.

Reference Documentation

http://www.microsoft.com/whdc/system/CEC/mm-timer.mspxhttp://www.intel.com/labs/platcomp/hpet/hpetspec.htm

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


System - Common Scenario Stress with IO

Type: Automated Test

Overview

The System - Common Scenario Stress with IO job ensures that the system and its devices accept and correctly handle numerous Plug and Play (PnP) and power management state change scenarios. This currently includes disable/enable and suspend/hibernate/wake scenarios. Additionally, it tries to ensure that the devices are still functional after these changes in state through SimpleIO stress testing.

Details

The System - Common Scenario Stress with IO job is the "System Kit" version of the Common_Scenario_Stress_with_IO automated scenario.
The job directs the underlying scenario to target all possible devices. Additionally, the underlying scenario can only run disable/enable scenarios on disableable devices. A disableable device is defined to be a device that has the "Disable" menu option available in Device Manager and is not class 'LegacyDriver'.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running System - Common Scenario Stress with IO

Command Syntax

Command option | Description

Troubleshooting
The underlying scenario was developed using the new Windows Device Testing Framework (WDTF). The WDK contains extensive documentation for using and extending this framework in your own driver development process. Search the WDK help documentation for "Windows Device Testing Framework" for more information. Details on the specific operation of this scenario can be found in the table of contents under "Windows Driver Kit" -> "Other Tools" -> "Windows Device Testing Framework" -> "Automated Scenarios".

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


BitLocker Drive Encryption System Partition Validation Test

Type: Automated Test

Overview

This test is required to obtain a logo for Microsoft Windows Vista systems that include the BitLocker Drive Encryption feature. This test makes sure that the disk partitions on the system meet the BitLocker Drive Encryption requirements for Windows Vista.

Details

This test tool validates that the system, intended to support BitLocker Drive Encryption (BDE), provides a second hard disk drive (HDD) partition, separate from the Windows partition, that is formatted as NTFS and has at least the amount of reserved space required for BDE files and utilities.
If the system does not support BitLocker Drive Encryption, this test will be skipped.

Run Time: 1 minute
Log File: Test results will be displayed on the screen, but no log file will be generated.
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running BitLocker Drive Encryption System Partition Validation Test

Make sure that the DTM Framework is installed.
As an alternative, run this test without DTM by following these steps:
1. Run the following in the command line: SSSystemPartitionValidation.exe

Command Syntax

Command option | Description
SSSystemPartitionValidation.exe |

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location
SSSystemPartitionValidation.exe | [WTT\TestBinRoot]\nttest\basetest\ngscb\spvlogo

Click to show or hide information. Test Assertions

Test Assertions

1 The system has separate OS Volume from System Volume
Test Assertion GUID: e5b9a556-a689-4b65-adbf-2210b43cc7be

Windows Logo Program: SYSFUND-0032 Systems that provide BitLocker(TM) Drive Encryption BIOS enhancements support BitLocker by reserving 50 MB exclusively for BitLocker utilities, outside the main OS partition

Additional Information:


SMBIOS HCT

Type: Automated Test

Overview

Validates system's SMBIOS data.

Details

This application will gather the SMBIOS data and validate it against the SMBIOS specifications available from the DMTF.
Run Time: less than 1 minute
Log File: smbios.xml
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running SMBIOS HCT

Run smbioshct.exe from the command line.

Command Syntax

Command option | Description
smbioshct.exe -v |

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

SYS-BIOS-18 System BIOS support for SMBIOS complies with the SMBIOS specification.
Test Assertion GUID: 835C141B-8161-4107-B494-1E9ACD49CA71

Windows Logo Program: SYSFUND-0074 System BIOS support for SMBIOS complies with the SMBIOS specification

Additional Information: SMBIOS must comply with the SMBIOS specification.


TVWLPTest - ehome - standard system tests

Type: Automated Test

Overview

This document describes the Vista requirements tested in the 'ehome - standard system tests' job. These tests are all invoked by a program called TVWLPTest and up to four DShow filters it may load.
Verifies that system is capable of supporting premium media center functionality. Tests SYSFUND-0043

Details

TvWLPTest is a command line program invoked by the DTM that verifies most of the Media Center requirements.
This job tests the following requirement:

SYSFUND-0064 (SYS-GLD-4)

Title: Test System with a Tuner Must Enable DMA On All Storage Devices
Success:
This test will succeed if DMA is enabled on all storage devices that include hard drives and CD/DVD-ROMs.
Failure:
This test will fail if DMA is disabled at least on one of storage devises.

Run Time:
Log File: TVWLPTest.xml
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running TVWLPTest - ehome - standard system tests

1) Run the 3 RunMeFirst jobs.
2) Run the job
- this will iterate through the requirement(s) listed above

Command Syntax

Command option | Description
tvwlptest <test case ID> “<Device ID of device you want to test>” |

Cautions

none known

Troubleshooting

If the jobs are too big and hence difficult to debug, run the individual requirement through the DTM as manually scheduled job using the WDKDeviceID parameter and the requirement name (e.g. STREAM-0011) and PnP-ID (50+ character name) as described above in the Alternate Installation Steps.
None known.

Code Tour

File Manifest

File | Location
TVWLPTest.exe |
TVWLPAudioMonitor.ax |
TVWLPSourceFilter.ax |
TVWLPMPeg2Monitor.ax |
TVWLPVBIMonitor.ax |

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Data Execution Prevention (DEP) Demo

Overview

The Data Execution Prevention (DEP) demo program allows the operator to test if DEP is enabled and supported on the host system.
The DEP demo program does not test system DEP configuration. The DEP demo program simply executes code from a non-executable location causing Microsoft Windows to close the DEP demo program and display a DEP error message.
Additionally, the DEP demo tool accepts a single command-line parameter "/sw" to simulate a software-enforced DEP problem. When the DEP demo program is run with the "/sw" parameter, Windows will close the DEP demo program and display an error message. (Note, software-enforced DEP does not have specific processor requirements.)
Windows support for Data Execution Prevention is available in Windows XP with Service Pack 2 (SP2), Windows Server 2003 with Service Pack 1 (SP1) and Windows Vista.
Hardware-enforced DEP requires one of the above mentioned versions of Windows and a processor that supports the "no-execute" (NX) or "execute disable" (XD) technologies.
DEP can be enabled on Windows using the "/noexecute" boot.ini flag or the "Data Execution Prevention" tab in Performance Options in System under Control Panel.

Details

The DEP demo program exercises Windows' support for DEP by executing code from a non-executable memory allocation. The purpose of the tool is to help system integrators and developers to verify that DEP is enabled and to test the various DEP configuration mechanisms within Windows.
Additionally, the DEP demo program has the application name and publisher resources correctly integrated into the executable binary. This allows users to view the DEP application termination experience within Windows with an application at fault that correctly identifies itself and its publisher.
To simulate a hardware-enforced DEP problem (the default method of operation), DEP demo allocates memory without the PAGE_EXECUTE attribute. DEP demo then generates executable code and places it within the memory allocation. Finally, DEP demo attempts to execute the generated code from the non-executable memory allocation. On a system with a processor capable of hardware-enforced DEP and Windows configured to apply DEP to the DEP demo executable, the DEP demo program will be closed by Windows. When the DEP demo program is closed by Windows, an error will be displayed indicating that the Data Execution Prevention Demo program encountered a problem with DEP. The publisher, "Microsoft Corporation" will be clearly identified.
To simulate a software-enforced DEP failure, DEP demo creates an exception handler in a non-executable memory region and ensures that the exception handler is attempted to be executed. When Windows attempts to execute the non-executable exception handler, the DEP demo program will be closed and the same message will be displayed as in the hardware-enforced DEP case.
To simulate a software-enforced DEP failure, the DEP demo tool must be run from the command line with the "/sw" parameter.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Service Pack 2 for Windows XP and Service Pack 1 for Windows Server 2003 are required

Hardware Requirements

  • Computer that meets the minimum software requirements

    • Processor

  • x86
  • x64
  • Itanium
  • Requires a processor with the NX (or XD) functionality to simulate a hardware-enforced DEP problem.
  • To simulate a hardware-enforced DEP failure, a processor with the "no execute" (NX) or "execute disable" (XD) feature is required.

Running Data Execution Prevention (DEP) Demo

Command Syntax

Command option | Description
/sw | Simulates a software-enforced DEP problem

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


TCG BIOS DOS Test Tool

Overview

This test validates the functions of the TCG Int 1A, sub-function BBh, interface that the BitLocker Drive Encryption (BDE)feature of Microsoft Windows Vista depends on.
NOTE: This test is a test tool intended to speed up TCG BIOS development and does not have to be run to meet a Vista Logo requirement

Details

This TCG BIOS development test tool is shipped in the WDK as a pre-compiled, 16-bit DOS application that must be copied to a removable media system boot device before the test can be run. The system under test is then booted from this removable media to run the test. For more information, see "Test Tool Procedure Details."

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • MS-DOS
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • BIOS that implements the TCG-specified INT 1Ah, sub-function BBh, interface

Running TCG BIOS DOS Test Tool

Part 1 -- How to install and run the test:

=========================

Step 1: Copy the tcgbios.exe binary to a removable boot device. The removable boot device options are to copy the tcgbios.exe file to an MS-DOS floppy, a CD-ROM or DVD that emulates an MS-DOS floppy, or a USB removable storage device that boots the system to a DOS prompt.
Step 2: Boot the system under test. Boot the system from the removable boot device that you created in Step 1 and that contains the tcgbios.exe file.
Step 3: Run the test to make sure BIOS does not hang. At the DOS prompt, enter “tcgbios.exe”; if the test returns with a DOS prompt, go to step 4.
Step 4: Run the test to get a test results log.
Step 4a: Reboot the system from the removable boot device that contains the tcgbios.exe file
Step 4b: At the DOS prompt, enter “tcgbios.exe > tcgbios.log (NOTE: If you used a read-only optical media for the removable boot device that contains the tcgbios.exe file, you will have to redirect the output log to a writable media)
Step 5: Interpret the test results log. Look at the last page of the test results log. If all tests passed, the last entry will read:
**** Tests complete ****

All tests passed!
IMPORTANT: You have to reboot the system in order to re-run the test.
Part 2 -- How to do a more detailed interpretation of the test results log

==============================================

To fully interpret the test results log, you will need the TCG PC Client Implementation for Conventional BIOS Spec, particularly section 12, Application Level Interface, and the TCG TPM Main Specification, particularly Part 3, in front of you. These specs can be downloaded from the TCG public website http://www.trustedcomputinggroup.org
The test results log is subdivided into the following parts, in sequence, from beginning to end:
**** StatusCheck ****
**** Read PCR ****

**** Extend PCR ****
**** Hash All ****
**** CompactHashLogExtendEvent ****
**** ShutdownPreBootInterface ****
The rest of this readme file gives more details about each of these major parts of the test.

More about the '**** StatusCheck ****' test

---------------------------------------------------------

This part of the test is the first call to the BIOS TCG INT 1Ah, sub-function BBh, application interface. This test verifies general information about the BIOS implementation of the interface by calling the TCG_StatusCheck function (see section 12.5 of the TCG BIOS specification):
(a) The BIOS implements the v1.2 INT 1Ah, sub-function BBh, application interface; if EAX = 0 upon return from this call, the system supports the TCG BIOS calls required by BitLocker.

(b) The BIOS implements v1.2 of the interface that is required by BitLocker; if CH = 01 and CL = 02, then this BIOS implements v1.2.
This part of the test also validates:

(c) The BIOS implements, specifically, the TCG_StatusCheck function; if CF = 0, then this BIOS implements that function.

(d) An indication that the BIOS implements event logging; if EDI <> 0 and EDI <> ESI, then this indicates the BIOS implements event logging.
If this test passes, the results in the log will be as shown below (NOTE: The values shown for ESI and EDI are examples only; the important thing is that EDI <> 0 and EDI <> ESI).

PASS: EAX = 0 Call succeeded!

PASS: Carry flag not set

PASS: TCG BIOS Version in CX is 01.02

PASS: Event Log (ESI) = 0x1f582f9a (NOTE: this is just an example value for ESI)

PASS: Last Log entry (EDI) is at 0x1f5842f0 (NOTE: this is just an example value for EDI)

PASS: Feature flag is 0x00000000
More about the '**** Read PCR ****' test

---------------------------------------------------------

This part of the test is a sequence of calls to the TCG_PassTroughToTPM function (see section 12.7 of the TCG BIOS Spec) that reads the values of PCR 0 through 5 and the values of PCR 8 through 16 from the TPM; each call to TCG_PassThroughToTPM returns the value of one PCR.
This test executes at a step in the boot process that a TCG compliant BIOS should have measured pre-OS code and data components into PCRs 0, 1, 2, 3, 4, and 5 and kept PCRs 8, 9, 10, 11, 12, 13, 14, 15, and 16 cleared; so this test checks for non-zero values in PCR 0 through 5 and zero values in PCR 8 through 16. For more information, see sections 3.2.3, 3.2.3.1, 3.2.3.2, 3.2.3.3, 3.2.3.4, 3.2.3.5, 3.2.3.6, and 3.2.3.9 of the TCG BIOS Spec.
If this test passes, then the sequence of test results are shown below (NOTE: The values shown for the 20-byte values read from each PCR are examples only and just show the first two bytes and last two bytes of the 20 byte value).
PASS: ReadPCR call succeeded

PASS: BIOS is extended in PCR[00]=42f6 ... 310f
PASS: ReadPCR call succeeded

PASS: NVRAM is extended in PCR[01]=e7dd ... d2f0
PASS: ReadPCR call succeeded

PASS: OptionROM is extended in PCR[02]=39d5 ... 1922
PASS: ReadPCR call succeeded

PASS: OptionROM data is extended in PCR[03]=3a3f ... 2275
PASS: ReadPCR call succeeded

PASS: IPL is extended in PCR[04]=ef92 ... 4dff
PASS: ReadPCR call succeeded

PASS: IPL data is extended into PCR[05]=3a3f ... 2275
PASS: ReadPCR call succeeded

PASS: Static OS PCR[08] is clear
PASS: ReadPCR call succeeded

PASS: Static OS PCR[08] is clear
PASS: ReadPCR call succeeded

PASS: Static OS PCR[09] is clear
PASS: ReadPCR call succeeded

PASS: Static OS PCR[10] is clear
PASS: ReadPCR call succeeded

PASS: Static OS PCR[11] is clear
PASS: ReadPCR call succeeded

PASS: Static OS PCR[12] is clear
PASS: ReadPCR call succeeded

PASS: Static OS PCR[13] is clear
PASS: ReadPCR call succeeded

PASS: Static OS PCR[14] is clear
PASS: ReadPCR call succeeded

PASS: Static OS PCR[15] is clear
PASS: ReadPCR call succeeded

PASS: Debug PCR[16] is clear
More about the '**** Extend PCR ****' test

---------------------------------------------------------

This test uses the TCG_PassThroughToTPM function and the TCG_HashAll function (see section 12.10 of the TCG BIOS Spec) to validate that the extension of a PCR with the hash value of a buffer full of data works correctly. PCR[16] is used for this test.
This test has 4 sequential steps:

1. Call TCG_PassThroughToTPM to read initial value of PCR 16; this step passes if PCR 16 is clear

2. Call TCG_PassThroughToTPM to extend PCR 16 with the hash of the contents of a data buffer; the extended value is returned

3. Call TCG_HashAll to hash the contents of the same data buffer and then compare the result with the extended value returned in step 2

4. Call TCG_PassThroughToTPM to clear PCR 16
If this test passes, then the sequence of test results are shown below (NOTE: The values shown for 20-byte hash values are examples only and just show the first two bytes and last two bytes of the 20 byte value).
PASS: Read initial value of PCR[16], it is cleared
PASS: Extended PCR[16]=ccd5 ... 5acf
PASS: Expected PCR[16]=ccd5 ... 5acf

PASS: PCR[16] extended correctly
PASS: PCR[16] cleared
More about the '**** HashAll ****' test

---------------------------------------------------------

This test calls the TCG_HashAll function three times. For each call, the contents and length of the data buffer to be hashed are different, but known, values. This enables the test code to compare the hash value returned by each TCG_HashAll function call with an expected correct result.
If this test passes, then the sequence of test results is:
PASS: Test vector correct

PASS: Test vector correct

PASS: Test vector correct
More about the '**** CompactHashLogExtendEvent ****' test

---------------------------------------------------------

This test validates the TCG_CompactHashLogExtendEvent function is implemented correctly by the BIOS.
This test has 5 sequential steps:

1. Call TCG_PassThroughToTPM to read the initial value of PCR 16; this step passes if PCR 16 is clear

2. Call TCG_HashLogExtendEvent to extend the hash value of known data buffer into PCR 16; this step passes if the function returns a non-zero event log entry number in edx, which indicates that the function created the required EV_COMPACT_HASH Event Type event log entry

3. Call TCG_HashAll to hash the data buffer used in step 2, this is the value that the TCG_HashLogExtendEvent function should have extended into PCR 16 in step 2

4. Call TCG_PassThroughToTPM to read the current value of PCR 16; this step passes if this value is equal to the hash value calculated in step 3

5. Call TCG_PassThroughToTPM to clear PCR 16
If this test passes, then the sequence of test results are shown below (NOTE: The values shown for 20-byte hash values are examples only and just show the first two bytes and last two bytes of the 20 byte value).
PASS: Read initial value of PCR[16], it is cleared
PASS: Event has ID 1 (NOTE: '1' is just an example, this may be any non-zero value)
PASS: Expected PCR[16]=ccd5 ... 5acf
PASS: Read PCR[16]=ccd5 ... 5acf

PASS: PCR[16] extended correctly
PASS: PCR[16] cleared
More about the '**** ShutdownPreBootInterface ****' test

---------------------------------------------------------

This test validates that the TCG_ShutdownPreBootInterface function (see section 12.8 of the TCG BIOS Spec).
This test has three sequential steps:

1. Call TCG_StatusCheck to ensure that the INT 1Ah, sub-function BBh interface has not been shutdown before this test is run

2. Call TCG_ShutdownPreBootInterface and check its return parameters for success

3. Call TCG_StatusCheck to ensure the INT 1Ah, sub-function BBh interface, is no longer callable
If this test passes, then the sequence of test results are shown below.
PASS: TCG API Present
PASS: Shutdown successful
PASS: TCG API no longer present

Command Syntax

Command option | Description

Code Tour

File Manifest

File | Location
tcgbios.exe | [WTT\TestBinRoot]\nttest\basetest\ngscb\tools

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


resstomp

Overview

This tool ensures that all resources currently in use are correctly reported to the operating system.

Details

This tool creates a tree of in-use resources that the OS has been informed of. Using this information, it creates a list of free ranges that have not been assigned. The tool then calls into the kernel portion of the test, which maps the physical address and issues a read request. If no hardware claims the read, 0xFFFFFFFF is returned and the test continues to the next address. If anything else is returned, then a piece of hardware is decoding that address and has not told the OS that the address is in use. This can lead to indeterminate results if windows assigns that "free" address to another piece of hardware and 2 devices share the same range.
NOTE: Some chipsets can generate a machine-check if a read request is issued to an address that is not decoded. Do not run this test on a machine in production.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Windows 2000
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86

Running resstomp

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID: D0FFD18A-A7B4-4106-9C11-9DA6158E439E


W2K3 MSCS - Run MovN

Overview

This test verifies that the resource move operation works properly on the cluster.

Details

The Move N Node Cluster test ensures that the resource move operation, the most common operation, works properly.
Run time: approximately 24 hours
Log File name: Movn.log

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows 2003
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running W2K3 MSCS - Run MovN

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Resume From Standby

Overview

RPAT is a tool that developers, testers and system integrators can use to discover which drivers are creating bottleneck when a system is resuming from S3 standby mode. It analyzes the output from PwrTst and displays statistics for each individual driver.
The tool will help system integrators figure out where to focus their efforts to meet the new Vista resume from standby requirements.

Details

RPAT
Usage:
rpat.exe [-f] [-i infile] [-o outfile]
flag | result
-f | Force overwrite of the output file if it exists
-i infile | Produce a report based on the contents of infile. Infile is a .etl file generated by pwrtst.exe. By default, rpat uses pwrtest.etl
-o outfile | Save the report to outfile. By default, rpat.exe creates a report called Summary.html
-h | Display help and exit
The report is divided into four major sections
  • header
  • device durations
  • device timeline
  • driver duration
Header:
The header gives the overall statistics for the Resume session contained in the .etl file:
Device durations:
The Device durations sections describes how long each specific device took to resume from standby. This list is ordered from the slowest device to the fastest.
(the bars on the right are clipped)
You can see here that, as is typical, the graphics controller took the longest to resume.
Clicking on a device name takes you to a summary of which drivers were using the device, how much time each one took and the dependencies between them. For example, clicking on the "USB Mass Storage Device" link, above, you get:
In the above diagram, you can see that the last two operations blocked on "usbhub.sys"
Important Note: The graphs for the individual graphs are normalized. The bar will extend across the page, regardless of how many ms the operation took. The chart shows relative time spent.
Device Timeline:
This graph shows the same information as the section, above, but it is ordered chronologically rather than by the time that each device took. This shows which devices depended on each other and the order in which they came back from suspend. They are similar in format to the graph, above.
The above except shows that the the System board device took negligible time to resume from standby but, as expected, blocked on the ACPI-Compliant System. Clicking on a hyperlink takes you to the same device summary as in the Device Duration part of the tool.
Driver Duration
The final, major section in the document is the Driver durations. This is the same format as the device durations but it shows the cumulative time that the system spent in each driver. This could be caused by several devices.
Here we see that the USB driver took the most time in system resume. The blank space is caused when a driver does not have a friendly name. This is a bug and will be fixed in the next release.

Run Time: 5 min
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running Resume From Standby

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


System - Sleep Stress with IO

Type: Automated Test

Overview

This System - Sleep Stress with IO job ensures that the system and its devices can be cycled through all supported sleep states. Additionally, it tries to ensure that the devices is still functional after these changes in state through SimpleIO stress testing.

Details

The System - Sleep Stress with IO job is the "System Kit" version of the Sleep_Stress_with_IO automated scenario.
The job directs the underlying scenario to target all possible devices for SimpleIO testing.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running System - Sleep Stress with IO

Command Syntax

Command option | Description

Troubleshooting
The underlying scenario was developed using the new Windows Device Testing Framework (WDTF). The WDK contains extensive documentation for using and extending this framework in your own driver development process. Search the WDK help documentation for "Windows Device Testing Framework" for more information. Details on the specific operation of this test tool can be found in the table of contents under "Windows Driver Kit" -> "Other Tools" -> "Windows Device Testing Framework" -> "Automated Scenarios".

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


TCG TPM Integration Test

Type: Automated Test

Overview

This test validates the integration of the Trusted Platform Module (TPM) on the system motherboard and meets the Windows Vista BitLocker Drive Encryption feature requirements.

Details

This is a test of the TCG system integration. This test is run after a full boot and exercises the TPM and BIOS base, including the setting of physical presence, taking ownership of the TPM, and ACPI interfaces.
The binary file Tpmsysint.exe runs all of the tests in user mode and the binary Protecttpmdriver.exe removes security restrictions on the TPM driver to allow raw communication via a TDDL layer.

Run Time: 7 to 15 minutes
Log File: TPMSysInt.xml
System Restart Required: Yes
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • TPM-aware BIOS

Running TCG TPM Integration Test

Run the Job in the DTM Framework
As an alternative, to run this test without DTM, make sure Wttlog.dll is in the path, and then:
1. To enable the test environment, type the following in the command line: protecttpmdriver.exe --false
2. After the system is restarted, to run the test, type the following in the command line: tpmsysint.exe
3. After the test has completed, disable the test environment and restart the system by typing the following in the command line: protecttpmdriver.exe --true

Command Syntax

Command option | Description
protecttpmdriver.exe --false | Restarts the system
tpmsysint.exe |
protecttpmdriver.exe --true | Restarts the system

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location
tddl.dll | [WTT\TestBinRoot]\nttest\basetest\ngscb\tpminteg
tpmsysint.exe | [WTT\TestBinRoot]\nttest\basetest\ngscb\tpminteg
protecttpmdriver.exe | [WTT\TestBinRoot]\nttest\basetest\ngscb\tools

Click to show or hide information. Test Assertions

Test Assertions

1 v1.2 TPM driver loaded successfully
Test Assertion GUID: 97F58D25-D7E9-3323-D6D6-E051445454A9

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

2 v1.2 TPM driver successfully unloaded and reloaded
Test Assertion GUID: 97F58D25-D7E9-3323-D6D6-E051445454AA

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

3 TPM starts up when commanded to do so.
Test Assertion GUID: 1E2EC9C1-1C7E-4859-B68E-0EDEBEA337CE

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

4 TPM saves its state when commanded to do so.
Test Assertion GUID: 0424B1D2-5CBB-41ed-BC11-95D33A9C1EEB

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

5 After completing initial set of self tests, TPM resumes self-testing and completes the full set of self tests.
Test Assertion GUID: 1279C6D2-A34E-4c87-A5FD-846F102C22F3

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

6 TPM returns self-test results when commanded to do so.
Test Assertion GUID: 1279C6D2-A34E-4c87-A5FD-846F102C22F3

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

7 TPM responds correctly to a second command to resume self-testing and to complete the full set of self tests.
Test Assertion GUID: F9D6B5E5-05AB-4fc6-8768-EC1F1D147B9A

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

8 System owner can take ownership of the TPM (establish a TPM owner password).
Test Assertion GUID: BFD077B4-3D11-4a84-9DCF-A4FB27B44887

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

9 TPM generates a random number when commanded to do so.
Test Assertion GUID: F3C5A408-D269-476c-A922-957ECA4C89B0

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

10 TPM wraps a key when commanded to do so.
Test Assertion GUID: D8B98116-8DAA-4986-9693-BA413B8ED82C

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

11 TPM loads a key when commanded to do so.
Test Assertion GUID: 0116C1CD-5695-4837-985F-50ED2146DE35

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

12 TPM successfully performs a seal with wrap key when commanded to do so.
Test Assertion GUID: D7A03DF3-576F-484d-8BC9-B6C615376B3A

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

13 TPM successfully performs an unseal with wrap key when commanded to do so.
Test Assertion GUID: C2BAEB50-72EE-4331-9DF6-5CFEB2FA45CE

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

14 TPM successfully performs an unseal with wrap key and PCRs when commanded to do so.
Test Assertion GUID: 8890B7D8-C5B7-425c-90E0-36674303E42F

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

15 TPM successfully performs an unseal with wrap key and PCRs, using TPM_PCR_SHORT data structure.
Test Assertion GUID: 3169E98E-32FB-4044-82FB-C40D05920C28

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

16 TPM successfully completes a seal operation using the Storage Root Key (SRK).
Test Assertion GUID: 38FAD3FF-36A6-4da4-B070-304479E351E2

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

17 TPM generates a random number when commanded to do so a second time.
Test Assertion GUID: E0F56AEF-DF9A-4ca5-AC35-688802FF888D

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

18 TPM reads PCRs.
Test Assertion GUID: 24827510-ECB4-45a1-AE54-5F151007180D

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

19 TPM extends PCRs.
Test Assertion GUID: 79C9A00E-5891-42a3-AC5E-A0630CA6EA88

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

20 BIOS Physical Presence Interface accepts Enable operation TPM operation request
Test Assertion GUID: FAD3BC46-3DF1-4d13-A1D2-91DBD410921E

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

21 BIOS Physical Presence Interface accepts Disable TPM operation request
Test Assertion GUID: FAD3BC46-3DF1-4d13-A1D2-91DBD410921F

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

22 BIOS Physical Presence Interface accepts Activate TPM operation request
Test Assertion GUID: FAD3BC46-3DF1-4d13-A1D2-91DBD4109220

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

23 BIOS Physical Presence Interface accepts Deactivate TPM operation request
Test Assertion GUID: FAD3BC46-3DF1-4d13-A1D2-91DBD4109221

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

24 BIOS Physical Presence Interface accepts Clear TPM operation request
Test Assertion GUID: FAD3BC46-3DF1-4d13-A1D2-91DBD4109222

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

25 BIOS Physical Presence Interface accepts Enable+Activate TPM operation request
Test Assertion GUID: FAD3BC46-3DF1-4d13-A1D2-91DBD4109223

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

26 BIOS Physical Presence Interface accepts Disable+Deactivate TPM operation request
Test Assertion GUID: FAD3BC46-3DF1-4d13-A1D2-91DBD4109224

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

27 BIOS Physical Presence Interface accepts SetOwnerInstall_True TPM operation request
Test Assertion GUID: FAD3BC46-3DF1-4d13-A1D2-91DBD4109225

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

28 BIOS Physical Presence Interface accepts SetOwnerInstall_False TPM operation request
Test Assertion GUID: FAD3BC46-3DF1-4d13-A1D2-91DBD4109226

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

29 BIOS Physical Presence Interface accepts Enable+Activate+SetOwnerInstall_True TPM operation request
Test Assertion GUID: FAD3BC46-3DF1-4d13-A1D2-91DBD4109227

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

30 BIOS Physical Presence Interface accepts Disable+Deactivate+SetOwnerInstall_False TPM operation request
Test Assertion GUID: FAD3BC46-3DF1-4d13-A1D2-91DBD4109228

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

31 BIOS Physical Presence Interface accepts optional SetTempDeactivated TPM operation request
Test Assertion GUID: FAD3BC46-3DF1-4d13-A1D2-91DBD4109229

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

32 BIOS Physical Presence Interface accepts optional SetOperatorAuth TPM operation request
Test Assertion GUID: FAD3BC46-3DF1-4d13-A1D2-91DBD410922A

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

33 BIOS Physical Presence Interface accepts Clear+Enable+Activate TPM operation request
Test Assertion GUID: FAD3BC46-3DF1-4d13-A1D2-91DBD410922B

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

34 BIOS Physical Presence Interface successfully clears any previous TPM operation request
Test Assertion GUID: FAD3BC46-3DF1-4d13-A1D2-91DBD410922C

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

35 BIOS Physical Presence Interface returns the version of the Physical Presence Interface supported by the platform
Test Assertion GUID: FAD3BC46-3DF1-4d13-A1D2-91DBD410922D

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

36 BIOS Physical Presence Interface returns the platform-specific action OS should use to transition the system to the BIOS for execution of a requested TPM operation
Test Assertion GUID: FAD3BC46-3DF1-4d13-A1D2-91DBD410922E

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

37 BIOS Physical Presence Interface returns the most recent request it received and its response to that request
Test Assertion GUID: FAD3BC46-3DF1-4d13-A1D2-91DBD410922F

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:

38 Port IO Mode not detected
Test Assertion GUID: FAD3BC46-3DF1-4d13-A1D2-91DBD4209000

Windows Logo Program: SYSFUND-0030 Systems implementing support for BitLocker(TM) Drive Encryption use TPM v1.2, or later

Additional Information:


W2K3 MSCS - Run Phase 1

Overview

This tests ensure that drivers, shared hard disks, and other SCSI components correctly implement SCSI Reserve and Release commands. The Cluster service storage device arbitration relies on this mechanism. One initiator will reserve the hard disk, and then commands issued to the hard disk from the other initiator should fail with "Reservation Conflict" status. These tests also ensure that reservations are broken with a bus reset.

Details

In Phase 1, each process creates a standard Microsoft Windows NT log file with the results from the test. The "Cluster N Node Test Server" process creates log files named NnodeSim_Server.log. There will be one of these files on each node that participated in the test. The "Cluster N Node Test Client" process creates 2 log files: a log file named NnodeSim_Server.log and one named NnodeSim_Client.log.
Run time: Dependent on the number of LUN's. More LUN's equals more time. Typically 24hrs
Log File name: Nnodesim_client.log, Nnodsim_server.log

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows 2003
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running W2K3 MSCS - Run Phase 1

Schedule job "W2K3 MSCS - Run Phase 1" against the machine pool you created. Once the test UI appears in each of the nodes:
You need to designate one of the nodes to act as a client and the rest as servers:
On node 1 (acting as the client):
On the "Installed Test Categories" list, under the “Cluster Servers – ALL: Cluster Servers”, then click the "Manual Tests" plus box, if closed.
Under the “Manual Tests” list, select "Client Server Phase 1: Client". Click the "Add Selection" button. Double-click the text “’This system is a client’ Disks (Don’t Change)=/t Number of Computers=/c:4” under the plus box and change Parameter 2 (“Number of Computers”) to the exact number of systems having the shared storage bus. If the number of systems is 4, as in a 4-node cluster, then of course leave this value alone.
Click OK.
Click the "Start Tests" button. This will start 2 processes (and 2 command windows). One process is the "Cluster N Node Test Client", "the other is the Cluster N Node Test Server".
Then, on all other nodes (acting as severs):
On the "Available Tests" list, under the “Cluster Servers – ALL: Cluster Servers”, select the "Manual Tests" plus box, if closed.
Under the “Manual Tests” list, select "Client Server Phase 1: Server".
Click the "Add Selection" button.
Click the "Client Server Phase 1: Server" plus box under "Selected Tests".
Double-click the text “’This system is Server’ Disks (Don’t Change)=/t Client Name=/s:ClientName” under the plus box and change Parameter 2 ("ClientName") to the name of the computer serving as the test client (in this example, node 1.) Be sure not to erase the /s: in front of the ClientName you specify.
Click OK.
Click the "Start Tests" button. This will start 1 process and 1 command window. The process is the Cluster N Node Test Server.

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WDTF - Common Scenario Stress with IO

Overview

The WDTF - Common Scenario Stress with IO scenario ensures that the system and its devices accept and correctly handle numerous Plug and Play (PnP) and power management state change scenarios. This currently includes disable/enable and suspend/hibernate/wake scenarios. Additionally, it tries to ensure that the devices are still functional after these changes in state through SimpleIO stress testing.

Details

By default the WDTF - Common Scenario Stress with IO scenario attempts to target all possible devices. However, it can only run disable/enable scenarios on disableable devices . A disableable device is defined to be a device that has the "Disable" menu option available in Device Manager and is not class 'LegacyDriver'.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running WDTF - Common Scenario Stress with IO

Command Syntax

Command option | Description

Troubleshooting
This scenario was developed using the new Windows Device Testing Framework (WDTF). The WDK contains extensive documentation for using and extending this framework in your own driver development process. Search the WDK help documentation for "Windows Device Testing Framework" for more information. This documentation can be found in the table of contents under "Windows Driver Kit" -> "Other Tools" -> "Windows Device Testing Framework".

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


BitLocker Drive Encryption BIOS USB Logo Test

Type: Automated Test

Overview

The BIOS USB Storage test for the BitLocker Driver Encryption (BDE) feature of Microsoft Windows Vista validates that the system BIOS support for USB storage class devices meets the BDE feature requirements.

Details

This test tests both operating system and pre-operating system functionality:
  1. In the operating system environment, system write operations to a USB mass storage class device are tested.
  2. In the pre-operating system environment, system BIOS read operations from a USB mass storage class device are tested.

Run Time: 5 minutes
Log File: FveUsbPreTest.xml & FveUsbPostTest.xml
System Restart Required: Yes
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running BitLocker Drive Encryption BIOS USB Logo Test

  • Run the job from the DTM environment.
  • Alternatively, run this test manually by following these steps:
    1. Copy the three test files to a local directory.
    2. Make sure the BIOS boot order on the computer is not set to boot from a USB device.
    3. Insert the USB storage device .
    4. Run FveUsbPreTest.exe.
    5. Restart the computer. During the restart, FveUsbTest.exe will be run.
    6. After the computer restarts, run FveUsbTest.exe.

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location
FveUsbPreTest.exe | [WTT\TestBinRoot]\nttest\basetest\ngscb
FveUsbTest.exe | [WTT\TestBinRoot]\nttest\basetest\ngscb
FveUsbPostTest.exe | [WTT\TestBinRoot]\nttest\basetest\ngscb

Click to show or hide information. Test Assertions

Test Assertions

1 BIOS USB write operation succeeds
Test Assertion GUID: 33E37DCE-57BE-11DA-8BDE-F66BAD1E3F3A

Windows Logo Program: SYSFUND-0069 Systems support BitLocker(TM) Drive Encryption by providing system firmware support for writing to and reading from USB flash devices in the pre-operating system environment

Additional Information:

2 BIOS USB read operation succeeds
Test Assertion GUID: 64834B74-5BD0-11DA-8BDE-F66BAD1E3F3A

Windows Logo Program: SYSFUND-0069 Systems support BitLocker(TM) Drive Encryption by providing system firmware support for writing to and reading from USB flash devices in the pre-operating system environment

Additional Information:


System - Disable Enable with IO

Type: Automated Test

Overview

The System - Disable Enable with IO job disables and then enables every disableable device in the system. Additionally, it tries to ensure that the devices are still functional after these changes in state through SimpleIO stress testing.

Details

The System - Disable Enable With IO job is the "System Kit" version of the "Disable_Enable_With_IO" automated scenario.
This job directs the underlying scenario to target all possible devices. Additionally, the underlying scenario can only target disableable devices and it cannot target devices of class 'LegacyDriver'. A disableable device is defined to be a device that has the "Disable" menu option available in Device Manager.

Run Time: 2 Hours
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP

Hardware Requirements

  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running System - Disable Enable with IO

Command Syntax

Command option | Description

Troubleshooting
The underlying scenario was developed using the new Windows Device Testing Framework (WDTF). The WDK contains extensive documentation for using and extending this framework in your own driver development process. Search the WDK help documentation for "Windows Device Testing Framework" for more information. Details on the specific operation of this test tool can be found in the table of contents under "Windows Driver Kit" -> "Other Tools" -> "Windows Device Testing Framework" -> "Automated Scenarios".

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Signed Driver Check (CheckLogo)

Type: Automated Test

Overview

Signed Driver Check (CheckLogo) is a test tool intended to verify drivers that are submitted on logo system submissions have valid logo level signature attributes. This validation ensures that drivers meet the criteria in WLP for the logo program.

Details

1) Down level (legacy) OS driver validation

Submissions for XP and Server 2003 need to validate signatures, we currently have working test in the HCT – we need to port this functionality to WTT format and integrate into the DTM
2) Standard level Logo submission -

Submissions submitted for standard level logo should check drivers for logo signature for available logo programs and DRS signature for drivers that do not have a logo program. Inbox drivers are valid in this scenario for this test.
3) Premium Level Logo submission –

Submissions submitted for premium Level logo need to check drivers for premium level logo attribute (WLP A.1.1.1.1) for all available logo programs with premium logo availability. Inbox drivers are valid in this scenario.
4) Stand Alone Execution

The test job(s) need to be available outside of the DTM for customers to run independently to verify driver level signatures.
5) Server device qualification

Need to differentiate between Server device logo and Client device logo for Audio, Video, Net, and Storage. Audio and video have reduced requirements while Net and Storage have increased requirements for Server.

Run Time: 10 min
Log File: chklogo6.wtl
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Windows 2000

Hardware Requirements

  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running Signed Driver Check (CheckLogo)

Command Syntax

Command option | Description
chklogo6.exe /WTT | chklogo6.exe [/WTT] [/PREMIUN] [/XP] [/2003]

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

Premium Logo System includes components and drivers that comply with the Premium Logo requirements for Windows Logo Program 3.0
Test Assertion GUID: 50DFE8F1-0C32-4902-A162-4383354C38B8

Windows Logo Program: SYSFUND-0001 Premium system contains premium-logo qualified devices if there is a premium testing program for the device

Additional Information:

System includes components and drivers that comply with Windows Logo Program 3.0
Test Assertion GUID: 86B42B8C-F9D4-46c6-B98B-29F5443DFA00

Windows Logo Program: SYSFUND-0002 System includes components and drivers that comply with Windows Logo Program 3.0

Additional Information:


Power Management Test Tool (PwrTest)

Overview

PwrTest is a test tool that enables developers, testers and system integrators to exercise and record power management information from the system. PwrTest can be used to automate sleep and resume transitions as well as record processor power management and battery information from the system over a period of time.
PwrTest features robust logging and a command-line interface. PwrTest is capable of logging information to both a Windows Test Technologies (WTL) and XML file format.

Details

Introduction
PwrTest is a test tool that enables developers, testers and system integrators to exercise and record power management information from the system. PwrTest can be used to automate sleep and resume transitions as well as record processor power management and battery information from the system over a period of time.
PwrTest features robust logging and a command-line interface. PwrTest is capable of logging information to both a Windows Test Technologies (WTL) and XML file format.
PwrTest functionality is separated into scenarios. Currently, PwrTest supports the following scenarios:
  • SLEEP
    • Exercises sleep and resume transition functionality. Sleep/resume transitions can be automated and target sleep states can be specified.
  • PPM
    • Displays and records processor power management (PPM) information and metrics. Performance (ACPI P states) and processor idle (ACPI C states) state information can be logged for a period of time at a specified interval.
  • BATTERY
    • Displays and records battery information and metrics. Battery capacity, voltage, rate of drain and estimated life time remaining can be logged for a period of time at a specified interval.
  • INFO
    • Displays system power management information, such as available sleep states and processor power management capabilities.
Command-Line Arguments
PwrTest functionality and scenarios can be accessed through the command-line. The basic usage for PwrTest is:
usage: PwrTest /scenario [-l:path]
scenario indicates the test scenario
  sleep    for sleep/resume transition testing
  ppm       for processor power management testing
  battery   for battery information testing
  info      for system capabilities  information
path indicates the logfile path
  For example, c:\logfile.xml
  Default is .\PwrTest.xml
The logfile path can be specified as the name of the target file in the current directory, or as the path and target file in another directory. PwrTest will automatically generate an XML and WTL version of the log with the same file name and “.XML” or “.WTL” appended at the end of the file name.
To learn more about each of the PwrTest scenarios, type:
      PwrTest /<scenario> /?
Log File Information
PwrTest supports both XML and WTL log file formats. By default, PwrTest will generate both the XML and WTL logs named “PwrTestlog.xml” and “PwrTestlog.wtl”, respectively. These files will be generated in the current directory.
You can use the –l:path argument to specify a different path and file name for the PwrTest log files. For example, -l:\\server\share\PwrTest_today\run will generate the files run.xml and run.wtl in the folder \\server\share\PwrTest_today\ .
The WTL log file format is common to all Windows Driver Kit (WDK) tools that use the WTTlog interface. The WTL log file format is described at: <insert link>.
The PwrTest XML log file format is described in detail with the scenario information below. However, all PwrTest XML log files have the following root element:
      <PwrTestLog
            date=”today’s date”
            time=”beginning time”
            filename = “logfile path”>
      … scenario information …
      </PwrTestLog>

Sleep Scenario Information
The PwrTest Sleep scenario is designed to facilitate automated testing of sleep and resume transitions. PwrTest is capable of directing the platform into one or more sleep states in an automated fashion and logging sleep state performance information such as the BIOS initialization and total resume times.
To learn more about the Sleep Scenario, type:
      PwrTest /sleep /?
The PwrTest Sleep scenario supports the following command-line arguments:
Argument
Description
Default value
/c:n
n indicates the number of sleep cycles
/c:1
/d:n
n indicates the delay time between consecutive sleep cycles, in seconds.
/d:90
/p:n
n indicates the time the system will sleep before automatically waking for the next sleep cycle, in seconds.
/p:60
/h:y
Indicates hybrid sleep transitions should be enabled.
Current user power policy
/h:n
Indicates hybrid sleep transitions should be disabled.
Current user power policy
/t:y
Indicates sleep transitions should be marked critical. Applications and services are not able to prevent the sleep transition.
Current user power policy
/t:n
Indicates sleep transitions should not be marked critical. Applications and services are able to prevent the sleep transition.
Current user power policy
/s:n
n indicates the target sleep state(s) for the sleep transitions. Possible values are:
  • “all”, All ACPI sleep states should be used in sequential order (S1, S3, S4, S1, S3, S4…)
  • “rnd”, All ACPI sleep states should be used in random order (S1, S4, S3, S1, S4, S1…)
  • “1”, Only S1 state should be used.
  • “3”, Only S3 state (“Standby”) should be used.
  • “4”, Only S4 state (“Hibernate”) should be used.
/s:3
Examples
PwrTest /sleep /c:7 /s:3
PwrTest will cycle the system through 7 standby transitions and save the output file information to .\PwrTestlog.xml and .\PwrTestlog.wtl.
PwrTest /sleep /c:1 /s:1
PwrTest will cycle the system through a single S1 transition and save the output file information to .\PwrTestlog.xml and .\PwrTestlog.wtl.
PwrTest /sleep /c:10 /s:rnd /d:180 /p:600 /l:random
PwrTest will cycle the system through 10 sleep/resume cycles with a random target sleep state from the available sleep states on the system. The system will sleep for 10 minutes on each sleep cycle and the delay between sleep cycles will be 3 minutes. The output will be saved to .\random.xml and .\random.wtl.
XML Logfile Output
The sleep scenario generates the following XML elements:
  <SleepScenario>
    <SleepTransitions
            critical=""
            hybrid=""
            delay=”"
            sleeptime="">
            <SleepTransition
                  number=""
                  status="">
                  <StartT></StartT>
                  <EndT></EndT>
                  <Duration></Duration>
                  <TargetState></TargetState>
                  <EffectiveState></EffectiveState>
                 <BIOSInit></BIOSInit>
                  <DriverInit></DriverInit>
                  <Suspend></Suspend>
                  <Resume></Resume>
                  <HiberRead></HiberRead>
                  <HiberWrite></HiberWrite>
            </SleepTransition>
            <SleepTransition
                  number=""
                  status="">
                  <StartT></StartT>
                  <EndT></EndT>
                  <Duration></Duration>
                  <TargetState></TargetState>
                  <EffectiveState></EffectiveState>
                 <BIOSInit></BIOSInit>
                  <DriverInit></DriverInit>
                  <Suspend></Suspend>
                  <Resume></Resume>
                  <HiberRead></HiberRead>
                  <HiberWrite></HiberWrite>
            </SleepTransition>
    </SleepTransitions>
  </SleepScenario>
This table describes the sleep scenario XML elements in detail:
Element | Description
<SleepScenario> | Contains information related to the sleep scenario. Only one <SleepScenario> element per PwrTest log file.
<SleepTransitions> | Provides overall data about the sleep transition cycles such as the state of critical and hybrid sleep features.
<SleepTransition> | Provides per-sleep cycle information such as the start and end times, as well as details about the resume time such as the BIOS initialization time. A <SleepTransition> element is generated for each sleep transition cycle.
<StartT> | Indicates the start time of the sleep cycle. (hh:mm:ss)
<EndT> | Indicates the end time of the sleep cycle. (hh:mm:ss)
<Duration> | Indicates the duration of the sleep cycle. (hh:mm:ss)
<TargetState> | Indicates the target sleep state.
<EffectiveState> | Indicates the effective sleep state.
<BIOSInit> | Indicates the amount of time required to initialize the BIOS (TargetState must be 3) on resume in milliseconds.
<DriverInit> | Indicates the amount of time required to initialize drivers on resume in milliseconds.
<Suspend> | Indicates the amount of time required to suspend the system in milliseconds.
<Resume> | Indicates the total amount of time required to resume the system in milliseconds.
<HiberRead> | Indicates the time required to read the hibernation file in milliseconds. (TargetState must be 4)
<HiberWrite> | Indicates the time required to write the hibernation file in milliseconds. (EffectiveState must be 4)
PPM Scenario Information
The PwrTest PPM scenario is designed to facilitate automated inspection of processor power management capabilities and run-time information. PwrTest is capable of recording system usage of processor performance and processor idle states over a duration of time.
These metrics can be analyzed post-run from the PwrTest logfile and compared to past or future runs of PwrTest.
To learn more about the PPM Scenario, type:
      PwrTest /ppm /?
The PwrTest PPM scenario supports the following command-line arguments:
Argument | Description | Default value
/n:n | n indicates the number of cycles of processor information to log. | /c:100
/i:n | n indicates the polling interval (in milliseconds) to update processor information. PwrTest will record processor information for the number of cycles specified by /n:n multiplied by the polling interval specified by /i:n. | /i:5000
/c:y | Indicates that processor idle (ACPI C-state) information should be logged. | (default)
/c:n | Indicates that processor idle (ACPI C-state) information should not be logged. |
/p:y | Indicates that processor performance / throttle state information should be logged. | (default)
/p:n | Indicates that processor performance / throttle state information should not be logged. |
/u:y | Indicates that CPU utilization information should be logged. | (default)
/u:n | Indicates that CPU utilization information should not be logged. |
Examples
PwrTest /ppm /n:10 /i:6000
PwrTest will record all processor power management information for one minute at 6 second intervals.
PwrTest /ppm /n:3600 /i:1000 /p:n
PwrTest will record processor performance state information every second for an hour.
PwrTest /ppm /n:3600 /i:1000 /u:y /p:n /c:n
PwrTest will record processor utilization only for one-second intervals for an hour.
XML Logfile Output
The PPM scenario generates the following XML elements:
<PPMScenario>
    <ProcessorInformation>
      <PerformanceStates>
        <PerformanceState
            number="0"
            frequency=""
            percentofmaxfrequency=""
            type="" />
      </PerformanceStates>
      <ProcessorName> </ProcessorName>
      <InterfaceType> </InterfaceType>
      <TransitionLatency units=""></TransitionLatency>
    </ProcessorInformation>
    <ProcessorTraces interval="">
      <Trace>
        <CpuId></CpuId>
        <ElapsedT></ElapsedT>
        <CPUIdle></CPUIdle>
        <PState></PState>
        <Frequency></Frequency>
        <PercentOfMax></PercentOfMax>
        <PStateType></PStateType>
        <COne></COne>
        <CTwo></COne>
        <CThree></CThree>
      </Trace>
    </ProcessorTraces>
  </PPMScenario>
This table describes the PPM scenario XML elements in detail:
Element | Description
<PPMScenario> | Contains information related to the PPM scenario. Only one <SleepScenario> element per PwrTest log file.
<ProcessorInformation> | Contains information related to the static attributes of the processor, such as performance and throttle state capabilities.
<PerformanceStates> | Contains a list of <PerformanceState> elements.
<PerformanceState> | Indicates an available performance or throttle state. Includes state number, frequency, percentage of maximum frequency and type attributes.
<ProcessorName> | Indicates the friendly name of the processor.
<InterfaceType> | Indicates the mechanism used to interface between Windows and platform processor power management features.
<TransitionLatency> | Indicates the latency when switching performance states. Includes an units attribute, typically “us”.
<ProcessorTraces> | Contains a list of <Trace> elements. Includes an interval attribute indicating the interval of each <Trace> element.
<Trace> | Contains trace information, which will vary depending on the command-line arguments presented to PwrTest.
<CpuId> | Identifies the processor.
<ElapsedT> | Indicates the elapsed time since the start of PwrTest in milliseconds.
<CPUIdle> | Indicates the percentage of processor idle time.
<PState> | Indicates the current processor performance state.
<Frequency> | Indicates the actual frequency of the current processor performance state in Megahertz.
<PercentOfMax> | Indicates the percentage of maximum frequency for the current performance state.
<PStateType> | Indicates if the performance state is a performance state (1) or a throttle state (0).
<COne> | Indicates the percentage of CPU idle time spent in the C1 CPU idle state.
<CTwo> | Indicates the percentage of CPU idle time spent in the C2 CPU idle state.
<CThree> | Indicates the percentage of CPU idle time spent in the C3 CPU idle state.
Battery Scenario Information
The PwrTest Battery scenario is designed to facilitate automated inspection of battery and power source information. PwrTest is capable of logging battery capacity, voltage, rate of drain and general state for up to two batteries on the system. Battery data is logged at a specified interval for a specified number of cycles.
To learn more about the Battery Scenario, type:
      PwrTest /battery /?
The PwrTest Battery scenario supports the following command-line arguments:
Argument | Description | Default value
/n:n | n indicates the number of cycles of battery information to log. | /c:100
/i:n | n indicates the polling interval (in milliseconds) to update battery information. | /i:5000
/b:n | n indicates the which battery to log information from (0 or 1). | /b:all
/b:all | Indicates battery information should be logged from all batteries. | /b:all
Examples
PwrTest /battery /n:10 /i:6000
PwrTest will record all battery information for one minute at 6 second intervals.
PwrTest /battery /n:10 /i:6000 /b:0
PwrTest will record battery information only from battery 0 for one minute at 6 second intervals.
XML Logfile Output
The Battery scenario generates the following XML elements:
<BatteryScenario>
    <Batteries>
      <Battery  id=”" shortterm="" rechargable="" >
        <Name></Name>
        <UniqueID></UniqueID>
        <Chemistry></Chemistry>
        <Manufacturer></Manufacturer>
        <DesignedCapacity></DesignedCapacity>
        <FullChargeCapacity></FullChargeCapacity>
        <CriticalBias></CriticalBias>
        <CycleCount></CycleCount>
        <ManufactureDate></ManufactureDate>
        <FullLifeTime Units=""></FullLifeTime>
      </Battery>
    </Batteries>
    <BatteryTraces interval="">
      <Trace>
        <ElapsedT></ElapsedT>
        <ACStatus></ACStatus>
        <Capacity id=""></Capacity>
        <TimeRemaining></TimeRemaining>
        <Capacity id=""></Capacity>
        <RateOfDrain id=””></RateOfDrain>
        <Voltage id=””></Voltage>
        <Capacity id=""></Capacity>
        <RateOfDrain id=””></RateOfDrain>
        <Voltage id=””> </Voltage>
      </Trace>
    </BatteryTraces>
  </BatteryScenario>
This table describes the Battery scenario XML elements in detail:
Element | Description
<BatteryScenario> | Contains information related to the battery scenario. Only one <BatteryScenario> element per PwrTest log file.
<Batteries> | Contains information related to the static attributes of the system batteries, such as manufacturer and cycle count information. Note, all information may not be available for each battery.
<Battery> | Contains static information about a system battery. An id attribute is present to uniquely identify the battery.
<Name> | Indicates the name of the battery.
<UniqueID> | Indicates the unique ID of the battery.
<Chemistry> | Indicates battery chemistry.
<Manufacturer> | Indicates the battery manufacturer.
<DesignedCapacity> | Indicates the designed capacity of the battery in mWh.
<FullChargeCapacity> | Indicates the fully charged capacity of the battery in mWh.
<CriticalBias> | Indicates a bias from zero, in mWh, which is applied to the battery reporting.
<CycleCount> | Indicates the number of charge/discharge cycles the battery has experienced.
<ManufactureDate> | Indicates the manufacture date of the battery.
<FullLifeTime> | Indicates the battery full life time in seconds.
<BatteryTraces> | Contains a list of <Trace> elements. Has an attribute indicating the battery information polling interval.
<Trace> | Contains information about battery status such as voltage, capacity and rate of drain for a given interval.
<ElapsedT> | Indicates the elapsed time since PwrTest was started.
<ACStatus> | Indicates if the system is running on AC (1) or battery (0) power.
<TimeRemaining> | Indicates the battery life time remaining from all system batteries, in seconds.
<Capacity> | Indicates the capacity of the battery in mWh. Has an id attribute to indicate which battery the capacity is being reported for.
<RateOfDrain> | Indicates the rate of drain of the battery in mW. Has an id attribute to indicate which battery the rate of drain is being reported for.
<Voltage> | Indicates the battery voltage in mV. Has an id attribute to indicate which battery the voltage is being reported for.
Info Scenario Information
The PwrTest Info scenario is designed to log and display system power management capabilities and information, such as the availability of system power states.
To learn more about the Info Scenario, type:
      PwrTest /info /?
The PwrTest Info scenario supports the following command-line arguments:
Argument | Description | Default value
/info:powercap | Display SYSTEM_POWER_CAPABILITIES, which includes information about the availability of system sleep states. | (none)
/info:powerinfo | Display SYSTEM_POWER_INFORMATION which displays dynamic data about current idle thresholds and timers. | (none)
/info:battery | Display SYSTEM_BATTERY_STATE which contains information about the current state of the system battery. | (none)
/info:ppm | Display PROCESSOR_POWER_INFORMATION which contains information about the system processor. | (none)
/info:all | Display all supported information data. | (none)
Examples
PwrTest /info:powercap
PwrTest will display and log system power capabilities information from the SYSTEM_POWER_CAPABILITIES structure.
PwrTest /info:all
PwrTest will display and log all supported information data.
XML Logfile Output
The info scenario generates the following XML elements:
<InfoScenario>
    <SYSTEM_POWER_CAPABILITIES>
      <SystemS1StateSupported></SystemS1StateSupported>
      <SystemS2StateSupported></SystemS2StateSupported>
      <SystemS3StateSupported></SystemS3StateSupported>
      <SystemS4StateSupported></SystemS4StateSupported>
      <SystemS5StateSupported></SystemS5StateSupported>
      <RtcWakeSupported></RtcWakeSupported>
      <FastSystemS4></FastSystemS4>
    </SYSTEM_POWER_CAPABILITIES>
    <SYSTEM_POWER_INFORMATION>
      <MaxIdlenessAllowed></MaxIdlenessAllowed>
      <Idleness></Idleness>
      <TimeRemaining></TimeRemaining>
      <CoolingMode></CoolingMode>
    </SYSTEM_POWER_INFORMATION>
    <SYSTEM_BATTERY_STATE>
      <AcOnLine></AcOnLine>
      <BatteryPresent></BatteryPresent>
      <Charging></Charging>
      <Discharging></Discharging>
      <MaxCapacity></MaxCapacity>
      <RemainingCapacity></RemainingCapacity>
      <RateOfDrain></RateOfDrain>
      <EstimatedTime></EstimatedTime>
      <DefaultAlert1></DefaultAlert1>
      <DefaultAlert2></DefaultAlert2>
    </SYSTEM_BATTERY_STATE>
    <PROCESSOR_POWER_INFORMATION>
      <CPUNumber></CPUNumber>
      <MaxMhz></MaxMhz>
      <CurrentMhz></CurrentMhz>
      <MhzLimit></MhzLimit>
      <MaxIdleState></MaxIdleState>
      <CurrentIdleState></CurrentIdleState>
    </PROCESSOR_POWER_INFORMATION>
    </InfoScenario>
This table describes the Battery scenario XML elements in detail:
Element | Description
<InfoScenario> | Contains information related to the info scenario. Only one <InfoScenario> element per PwrTest log file.
<SYSTEM_POWER_CAPABILITIES> | Contains information related to system power capabilities. This information is retrieved from the SYSTEM_POWER_CAPABILITIES structure.
<SystemSxStateSupported> | Indicates if a given system ACPI sleep state is supported on the system.
<RtcWakeSupported> | Indicates the lowest sleep state where RTC wake (wake on timer) is supported. The value is of the SYSTEM_POWER_STATE enumeration.
<FastSystemS4> | Indicates if hybrid sleep is available on the system.
<SYSTEM_POWER_INFORMATION> | Contains information related to the idleness of the system.
<MaxIdlenessAllowed> | Indicates the idleness (in percentage) when the system is considered idle and the idle timeout begins counting.
<Idleness> | Current idle level, expressed in percentage.
<TimeRemaining> | Indicates the time remaining in the system standby idle timer, in seconds.
<CoolingMode> | Indicates the current system cooling mode: (0) Active, (1), Passive, (2) Invalid.
<SYSTEM_BATTERY_STATE> | Contains information related to the current state of the system battery.
<AcOnLine> | Indicates if the system is currently operating on AC power.
<BatteryPresent> | Indicates if at least one battery is present in the system.
<Charging> | Indicates if at least one battery is currently charging.
<Discharging> | Indicates if at least one battery is currently discharging.
<MaxCapacity> | Maximum capacity of the battery when new, in mWh.
<RemainingCapacity> | Estimated remaining capacity of the battery, in mWh.
<RateOfDrain> | Indicates the current rate of discharge of the battery in mW.
<EstimatedTime> | Estimated time remaining on the battery, in seconds.
<DefaultAlert1> | Indicates the battery manufacturers suggested capacity when a low battery alert should occur.
<DefaultAlert2> | Indicates the battery manufacturers suggested capacity when a warning battery alert should occur.
<PROCESSOR_POWER_INFORMATION> | Contains information related to the system processors and their power management capabilities.
<CPUNumber> | Indicates which processor the current <PROCESSOR_POWER_INFORMATION> element is describing.
<MaxMhz> | Indicates the maximum frequency of the processor.
<CurrentMhz> | Indicates the current frequency of the processor.
<MhzLimit> | Indicates the current limit on the processor clock frequency.
<MaxIdleState> | Indicates the maximum idle state of the processor.
<CurrentIdleState> | Indicates the current idle state of the processor.

Run Time: 10 minutes
Log File: PwrTestLog.xml
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running Power Management Test Tool (PwrTest)

Command Syntax

Command option | Description

Cautions

Troubleshooting

Reference Documentation

Power Management Diagnosability Resolver Design Specificationhttp://team/sites/winmob/Hawk/Diagnosibility%20dev%20design.mhtPower Management Diagnosability Scenario Specification\\winwebdocs\ntspecs\instrumentationeventtracing\Diagnosis\DiagScenarios\diagscenariospowmgmt.doc

Code Tour

File Manifest

File | Location
pwrtest.exe | tools\acpi\pwrtest

Click to show or hide information. Test Assertions

Test Assertions

S3 Resume
Test Assertion GUID: C98100E4-BF10-431e-B803-BD1292276285

Windows Logo Program: SYSFUND-0004 System resumes from ACPI S3 state in ≤2 s

Additional Information: Content will be published


W2K3 MSCS - Run ValdN

Overview

The Validate N Node Cluster test ensures that all cluster operations between nodes, such as move and failover, will work. You need to run this test with all the nodes joined to the cluster intended for validation.

Details

This test ensures that all cluster operations between nodes, such as move and failover, will work. You need to run this test with all the nodes joined to the cluster intended for validation.
Run time: approximately 48 hours
Log File name: Valdn.log

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows 2003
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running W2K3 MSCS - Run ValdN

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Cluster Server Testing Overview

To receive the “Designed for Windows” logo for a system or server, and qualify the system or server to appear in the Windows Catalog, you must complete the required Cluster Server testing. These tests verify that your product functions properly with the applicable Microsoft Windows operating system.

The procedures presented in this section outline the process for testing your Cluster Server. These procedures use the Microsoft Windows Driver Kit (WDK) and Driver Test Manager (DTM). To ensure full functionality, you must run all of the tests that the DTM identifies as required for the Cluster Server.

Using the Test Procedure Help Topics

The test procedures are divided into the following types of topics:

Overview: The overview topics describe the hardware, software, and tester knowledge requirements.

Preparing: The preparing topics describe how to configure the system or systems for "Designed for Windows" logo testing.

Running: The running topics describe how to run the tests for your device or system.

Geographically dispersed cluster servers

A geographically dispersed cluster is a cluster in which the nodes are deployed on several different sites. A geographically dispersed cluster server need to ensure that the round-trip latency of the network between nodes of the cluster is 500 milliseconds or less. Use the cluster server test procedures to test a geographically dispersed cluster.

There is only one difference between testing a cluster server and testing a geographically dispersed cluster server: The “W2K3 MSCS - Run Phase 1” test is not required for a geographically dispersed cluster submission.

Cluster server tests

These tests are required for all cluster servers and must be run in the order that they are listed:

  1. W2K3 MSCS - Run Phase 1
  2. W2K3 MSCS - Run Signed Driver Check
  3. W2K3 MSCS - Run ValdN
  4. W2K3 MSCS - Run MovN

Run time: approximately 77 hours

Hardware requirements

Note: All hardware that is part of the system or shipped with the cluster solution must be listed in the Windows Server Catalog for the appropriate operating system before the system itself can be granted a logo. In addition, the domain controller, remote test host, and clients must be listed in the Windows Server Catalog.

The following hardware is required to run the Cluster Server HCT kit:

  • At least two computers to serve as nodes of the cluster. Each computer must include the following:
    • x86, Itanium-2-based, or x64 processor with a minimum speed of 450 MHz
    • One hard disk drive with at least 6 GB free storage capacity after operating system installation
    • One CD-ROM drive
    • Two Peripheral Component Interconnect (PCI) network adapters, with a minimum speed of 10/100
    • At least 1024 MB RAM in each node.

  • The following are needed to implement a shared storage bus:
    • At least one PCI-based SCSI controller, Fibre Channel controller, SCSI RAID controller, or Fibre Channel RAID controller for each node of the cluster. Each controller must have at least eight non-quorum, "shared-nothing" Logical Unit Numbers (LUNs).
    • At least one non-quorum, “shared-nothing” LUN must be available on the shared storage bus for each node in the cluster server. Each disk partition must be formatted with NTFS and must have at least 2 GB of storage capacity.
    • Two network hubs, with a minimum speed of 10/100

  • Eight desktop computers to serve as the test clients. Each computer must include the following:
    • x86 processor with a minimum speed of 450 MHz
    • At least 128 MB RAM (256 MB of RAM is preferable.)
    • One network adapter, with a minimum speed of 10/100
    • 2 GB of available hard disk space on the system installation drive

  • One computer to serve as the remote test host (also called the client master). This computer must include the following:
    • x86 processor with a minimum speed of 450 MHz
    • At least 256 MB RAM
    • Two network adapters, with a minimum speed of 10/100
    • At least 6 GB of available hard disk space on the system installation drive

  • One computer to serve as the primary domain controller. This computer must include the following:
    • x86, Itanium-2-based, or x64 processor with a minimum speed of 450 MHz
    • At least 256 MB RAM
    • Two network adapters, with a minimum speed of 10/100
    • 6 GB available hard disk space on the system installation drive

Software requirements

The following software is required to run the Cluster Server HCT kit:

  • One of the following operating systems for each node of the cluster:
    • Microsoft Windows Server 2003, Enterprise Edition
    • Microsoft Windows Server 2003, Datacenter Edition
    • Microsoft Windows Server 2003, Enterprise x64 Edition
    • Microsoft Windows Server 2003, Datacenter x64 Edition
    • Microsoft Windows Server 2003, Enterprise Edition for Itanium-based Systems
    • Microsoft Windows Server 2003, Datacenter Edition for Itanium-based Systems

  • Microsoft Windows Server 2003, Standard Edition, for the domain controller and the remote test host.
  • Microsoft Windows XP Professional with Service Pack 2 (SP2) for the eight client systems:
  • The current release of the Windows WDK kit

Tester knowledge requirements

To run the Windows HCT kit for cluster servers, testers must know how to accomplish the following tasks:

  • Create, format, and remove partitions on a hard disk drive.
  • Install RAM in a test system.
  • Install and configure a cluster server.
  • Set power management options.
  • Install the test adapter and attach devices to it.
  • Create a domain by using Dynamic Host Configuration Protocol (DHCP) and a domain administrator account.
  • Join computers to a domain.


Preparing for Cluster Server Testing

For a complete list of required hardware, software, and tester knowledge requirements, see Cluster Server Testing Overview.

Test system configuration

To run the Cluster Server HCT kit, you must first assemble the test environment and then configure the computers.

Note: Before you begin testing, make sure that all the devices on each system are enabled, all drivers are loaded, and any Internet firewall settings are disabled for all network devices.

To assemble the test environment

Figure 1 illustrates the configuration for a two-node cluster with a shared SCSI storage bus. Figure 2 illustrates the configuration for a two-node cluster with a shared Fibre Channel storage bus.

Figure 1: Standard configuration that uses a SCSI adapter for the shared storage bus

Figure 2: Standard configuration that uses a Fibre Channel adapter for the shared storage bus

Note: On cluster servers with more than two nodes, each node must be connected to a network hub and to a Fibre Channel switch. SCSI storage is not supported for cluster servers with more than two nodes.

  1. Install the two network hubs. One hub is referred to as the hub for the shared LAN, and the other hub is referred to as the private hub.
  2. Connect the domain controller to both network hubs.
  3. Connect the remote test host to both network hubs.
  4. Connect the eight client systems to the hub for the shared LAN.
  5. Install a SCSI, Fibre Channel, SCSI RAID, or Fibre Channel RAID controller on each node of the cluster.
  6. Connect each node of the cluster to the hub for the shared LAN and to the private hub.
  7. Connect each node of the cluster to the shared storage bus, either directly if you are using a SCSI bus, or through a hub or a switch if you are using a Fibre Channel bus.
  8. Connect the shared disk array to the shared storage bus, either directly if you are using a SCSI bus, or through a hub or a switch if you are using a Fibre Channel bus.
  9. Install the appropriate operating system on the remote test host.
  10. Install the appropriate operating system on each node of the cluster.
  11. Install the appropriate operating system on the domain controller.
  12. Install the appropriate operating system on each of the eight test clients.
  13. Create a user account for the domain administrator, and grant this account local administrative credentials on all of the computers.

To configure the cluster for cluster server testing

Use the following procedure to configure the computers in the test environment.

Note: When performing the following actions, always log on to all test systems by using the domain account that you created while assembling the test environment.

  1. Join the domain controller, the remote test host, each node of the cluster, and each of the eight test clients to the domain.
  2. Use the following procedure to install DHCP services on the domain controller:
    1. On the domain controller, click Start, click Control Panel, double-click Add or Remove Programs, and then click Add/Remove Windows Components.
    2. In the Windows Components wizard, select the Networking Services check box, and then click Details.
    3. In the Networking Services dialog box, select the Dynamic Host Configuration Protocol (DHCP) check box, and then click OK.
    4. Follow the instructions in the wizard to finish installing DHCP services.

  3. Use the following procedure to install Domain Name System (DNS) services on the domain controller:
    1. On the domain controller, click Start, click Control Panel, double-click Add or Remove Programs, and then click Add/Remove Windows Components.
    2. In the Windows Components wizard, select the Networking Services check box, and then click Details.
    3. In the Networking Services dialog box, select the Domain Name System (DNS) check box, and then click OK.
    4. Follow the instructions in the wizard to finish installing DNS.

  4. Use the following procedure to install Windows Internet Name Service (WINS) on the domain controller:
    1. On the domain controller, click Start, click Control Panel, double-click Add or Remove Programs, and then click Add/Remove Windows Components.
    2. In the Windows Components wizard, select Networking Services, and then click Details.
    3. In the Networking Services dialog box, select Windows Internet Name Service (WINS), and then click OK.
    4. Follow the instructions in the wizard to finish installing DNS. Be sure to assign a static IP address to each of the network adapters on the nodes of the cluster.

  5. Use the following procedure to turn off the screen saver:
    1. Click Start, click Control Panel, and then double-click Display.
    2. On the Screen Saver tab of the Display Properties dialog box, select (None) from the Screen saver list.

  6. The cluster shared storage should have N+1 LUN’s, where N is the number of nodes.
  7. Run the “W2K3 MSCS - Run Phase 1” tests on each node of the cluster. Do not form a cluster for this test. All partitions on the cluster shared storage LUN need to be deleted. You can do this using the Disk Management tool.
  8. Create a cluster, and add each of the nodes to the cluster.
  9. Use the following procedure to configure the remote test host:
    1. On the remote test host, click Start, click Control Panel, double-click Add or Remove Programs, and then click Add/Remove Windows Components.
    2. In the Windows Components wizard, select the Management and Monitoring Tools check box, and then click Details.
    3. In the Management and Monitoring Tools dialog box, select the Network Monitor Tools check box, and then click OK.
    4. In the Windows Components wizard, click Next.
    5. When the installation is complete, click Finish.
    6. Install .Net framework 2.0 on the remote test host.

  10. Use the following procedure to configure the power options on the domain controller, the remote test host, the nodes of the cluster, and all of the test clients:
    1. Click Start, click Control Panel, and then double-click Power Options.
    2. On the Power Schemes tab of the Power Options Properties dialog box, do the following:
      1. From the Turn off monitor list, select Never.
      2. From the System standby list, select Never.
      3. If there is a System hibernates list, select Never.

    3. On the Hibernate tab of the Power Options Properties dialog box, clear the Enable hibernation check box.

  11. Install the DTM client on all the test machines (remote test host, test clients, nodes)
  12. Create a machine pool, name it whatever you wish: When DTM client has been installed on all machines, they will appear in the default pool. Move all test machines to that pool. The machine pool should contain one remote test host (MC), 8 test clients (SC), and all the nodes (Node) in the cluster.
  13. Machine dimensions: For each machine, set the machine dimension (HCT\Role) to the appropriate value (MC, SC, or Node). This can be done by right-clicking on each machine and selecting the edit option, then going to machine dimensions tab and add a new dimension “HCT\Role”.


Running the Cluster Server Tests

To run the tests in the Cluster Server HCT kit most efficiently, you must modify the test system configuration and run the tests in a specific order. This topic describes how to configure the test system and run the cluster server tests.

  1. Before createing the cluster, run “W2K3 MSCS - Run Phase 1” test on the machine pool. This will start test processes on each node of the cluster. Do not form a cluster for this test. All partitions on the cluster shared storage LUN need to be deleted. You can do this using the Disk Management tool.
  2. Shut down all of the nodes of the cluster, and then restart Node A.
  3. Create partition for each cluster shared storage LUN, set to Master Boot Record (MBR), and format with NTFS.
  4. Configure clustering on Node A, to form a one-node cluster.
  5. Start all of the other nodes in the cluster.
  6. Join the new nodes to the cluster.
  7. Run the W2K3 MSCS - Run Signed Driver Check test on the machine pool. This will start test processes on each node of the cluster.
  8. Run the W2K3 MSCS - Run ValdN test on the machine pool. This will start the test process on the remote test host.
  9. Run the W2K3 MSCS - Run MovN test on the machine pool. This will start the test process on the remote test host.
  10. Return the test results.


Troubleshooting Cluster Server Tests


Driver Reliability Tests

Test name | Target operating system | Test description
Plug and Play Driver Test | Windows Vista Windows XP | The test exercises various Plug and Play (PnP)-related code paths in the driver and user-mode components. This test job runs Plug and Play Driver test with Driver Verifier enabled.
Disable Enable with IO | Windows Vista Windows XP | The Disable Enable with IO job ensures that the device under test can be disabled and enabled without error. Additionally, it tries to ensure that the device is still functional after these changes in state through SimpleIO stress testing.
Prefast for Drivers | Windows Vista Windows XP | PREfast for Drivers is a required tool for Windows Logo programs. You must submit PREfast results if a kernel-mode device driver or kernel-mode service is included with your DRS or Logo submission.
Core Stress Test | Windows Vista Windows XP | Core Stress Test exercises memory and disk subsystems of the Windows operating system
Device Path Exerciser | Windows Vista Windows XP | The Device Path Exerciser test is designed to test the reliability and security of drivers.
Common Scenario Stress with IO | Windows Vista Windows XP | The Common Scenario Stress with IO job ensures that the device under test accepts and correctly handles numerous Plug and Play (PnP) and power management state change scenarios. This currently includes disable/enable and suspend/hibernate/wake scenarios. Additionally, it tries to ensure that the device is still functional after these changes in state through SimpleIO stress testing.
Static Driver Verifier | Windows Vista Windows XP | Static Driver Verifier (SDV) is not a required tool for Windows Logo programs however its use is highly encouraged. In the future, SDV might become a required test for Windows Logo if a kernel-mode device drivers or service is included in the submission package.
Sleep Stress with IO | Windows Vista Windows XP | This Sleep Stress with IO job ensures that the device under test permits the system to be cycled through all supported sleep states. Additionally, it tries to ensure that the device is still functional after these changes in state through SimpleIO stress testing.
Driver Verifier | Windows Vista Windows XP | Driver Verifier monitors kernel-mode drivers and graphics drivers to verify that they are not making invalid function calls or causing system corruption. This tool can perform a large number of checks on these drivers and can subject them to a variety of stresses and tests to find improper behavior.


Plug and Play Driver Test

Type: Automated Test

Overview

The test exercises various Plug and Play (PnP)-related code paths in the driver and user-mode components. This test job runs Plug and Play Driver test with Driver Verifier enabled.

Details

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running Plug and Play Driver Test

Prerequisite: Before you can run DRS - Plug and Play Driver Test, install the device and driver on the test client. Next, install and configure DTM.
To Run DRS - Plug and Play Driver Test
  • Start DTM Studio.
  • Open or switch to the Device Console window, and then select the machine pool that contains the computer where you want to run the test.
  • In the Available Devices pane, expand the type of device that is associated with your driver, and then select the specific device on which to run the test.
  • In the Available Jobs pane, select the DRS - Plug and Play Driver Test job.
  • Click Add Selected in the lower-left corner of the Device Console window to add the jobs to the schedule of jobs to be run.
  • Click Schedule Jobs.
  • Follow the progress of the DRS - Plug and Play Driver Test job by using Job Monitor. Use the Result Explorer to examine the results of jobs that have completed. The test creates additional log files that contain detailed information about what the test is doing. You can use these log files to help you determine why a test failed.

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Disable Enable with IO

Type: Automated Test

Overview

The Disable Enable with IO job ensures that the device under test can be disabled and enabled without error. Additionally, it tries to ensure that the device is still functional after these changes in state through SimpleIO stress testing.

Details

The Disable Enable With IO job is the "Driver Reliability" version of the Disable_Enable_With_IO automated scenario.
The job directs the underlying scenario to target the device under test via it's service name. Additionally, the underlying scenario can only target disableable devices. A disableable device is defined to be a device that has the "Disable" menu option available in Device Manager and is not class 'LegacyDriver'. If the scenario is targeted at a non-disableable device, the scenario should auto-pass.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running Disable Enable with IO

Prerequisite: Before you can run Disable Enable with IO, install the device and driver on the test client. Next, install and configure DTM.
To Run Disable Enable with IO
  • Start DTM Studio.
  • Open or switch to the Device Console window, and then select the machine pool that contains the computer where you want to run the test.
  • In the Available Devices pane, expand the type of device that is associated with your driver, and then select the specific device on which to run the test.
  • In the Available Jobs pane, select the Disable Enable with IO job.
  • Click Add Selected in the lower-left corner of the Device Console window to add the jobs to the schedule of jobs to be run.
  • Click Schedule Jobs.
  • Follow the progress of the Disable Enable with IO job by using Job Monitor. Use the Result Explorer to examine the results of jobs that have completed. The test creates additional log files that contain detailed information about what the test is doing. You can use these log files to help you determine why a test failed.

Command Syntax

Command option | Description

Troubleshooting
The underlying scenario was developed using the new Windows Device Testing Framework (WDTF). The WDK contains extensive documentation for using and extending this framework in your own driver development process. Search the WDK help documentation for "Windows Device Testing Framework" for more information. Details on the specific operation of this test tool can be found in the table of contents under "Windows Driver Kit" -> "Other Tools" -> "Windows Device Testing Framework" -> "Automated Scenarios".

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Prefast for Drivers

Type: Automated Test

Overview

PREfast for Drivers is a required tool for Windows Logo programs. You must submit PREfast results if a kernel-mode device driver or kernel-mode service is included with your DRS or Logo submission.

Details

PREfast for Drivers is a compile-time verification tool that is designed specifically to detect errors in kernel-mode driver code. PREfast for Drivers can catch errors such as copying a whole I/O request packet (IRP) without modifying members and saving a pointer to a string, or structure argument, instead of copying an argument in a DriverEntry routine. This is a required test in the DRS program. You can run PREfast for Drivers either by using DTM or by running the tool stand-alone. If you run the tool stand-alone, you must import the summary results file in your submission package.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running Prefast for Drivers

Prerequisite: If you plan to use the option to run PREfast from DTM, before you begin install the WDK build environment and your device driver source files on the test client.
To Run PREfast for Drivers
  • Start DTM Studio.
  • Open or switch to the Device Console window, and then select the machine pool that contains the computer where you want to run the test.
  • In the Available Devices pane, expand the type of device that is associated with your driver, and then select the specific device to run the test.
  • In the Available Jobs pane, select the PREfast for Drivers job.
  • Click Add Selected in the lower-left corner of the Device Console window to add the jobs to the schedule of jobs that you want to run.
  • In the Add Selected pane, right-click the PREfast for Drivers job and select Edit Parameters.
  • For the PREfast for Drivers job, you must provide values for some of the parameters. The descriptions that follow the figure explain the parameters and the values they require.
Note: A PREfast for Drivers summary results file is required for Logo or Unclassified Signature if your submission contains a kernel-mode device driver or kernel-mode service. If your submission does not contain a kernel-mode driver or service, then do not use either of the two options described below and leave all parameters set to <NULL> or their default values. In this case the test job will schedule and exit with a passing result.
For all path parameters in the following sections, you may specify the path using drive letters (for example C:\) or Universal Naming Convention (UNC) paths (for example \\server\Network_Drivers) The default values are <NULL>.
LogFileName
Use this parameter if you are using the option to import PREfast for Drivers results that had been previously created without actually running PREfast for Drivers on your driver source code from DTM. This option is intended when driver source code is not available to the organization using DTM to prepare a Logo submission. In this case the development organization which does have access to driver source code must run PREfast for Drivers then pass along the summary results file DefectsSum.xml for import into the submission package.
If you use this option, then do not change any of the other parameters, that is leave them set to <NULL> or their default values. Edit the LogFileName parameter to point to the summary results file. Typically this path will be a shared directory visible to all the test clients, for example:
\\server\PREfastResults\YourDriverName\DefectsSum.xml
Care must be taken by the development organization which runs PREfast for Drivers and provides the results summary file, to use the same source code that was used to create the kernel-mode device driver or service being submitted for Logo or Unclassified signature.
WDKDriverName
The name of the driver to build. This value is automatically filled in when the job is scheduled. You can leave the value <NULL>.
DriverBasePath
Use this and the following two parameters if you are using the option to actually run PREfast for Drivers on the driver source code from DTM and import the results summary to the submission package. If you use this option, then leave the LogFileName parameter set to <NULL>. Furthermore, if you use this option the Windows Drive Kit build environment and your driver source code must be installed on the client computer that this job is schedule on.
DriverBasePath is The root directory of your driver source tree. In many cases, the value you use for DriverBasePath is the same as the value that you use for DriverSrcPath. For example, if your source files are in C:\Winddk\5234\Src\Wdm\Wmi\Wmifilt, you would use the same path as the value for DriverBasePath.
However, if you build related drivers and use a single hierarchical directory structure, you would specify the topmost directory as DriverBasePath. For example, in the following directory listing, Network_Drivers is the root directory for the Miniport and Intermediate drivers.
DriverSrcPath
The path to the driver source code. For example, if you were testing the WDK sample WMI filter driver on the test client, DriverSrcPath might be similar to the following:
C:\Winddk\5234\Src\Wdm\Wmi\Wmifilt
You can specify DriverSrcPath by using drive letters (for example, C:\) or Universal Naming Convention (UNC) paths (for example, \\server\Network_Drivers\Miniport). The default value is <NULL>. You must specify the path to the source file directory.
Note if you use the LogFileName to include the results summary file, leave the DriverSrcPath value <NULL>.
DriverLibPath
The path to the library directory (if the driver links to library files). The default value is <NULL>. If your driver links to library files, you must specify the path. You can specify multiple library paths by using a semicolon as the delimiter, as the following example shows.
\\driver_dev_sys\Nework_Adapters\Lib1;\\driver_dev_sys\Nework_Adapters\Lib2
Note If you use the LogFileName parameter to include the results summary file, leave the DriverLibPath value <NULL>.
BuildType
The type of build environment that you are using on the test client. The default value is [WTT/Build]. If you use the default value [WTT/Build], the correct value is selected automatically. To set the value explicitly, use the options Check or Free .
Note If you use the LogFileName parameter to include the results summary file, leave the BuildType value set to its default value.
OS
The version of the Microsoft Windows operating system that is running on the test client. The default value is [WTT/OS]. If you use the default value [WTT/OS], the correct value is selected automatically. To set the value explicitly, use one of the following values:
· LH, LONGHORN, Windows Vista (for Windows Vista)
· w2003, Windows Server 2003 (for Windows Server 2003)
· XP, Windows XP (for Windows XP)
Processor
The type of processor that the test client uses. The default value is [WTT/Build]. If you use the default value [WTT/Build], the correct value is selected automatically. To set the value explicitly, use the options x86, amd64, x64, or ia64. If you are running PREfast for Drivers for DRS on a test client that uses an x64 processor, set the value to x86. PREfast for Drivers for DRS is not supported on x64-based computers.
Click Schedule Jobs.
  • Follow the progress of the PREfast for Drivers job by using Job Monitor. When PREfast for Drivers is finished examining the code, the test parses the PREfast for Drivers log file. If any PREfast for Drivers warnings are found, they are reported in the job results. Use the Result Explorer to examine the results of jobs that have completed.

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Core Stress Test

Type: Automated Test

Overview

Core Stress Test exercises memory and disk subsystems of the Windows operating system

Details

Core Stress Test loads the system that is being tested with memory and I/O requests. This test uses Driver Verifier to monitor the driver and confirm that it is not causing system corruption. The Core Stress Test with low resources simulation uses the Driver Verifier option to simulate low system resources against specific driver(s). When the low-resources simulation option is selected, Driver Verifier will cause a random selection of the driver's memory allocations to fail. This tests the driver's ability to react properly to low memory and other low-resource conditions. The stress tests use an extensible test harness that can be modified to include device specific stress tests.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running Core Stress Test

Prerequisite: Before you can run Core Stress Test and the Core Stress Test with low resources, install the device and driver on the test client. Next, install and configure DTM. For more information about installing DTM, see Installing Driver Test Manager.
Update instructions to use the Submissions Wizard, and INF option.
To Run DRS - Stress Tests
  • Start DTM Studio.
  • Open or switch to the Device Console window, and then select the machine pool that contains the computer where you want to run the test.
  • In the Available Devices pane, expand the type of device that is associated with your driver, and then select the specific device on which to run the test.
  • In the Available Jobs pane, select the Core Stress Test and Core Stress Test with low resources job.
  • Click Add Selected in the lower-left corner of the Device Console window to add the jobs to the schedule of jobs to execute.
  • Click Schedule Jobs.
  • Follow the progress of the Core Stress Test or Core Stress Test with low resources job by using Job Monitor. Use the Result Explorer to examine the results of jobs that have completed. The test creates additional log files that contain detailed information about what the test is doing. You can use these log files to help you determine why a test failed.
Comments
Core Stress Test and Core Stress Test with low resources use an extensible test harness that can be modified to include device-specific stress tests. For information about adding your tests to the stress mix, see Adding Device Specific Stress Tests.

Adding Device Specific Stress Tests

[This is preliminary documentation and subject to change.]
Core Stress Test and Core Stress Test with low resources run a suite of tests to stress the system. You can use an extensible configuration file (DRS_Ext.ini) to add tests, including device-specific tests, to the suite. By default, no additional tests are run. To add your own tests or to run device-specific tests, make a copy of the configuration file and then modify the copy to include the additional tests.

DRS_Ext.ini file format

The DRS_Ext.ini file specifies the names of the tests, their command-line parameters, and their return values (if any). If a test launches an additional test, or child process, that test (or those tests) must also be listed in the configuration file. The configuration file has three sections.

[ext_tests]

This section lists the names of the tests and their command-line arguments. The command line for each test is assigned an identifier (Test1, Test2, etc.). The syntax is as follows:
[ext_tests]
Test1=test1.exe [-test1parameter]...
Test2=test2.exe [-test2parameter]...
[exit_codes]
If your test returns a value on exit, you must specify this return value in the [exit_codes] section of the configuration file. For example, in the following DRS_Ext.ini file, Mytest.exe is declared in the [ext_tests] section. The test returns the value 1 if the test is successfully completed. If the test returns a value other than 1, the test fails and the stress run is halted. If a test runs continuously in a loop, no exit code is necessary.
[ext_tests]
Test1=mytest.exe
[exit_codes]
Test1=1
[child_process]
If a test starts or launches other test executables, those tests (or children) must also be listed in the [child_process] section. List all the tests that are started during a stress test run, so that the stress test harness can perform cleanup.
Example DRS_Ext.ini file
In the following example, Test1 returns the value 1 if the test is successfully completed. Test2 takes a command-line argument, and Test3 launches two additional tests, which are listed in the [child_process] section.
[ext_tests]
Test1=stress1.exe
Test2=stress2.exe -all
Test3=wrapper.exe
[exit_codes]
Test1=1
[child_process]
Test3=child1.exe,child2.exe
Adding Tests to the Stress Configuration File
To add or run device specific tests
  • Make a copy of the configuration file, DRS_Ext.ini. This file is located on the DTM Controller in the following directory (replace DTMServerName with the name of the computer that runs the DTM controller; replace cpu with the target processor architecture:
\\DTMServerName\Tests\cpu\nttest\BaseTest\whdq\DQS\RUNSTRSS
  • Open the copy of the configuration file and then remove the comment characters that cover any of the tests listed in the configuration file that you want add to the stress run. The configuration file uses C++ comment delimiters (//). Everything after the comment delimiter up to the end of the line is ignored.
  • To add your tests for your device to the list of tests, use the following format:
Test1=<test1.exe> [-test1parameter]...
Test2=<test2.exe> [-test2parameter]...
If your test returns a value on exit, you must specify this return value in the [exit_codes] section of the configuration file. For example, in the following configuration file, Stress1.exe is declared in the [ext_tests] section. The test returns the value 1 if the test is successfully completed. If the test returns a value other than 1, the test fails and the stress run is halted.
[ext_tests]
Test1=stress1.exe
[exit_codes]
Test1=1
If your test starts up other tests, you must specify the names of those tests in the [child_process] section of the configuration file. For example, in the following configuration file, Test3 (wrapper.exe) starts two additional tests (child1.exe and child2.exe).
[ext_tests]
[Test3=wrapper.exe
[child_process]
Test3=child1.exe,child2.exe
  • Save the copy of the configuration file.
  • In the Device Console window, select and then add the stress jobs DRS - Stress Test and DRS - Stress Test with low resources.
  • In the Add Selected pane, right-click a stress job DRS - ( KRISTI RASMUSSEN: Numbering here is off, but building fine.) Stress Test or DRS - Stress Test with low resources and select Edit Parameters. For the ExIniFile parameter, specify the name of the configuration file you just edited. Repeat this step for the other stress jobs. When you run the tests, the additional device-specific tests are added to the stress run.
  • Click Save to create a Device Job Schedule file that you can load in the future to avoid having to edit the parameters again.

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Device Path Exerciser

Type: Automated Test

Overview

The Device Path Exerciser test is designed to test the reliability and security of drivers.

Details

Device Path Exerciser test is designed to test the reliability and security of drivers by calling them through various user-mode I/O interfaces with valid, invalid, meaningless, and poorly-formatted buffers and data that will crash the driver if not managed correctly.
Device Path Exerciser is designed to test a single device driver as part of a Device Logo test.
Systems - Device Path Exerciser is designed to test every device driver in the system as part of a Systems Logo test.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running Device Path Exerciser

Prerequisite: Before you can run DRS - Device Path Exerciser, install the device and driver on the test client. Next, install and configure DTM.
To Run DRS - Device Path Exerciser
  • Start DTM Studio.
  • Open or switch to the Device Console window, and then select the machine pool that contains the computer where you want to run the test.
  • In the Available Devices pane, expand the type of device that is associated with your driver, and then select the specific device on which to run the test.
  • In the Available Jobs pane, select the DRS - Device Path Exerciser job.
  • Click Add Selected in the lower-left corner of the Device Console window to add the jobs to the schedule of jobs to be run.
  • Click Schedule Jobs.
Follow the progress of the DRS - Device Path Exerciser job by using Job Monitor. Use the Result Explorer to examine the results of jobs that have completed. The test creates additional log files that contain detailed information about what the test is doing. You can use these log files to help you determine why a test failed. For more information about these files, see Device Path Exerciser Logs in the Windows Driver Kit Documentation.

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Common Scenario Stress with IO

Type: Automated Test

Overview

The Common Scenario Stress with IO job ensures that the device under test accepts and correctly handles numerous Plug and Play (PnP) and power management state change scenarios. This currently includes disable/enable and suspend/hibernate/wake scenarios. Additionally, it tries to ensure that the device is still functional after these changes in state through SimpleIO stress testing.

Details

The Common Scenario Stress with IO job is the "Driver Reliability" version of the Common_Scenario_Stress_with_IO automated scenario.
The job directs the underlying scenario to target the device under test via it's service name. Additionally, the underlying scenario can only run disable/enable scenarios on disableable devices. A disableable device is defined to be a device that has the "Disable" menu option available in Device Manager and is not class 'LegacyDriver'. If the scenario is targeted at a non-disableable device, it will revert to just the power management scenarios.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running Common Scenario Stress with IO

Prerequisite: Before you can run DRS- Sleep Stress Disable-Enable with I/O, install the device and driver on the test client. Next, install and configure DTM.
To Run Common Scenario Stress with IO
  • Start DTM Studio.
  • Open or switch to the Device Console window, and then select the machine pool that contains the computer where you want to run the test.
  • In the Available Devices pane, expand the type of device that is associated with your driver, and then select the specific device on which to run the test.
  • In the Available Jobs pane, select the Common Scenario Stress with IO job.
  • Click Add Selected in the lower-left corner of the Device Console window to add the jobs to the schedule of jobs to be run.
  • Click Schedule Jobs.
  • Follow the progress of the Common Scenario Stress with IO job by using Job Monitor. Use the Result Explorer to examine the results of jobs that have completed. The test creates additional log files that contain detailed information about what the test is doing. You can use these log files to help you determine why a test failed.

Command Syntax

Command option | Description

Troubleshooting
The underlying scenario was developed using the new Windows Device Testing Framework (WDTF). The WDK contains extensive documentation for using and extending this framework in your own driver development process. Search the WDK help documentation for "Windows Device Testing Framework" for more information. Details on the specific operation of this scenario can be found in the table of contents under "Windows Driver Kit" -> "Other Tools" -> "Windows Device Testing Framework" -> "Automated Scenarios".

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Static Driver Verifier

Overview

Static Driver Verifier (SDV) is not a required tool for Windows Logo programs however its use is highly encouraged. In the future, SDV might become a required test for Windows Logo if a kernel-mode device drivers or service is included in the submission package.

Details

SDV is a compile-time verification tool that explores possible execution paths in a device driver for error conditions, such as calling the IoCompleteRequest routine twice. SDV is an essential unit-testing tool for device drivers. It places a driver in a hostile environment and systematically tests code paths through the driver by looking for violations of Windows Driver Model (WDM) usage rules. SDV is limited to specific types of device drivers that are written in C. This is an optional test in the DRS program. However, you are strongly encouraged to run SDV on your source code. Microsoft continues to invest in the development of the SDV tool.
Static Driver Verifier can test only drivers and libraries that are written in C and that are contained in source files with a .c file name extension. This tool cannot analyze drivers that are written in C++ or any other language.
Static Driver Verifier verifies only Windows Driver Model (WDM)-compliant device drivers (that is, function drivers, filter drivers, and bus drivers), file system filter drivers, and drivers that are written for Windows NT 4.0.
Static Driver Verifier cannot verify drivers that are built by using Kernel-Mode Driver Framework (KMDF).
For more information about other factors that might prevent testing, see Static Driver Verifier Limitations.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running Static Driver Verifier

Prerequisite: If you plan to use the option to run Static Driver Verifier from DTM, before you begin install the WDK build environment and your device driver source files on the test client.
To Run DRS - Static Driver Verifier
  • Start DTM Studio.
  • Open or switch to the Device Console window, and then select the machine pool that contains the computer where you want to run the test.
  • In the Available Devices pane, expand the type of device that is associated with your driver, and then select the specific device on which to run the test.
  • In the Available Jobs pane, select the DRS - Static Driver Verifier job.
  • Click Add Selected in the lower-left corner of the Device Console window to add the jobs to the schedule of jobs to execute.
  • In the Add Selected pane, right-click the DRS - Static Driver Verifier job and select Edit Parameters.
  • For the DRS - Static Driver Verifier job, you must provide values for some of the parameters. The descriptions that follow the figure explain the parameters and the values they require.
LogFileName
The path and name of the log file that contains the test results. If you run the DRS - Static Driver Verifier job, leave this value <NULL>.
If you run Static Driver Verifier from a command prompt and want to import the test results, provide the path and name of the log file (SDV-DQS.xml is the default). Static Driver Verifier generates the SDV-DQS.xml file and places it in the \SDV directory in your source tree. For example, if you ran the tool on the Toaster sample bus driver, the vaule for LogFileName would be C:\WINDDK\version#\src\general\toaster\bus\SDV\SDV-DQS.xml.
WDKDriverName
The name of the driver to build. This value is automatically filled in when the job is scheduled. You can leave the value <NULL>.
DriverType
The driver model or type. DriverType currently supports the following values: WDM, NDIS, LEGACY, FSD, and OTHER. You must specify one of these value for DriverType. The default value is <NULL>.
DriverBasePath
The root directory of your driver source tree. In many cases, the value you use for DriverBasePath is the same value you use for DriverSrcPath. For example, if your source files are in C:\Winddk\5234\Src\Wdm\Wmi\Wmifilt, you would use the same path as the value for DriverBasePath.
However, if you build related drivers and use a single hierarchical directory structure, you would specify the topmost directory as DriverBasePath. For example, in the following directory listing, Network_Drivers is the root directory for the Miniport and Intermediate drivers.
Network_Drivers (DriverBasePath)
Miniport (DriverSrcPath)
Intermediate (DriverSrcPath)
Lib (DriverLibPath)
You can specify DriverBasePath by using drive letters (for example, C:\) or Universal Naming Convention (UNC) paths (for example, \\server\\Network_Drivers). The default value is <NULL>. You must specify the path to the root directory or the source file directory.
DriverSrcPath
The path to the driver source code. For example, if you were testing the sample WMI filter driver on the test client, DriverSrcPath might be similar to the following:
C:\Winddk\5234\Src\Wdm\Wmi\Wmifilt
You can specify DriverSrcPath by using drive letters (for example, C:\) or Universal Naming Convention (UNC) paths (for example, \\server\Network_Drivers\Miniport). The default value is <NULL>. You must specify the path to the source file directory.
DriverLibPath
The path to the library directory (if the driver links to library files). The default value is <NULL>. If your driver links to library files, you must specify the path. You can specify multiple library paths by using a semicolon as the delimiter, as the following example shows.
\\driver_dev_sys\Nework_Adapters\Lib1;\\driver_dev_sys\Nework_Adapters\Lib2
BuildType
The type of build environment that you are using on the test client. The default value is [WTT/Build]. If you use the default value [WTT/Build], the correct value is selected automatically. To set the value explicitly, use the options Check ( KRISTI RASMUSSEN: Same as above. Check or checked?) or Free.
OS
The version of the Microsoft Windows operating system that is running on the test client. The default value is [WTT/OS]. If you use the default value [WTT/OS], the correct value is selected automatically. To set the value explicitly, use one of the following values:
· LH, LONGHORN, Windows Vista (for Windows Vista)
· w2003, Windows Server 2003 (for Windows Server 2003)
· XP, Windows XP (for Windows XP)
Processor
The type of processor that the test client uses. The default value is [WTT/Build]. If you use the default value [WTT/Build], the correct value is selected automatically. To set the value explicitly, use the options x86, amd64, x64, or ia64. If you are running DRS - Static Driver Verifier on a test client that uses an x64 processor, set the value to x86. DRS - Static Driver Verifier is not supported on x64-based computers.
  • Click Schedule Jobs.
  • Follow the progress of the DRS - Static Driver Verifier job by using Job Monitor. When Static Driver Verifier is finished examining the code, the test parses the log file. If any warnings are found, they are reported in the job results. Use the Result Explorer to examine the results of jobs that have completed

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Sleep Stress with IO

Type: Automated Test

Overview

This Sleep Stress with IO job ensures that the device under test permits the system to be cycled through all supported sleep states. Additionally, it tries to ensure that the device is still functional after these changes in state through SimpleIO stress testing.

Details

The Sleep Stress with IO job is the "Driver Reliability" version of the Sleep_Stress_with_IO automated scenario.
The job directs the underlying scenario to target the device under test via it's service name.
The script has following command line parameters:
DeviceID – device to run stress on. By default, the test runs IO stress on all media, net and disk devices.
MinutesToRun – amount of time the script will run.
SleepPeriod – RTC timer will be set to this value (in minutes) each time the machine goes to sleep.
MinIOPeriod and MaxIOPeriod specify the time (in milliseconds) IO tests will be running between subsequent sleep cycles.
ResumeDelay – delay in milliseconds after machine resumes from sleep and before next IO cycle starts. It is needed to allow devices restore their working state (renew IP address for network card etc.)
The script runs IO tests for a random amount of time between min and max values. Then it pauses the tests, picks up a random supported sleep state and sends machine to sleep setting RTC to wake it up. After the machine wakes up these actions are repeated until MinutesToRun minutes pass.

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running Sleep Stress with IO

Prerequisite: Before you can run Sleep Stress with I/O, install the device and driver on the test client. Next, install and configure DTM.
To Run Sleep Stress with I/O Test
  • Start DTM Studio.
  • Open or switch to the Device Console window, and then select the machine pool that contains the computer where you want to run the test.
  • In the Available Devices pane, expand the type of device that is associated with your driver, and then select the specific device on which to run the test.
  • In the Available Jobs pane, select the Sleep Stress with I/O job.
  • Click Add Selected in the lower-left corner of the Device Console window to add the jobs to the schedule of jobs to be run.
  • Click Schedule Jobs.
  • Follow the progress of the Sleep Stress with I/O job by using Job Monitor. Use the Result Explorer to examine the results of jobs that have completed. The test creates additional log files that contain detailed information about what the test is doing. You can use these log files to help you determine why a test failed.

Command Syntax

Command option | Description

Troubleshooting
The underlying scenario was developed using the new Windows Device Testing Framework (WDTF). The WDK contains extensive documentation for using and extending this framework in your own driver development process. Search the WDK help documentation for "Windows Device Testing Framework" for more information. Details on the specific operation of this test tool can be found in the table of contents under "Windows Driver Kit" -> "Other Tools" -> "Windows Device Testing Framework" -> "Automated Scenarios".

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Driver Verifier

Type: Automated Test

Overview

Driver Verifier monitors kernel-mode drivers and graphics drivers to verify that they are not making invalid function calls or causing system corruption. This tool can perform a large number of checks on these drivers and can subject them to a variety of stresses and tests to find improper behavior.

Details

Refer to the Windows Driver Kit documentation for Driver Verifier full description and theory of operation.
Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running Driver Verifier

Prerequisite: Before you can run DRS - Driver Verifier, install the device and driver on the test client. Next, install and configure DTM.
To Run DRS - Driver Verifier
  • Start DTM Studio.
  • Open or switch to the Device Console window, and then select the machine pool that contains the computer where you want to run the test.
  • In the Available Devices pane, expand the type of device that is associated with your driver, and then select the specific device on which to run the test.
  • In the Available Jobs pane, select the DRS - Driver Verifier job.
  • Click Add Selected in the lower-left corner of the Device Console window to add the jobs to the schedule of jobs to be run.
  • Click Schedule Jobs.
  • Follow the progress of the DRS - Driver Verifier job by using Job Monitor. Use the Result Explorer to examine the results of jobs that have completed. The test creates additional log files that contain detailed information about what the test is doing. You can use these log files to help you determine why a test failed. For more information about the test, see Driver Verifier in the Windows Driver Kit documentation.

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Audio Tests

Test name | Target operating system | Test description
SysFX UI Test | Windows Vista | SysFX UI Test is an automated, scripted user interface test which verifies that each extensible vendor provided system effects property page set for the MM Control Panel CPL implements one checkbox UI element for the purposes of enabling & disabling the said audio effect per the WLP Logo requirements.
FidelityTest | Windows Vista | Test to verify hardware audio fidelity using Audio Precision test device.
CardBus Bridge Power Management Register Test | Windows Vista Windows XP | The CardBus Bridge Power Management Register test searches the CardBus Bridge/Card configuration space for each of the CardBus device functions and verifies that the power management registers are correctly implemented.
KS Topology Test | Windows Vista Windows 2000 | KS Topology Test tests audio devices to make sure that the topology filters revealed behave properly and adhere to Microsoft requirements.
Audio SysFX Test | Windows Vista | Test for SysFx (both GFx and LFx) APO implementation. Verifies correct behavior of APO and more strict guidelines specifically for SysFx.
Digital Rights Management Test (Vista) | Windows Vista | The Digital Rights Management (DRM) test verifies that the device and driver properly protect the copyrighted digital audio stream.
CardBus Card Configuration Space Register test | Windows Vista Windows XP | This test determines the correct implementation of the CardBus card’s configuration space support registers.
MIDI Driver Test | Windows Vista Windows XP | The MIDDRV32 test ensures that an audio device complies with the Multimedia SDK documentation related to the MIDI family of multimedia APIs.
Digital Rights Management Test (Legacy) | Windows XP Windows 2000 | The Digital Rights Management (DRM) test verifies that the device and driver properly protect the copyrighted digital audio stream.
CardBus Card Common Silicon Guidelines test | Windows Vista Windows XP | This test determines whether the CardBus card’s configuration space supports the Common Silicon Guidelines as described in PC Card Standard Guidelines, Volume 10.


SysFX UI Test

Type: Automated Test

Overview

SysFX UI Test is an automated, scripted user interface test which verifies that each extensible vendor provided system effects property page set for the MM Control Panel CPL implements one checkbox UI element for the purposes of enabling & disabling the said audio effect per the WLP Logo requirements.

Details

The theory is to ensure that users have the ability to enable & disable vendor provided effects on each endpoint. Each checkbox must be visible on at least one (1) property page in each property page set, on each endpoint whereas vendor UI is provided. The checkbox must toggle the correct registry key value per specifications to set its state to either enabled or disabled. The checkbox must further have the correct Control ID set so that it can be identified by this test.
The test is a fully automated script written for the WinFX API, which is an integral part of the Vista OS.

Run Time: 5 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running SysFX UI Test

Command Syntax

Command option | Description
wscript.exe sysfx.ui.wdk.verifyenabledisablecheckbox.wsf | Without any options, the test runs through its default verification.

Code Tour

File Manifest

File | Location
sysfx.ui.wdk.verifyenabledisablecheckbox.wsf | [WTT\TestBinRoot]\nttest\multimediatest\deviceui\UIScripts\sysfx\sysfx.ui.wdk.verifyenabledisablecheckbox.wsf

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


FidelityTest

Type: Automated Test

Overview

Test to verify hardware audio fidelity using Audio Precision test device.

Details

FidelityTest will verify that the audio device meets the WLP requirements for a high-fidelity audio playback experience. The test plays a tone which is analyzed by an Audio Precision System Two device connected to the analog output jack of the system. A second computer (the AP Host) runs Audio Precision’s APWin or AP2700 software and controls the AP analyzer. The basic test procedure is for the System Under Test (SUT) to play a signal while the analyzer listens. This coordination happens over the local network.
FidelityTest takes four measurements:

* Output Level Test plays a digital full-scale signal and verifies that it meets the Full-Scale Output Voltage requirement in WLP Device Fidelity Requirements.

* Dynamic Range Test takes a noise floor measurement in presence of signal per AES-17, and verifies that the measurement meets the Dynamic Range requirement in WLP Device Fidelity Requirements.

* THD+N Test takes a THD+N measurement and verifies the measurement per the WLP Device Fidelity Requirements document.

* Magnitude Response Test measures the frequency response of the device and verifies it meets the Magnitude Response requirement in the WLP Device Fidelity Requirements.
All test cases return PASS or FAIL, and the generated log file contains the actual measurement recorded.

Run Time: 15 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • AP Host computer

Running FidelityTest

TBD

Command Syntax

Command option | Description
TBD |

Cautions

TBD.
LOTS of stuff to put here.

Troubleshooting
See Audio Precision documentation for connecting AP analyzer to AP Host machine

Code Tour

File Manifest

File | Location
fidelitytestapp.exe, fidelitytest.dll, audiolab.dll | [testbinroot]\nttest\multimediatest\avcore\audio\wdk

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


KS Topology Test

Type: Automated Test

Overview

KS Topology Test tests audio devices to make sure that the topology filters revealed behave properly and adhere to Microsoft requirements.

Details

KS Topology Test tests all the various components of the audio topology filters and the general functioning of the filter as a whole to confirm proper behavior and adherence to Microsoft requirements. The tests check all filters, nodes, pins, node properties and their layouts.
Nodes are tested to make sure that the number of inputs and outputs is valid and numbered correctly and that their required properties are present. Also no orphaned nodes are allowed.
Node Properties are checked to see if their messages are well formatted and behave in the required fashion. The KSPROPERTY_DESCRIPTOR values are checked including the Access flags and the KSPROPERTY_MEMBERSHEADER structure for channel properties. Also the tests make sure that each channel exists and functions within the specified ranges.
Pins are checked for valid KsDataRange and KsDataFormat values. The pin DataFlow values are validated to make sure they comply with the general flow of the topology graph. Also no orphaned pins are allowed.
Filters are checked to make sure the connections between nodes (internal connections) and the physical connections (connections between filters) are valid and consistent. Also, a test checks to see if there is a valid path of connections between pins that correspond to physical jacks on an audio device and source/sink pins in the topology.
For details on the Microsoft requirements for Audio devices, please refer to the "Audio" Section under "Device and Driver Technologies" in MSDN.

Run Time:
Log File: KsTopTest.log
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Windows 2000
  • Windows 9x
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running KS Topology Test

All test cases return PASS or FAIL. Review the test results in the log file (KsTopTest.log) for specific details about failures.

Command Syntax

Command option | Description
KsTopTest.exe | Without any options, the test enumerates devices
-c [string] | Starts the app and runs the testcases specified in the .profile
-h [string] | Specifies the PnP ID of the device to be tested
KsTopTest.pro | The .profile of testcases to be run

Code Tour

File Manifest

File | Location
KsTopTest.exe | [testbinroot]\nttest\multimediatest\AVCore\Audio\WDK\

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Audio SysFX Test

Type: Automated Test

Overview

Test for SysFx (both GFx and LFx) APO implementation.
Verifies correct behavior of APO and more strict guidelines specifically for SysFx.

Details

Audio SysFX Test is a certification test for audio device drivers, specifically for audio drivers that install a SysFx (either a Global Fx, a Local Fx, or both).
The test will enumerate all endpoints on all installed devices and list any installed LFx and GFx for each endpoint.
Test cases are run against selected endpoint/SysFx combination. By default, all such SysFx are selected; you may enable or disable tested SysFx through Options.Select Devices.
These tests include:
General tests - which verify any interface support the APO claims.
IAudioProcessingObject tests - which verify each method on this interface for correct behavior.
IAudioProcessingObjectRT tests - which verify each method on this interface for correct behavior.
Certification tests - verifies libraries that implement SysFx are signed.
All test cases return either PASS or FAIL.
Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running Audio SysFX Test

The test log will provide details on any failures.

Command Syntax

Command option | Description
ExtFxTst.exe | Without any options, the test enumerates devices
-c [string] | starts the app and runs the testcases specified in the .profile
-h [string] | specifies the PnP ID of the device to be tested
ExtFxTst_WDK.pro | the .profile of testcases to be run

Cautions

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location
ExtFxTst.exe | [testbinroot]\nttest\multimediatest\AVCore\Audio\WDK\

Click to show or hide information. Test Assertions

Test Assertions

TEMP-AUD-003 System effect APOs comply with Windows Protected Environment conformance and compliance criteria
Test Assertion GUID: a9c09f20-b573-4f91-a2ac-abc1154f0389

Windows Logo Program: ERROR ERROR

Additional Information: This test verifies that the appropriate Audio Processing Object (APOs) are loaded into the system effect infrastructure by the audio device driver INF must be signed with a certificate indicating conformance and compliance with the robustness rules of the Windows Protected Environment.


Digital Rights Management Test (Vista)

Type: Automated Test

Overview

The Digital Rights Management (DRM) test verifies that the device and driver properly protect the copyrighted digital audio stream.

Details

This Digital Rights Management (DRM) test verifies that the test device and the driver cooperate with system components to protect the copyrighted digital audio stream. The test creates copyrighted streams with different usage rights to test the audio subsystem. The focus of this test is on the audio driver portion of DRM, the trusted audio drivers.
For example, if the usage rights indicate that the loop-back capture should be disabled, the test verifies that the audio subsystem has correctly disabled loop-back capture.
For information about the DRM implementation in Windows, please refer to the "Digital Rights Management" section for Streaming Devices in the Windows DDK.

Run Time:
Log File: DRMTest.log
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • If the sound card has S/PDIF output, a receiver with S/PDIF input or a speaker with S/PDIF input is required.

Running Digital Rights Management Test (Vista)

All test cases return PASS or FAIL. Review the test results in the log file (Drmtest.log) for specific details about failures.

Command Syntax

Command option | Description
DRMTest.exe | Without any options, the test enumerates devices
-c [string] | Starts the app and runs the testcases specified in the .profile
-h [string] | Specifies the PnP ID of the device to be tested
wdk_drmtest.pro | The .profile of testcases to be run

Code Tour

File Manifest

File | Location
DRMTest.exe | [testbinroot]\nttest\multimediatest\AVCore\Audio\WDK\

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


MIDI Driver Test

Type: Automated Test

Overview

The MIDDRV32 test ensures that an audio device complies with the Multimedia SDK documentation related to the MIDI family of multimedia APIs.

Details

This test requires an audio device and driver installed in a test system. A MIDI loopback cable must be attached to the device being tested.
This test is installed as part of the WDK (Audio) kit.
It enumerates all MIDI in/out devices using midiOutGetNumDevs and midiInGetNumDevs API.
Depending on the type of devices found (In/Out). The test dynamically decides to run the appropriate testcases.
The app tests for Device Control, Buffer Preparation, MIDI Recording, SysEx Message Recording etc.
All test cases return PASS, FAIL or PENDING. Review the test results in the generated log file for specific details about failures. A test case returns PENDING when it determines that the environment is not set up properly for the test. For example, if the test is run with no output port selected and a given test case requires an output port, the test case returns PENDING.

Run Time: 10 minutes
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Windows XP
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • MIDI device

Running MIDI Driver Test

Command Syntax

Command option | Description
middrv.exe | Without any options, the test launches the GUI
-c [string] | starts the app and runs the testcases specified in the .pro file specified by [string]
-h [string] | specifies the PnP id of the device to be used by the testcases. Default is all devices

Troubleshooting

Test application window logs messages including success/failure results. Test also creates a detailed log file.

Code Tour

File Manifest

File | Location
middrv.exe | [testbinroot]\nttest\multimediatest\avcore\audio\wdk\

Click to show or hide information. Test Assertions

Test Assertions

16.10.1 MIDI Get Device Capabilities – The device must correctly populate the MIDIINCAPS structure on a call to midiInGetDevCaps.
Test Assertion GUID:

16.10.2 MIDM_GETDEVCAPS with various sizes of MIDIINCAPS
Test Assertion GUID:

16.10.3 MODM Get Device Capabilities – The device must correctly populate the MIDIOUTCAPS structure on a call to midiOutGetDevCaps.
Test Assertion GUID:

16.10.4 MODM Get Device Capabilities with various sized MIDIOUTCAPS
Test Assertion GUID:

16.10.5 MIDM_OPEN and MIDM_CLOSE with function callback
Test Assertion GUID:

16.10.6 MIDM_OPEN and MIDM_CLOSE with window callback
Test Assertion GUID:

16.10.7 MIDM_OPEN and MIDM_CLOSE with event callback
Test Assertion GUID:

16.10.8 MIDM_CLOSE while buffers are in the queue
Test Assertion GUID:

16.10.9 MODM_OPEN and MODM_CLOSE with function callback
Test Assertion GUID:

16.10.10 MODM_OPEN and MODM_CLOSE with window callback
Test Assertion GUID:

16.10.11 MODM_OPEN and MODM_CLOSE with event callback
Test Assertion GUID:

16.10.12 MIDM_PREPARE and MIDM_UNPREPARE with various buffer sizes
Test Assertion GUID:

16.10.13 MODM_PREPARE and MODM_UNPREPARE with various buffer sizes
Test Assertion GUID:

16.10.14 MIDI Start while already recording short message
Test Assertion GUID:

16.10.15 MIDI Start while already recording SysEx message
Test Assertion GUID:

16.10.16 MIDI Start after recording is stopped
Test Assertion GUID:

16.10.17 MIDI Start after recording is reset
Test Assertion GUID:

16.10.18 MIDI Start with no buffers to record SysEx message
Test Assertion GUID:

16.10.19 MIDI Stop while recording SysEx message
Test Assertion GUID:

16.10.20 MIDI Stop after recording is reset
Test Assertion GUID:

16.10.21 MIDI Stop, verify recording stops
Test Assertion GUID:

16.10.22 MIDI Reset while recording SysEx messages
Test Assertion GUID:

16.10.23 MIDI Reset after recording is stopped
Test Assertion GUID:

16.10.24 MIDI Reset while recording short messages only
Test Assertion GUID:

16.10.25 MIM DATA function callback verification
Test Assertion GUID:

16.10.26 MIM LONGDATA function callback verification
Test Assertion GUID:

16.10.27 MIM LONGERROR function callback verification
Test Assertion GUID:

16.10.28 MIM LONGDATA without callbacks
Test Assertion GUID:

16.10.29 MODM LONGDATA without callbacks
Test Assertion GUID:

16.10.30 MIDM Add Buffer before recording is started
Test Assertion GUID:

16.10.31 MIDM Add Buffer after recording is started
Test Assertion GUID:

16.10.32 MIDM Add Buffer with five buffers of various sizes
Test Assertion GUID:

16.10.33 SysEx message recording with buffers same size as SysEx messages
Test Assertion GUID:

16.10.34 SysEx message recording with buffers smaller than the SysEx message
Test Assertion GUID:

16.10.35 SysEx message recording with buffers larger than the SysEx message
Test Assertion GUID:

16.10.36 SysEx msg recording and running status
Test Assertion GUID:

16.10.37 Short msg recording with running status
Test Assertion GUID:

16.10.47 MIDI Volume Control message verification
Test Assertion GUID:

16.10.48 Basic midiOutGetVolume/midiOutSetVolume test
Test Assertion GUID:


Digital Rights Management Test (Legacy)

Overview

The Digital Rights Management (DRM) test verifies that the device and driver properly protect the copyrighted digital audio stream.

Details

This Digital Rights Management (DRM) test verifies that the test device and the driver cooperate with system components to protect the copyrighted digital audio stream. The test creates copyrighted streams with different usage rights to test the audio subsystem. The focus of this test is on the audio driver portion of DRM, the trusted audio drivers.
For example, if the usage rights indicate that the loop-back capture should be disabled, the test verifies that the audio subsystem has correctly disabled loop-back capture.
For information about the DRM implementation in Windows, please refer to the "Digital Rights Management" section for Streaming Devices in the Windows DDK.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows XP
  • Windows 2000
  • Windows 9x
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • If the sound card has S/PDIF output, a receiver with S/PDIF input or a speaker with S/PDIF input is required.

Running Digital Rights Management Test (Legacy)

All test cases return PASS or FAIL. Review the test results in the log file (Drmtest.log) for specific details about failures.

Command Syntax

Command option | Description

Code Tour

File Manifest

File | Location
Legacy_DRMTest.exe | Without any options, the test enumerates devices
-c [string] | Starts the app and runs the testcases specified in the .profile
-h [string] | Specifies the PnP ID of the device to be tested
wdk_legacy_drmtest.pro | The .profile of testcases to be run

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Kernel-Mode Driver Tests

Test name | Target operating system | Test description
Validate Color Profiles | Windows Vista | This test validates that color profiles can be used by Windows and that the color profile meets basic profile file format requirements.
Resume From Standby | Windows Vista | RPAT is a tool that developers, testers and system integrators can use to discover which drivers are creating bottleneck when a system is resuming from S3 standby mode. It analyzes the output from PwrTst and displays statistics for each individual driver. The tool will help system integrators figure out where to focus their efforts to meet the new Vista resume from standby requirements.
Power Management Test Tool (PwrTest) | Windows Vista | PwrTest is a test tool that enables developers, testers and system integrators to exercise and record power management information from the system. PwrTest can be used to automate sleep and resume transitions as well as record processor power management and battery information from the system over a period of time. PwrTest features robust logging and a command-line interface. PwrTest is capable of logging information to both a Windows Test Technologies (WTL) and XML file format.


Modem Tests

Test name | Target operating system | Test description
Fax Modem Logo Test | Windows Vista | The Fax Modem Logo Test tool is an automated Windows Driver Kit (WDK) tool for testing the capabilities of modems with respect to faxing. This tool examines the ability of a modem to work with Microsoft Windows Vista software and tests the fax capability. The modem is fax-capable if it can receive and send a 5-page CCITT Group 4 (2d) Fax.


Fax Modem Logo Test

Type: Automated Test

Overview

The Fax Modem Logo Test tool is an automated Windows Driver Kit (WDK) tool for testing the capabilities of modems with respect to faxing.
This tool examines the ability of a modem to work with Microsoft Windows Vista software and tests the fax capability. The modem is fax-capable if it can receive and send a 5-page CCITT Group 4 (2d) Fax.

Details

This test verifies the ability of the Test Fax modem to receive and send a 5-page CCITT Group 4 (2d) Fax. The fax is sent from the Reference Fax modem to the Test Fax modem, the Test Fax modem sends the fax back to the Reference Fax modem, and the two steps are repeated.

The Reference Fax modem is the USR Courier V.Everything modem.

Run Time: 30 minutes
Log File: FE8F9998-FB17-4f11-BCB9-C640B4F3D5CD.xml
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running Fax Modem Logo Test

On the Server computer:

1. Install the Test Fax modem.

2. Start the FaxVrfy test application.

3. Verify that the FaxVrfy test application is configured to receive (Options > Receive).

4. Click the Start button.
On the Client computer:
1. Install the Reference Fax modem.

2. Start the FaxVrfy test application.

3. Verify that the application is configured to send (Options > Send).

4. Provide the phone number of the Test Fax modem in the Send to field.

5. Provide the phone number of the Reference Fax modem in the Receive on field.

6. Click the Start button.

The results will be displayed within the Status section and logged to the log file.

Command Syntax

Command option | Description
faxvrfy.exe | Without any options, the test launches the graphical user interface (GUI) in receive mode.
-? /? or -h /h | Optional. Opens the help file.
/bvt or -bvt | Optional. Starts a BVT test. Sends and receives a 5-page fax once.
/s or -s | Optional. Sets the computer in send mode. The default mode is receive mode.
/r or -r | Optional. Sets the computer in receive mode. This mode is the default mode.
/x or -x | Optional. Does not check if the correct TSID is received.
/modem: or -modem: | Optional. Supply which device to use for faxing; otherwise, the default device will be used.
/devinstid: or -devinstid: | Optional. Supply which device instance ID to use for faxing; otherwise, the default device will be used.
/auto or -auto | Optional. Run the test in automated mode. This option sends and receives a 5-page fax twice.
/snd: or -snd: | Optional. Sets the SndTo phone number. Can be set in the user interface (UI).
/rcv: or -rcv: | Optional. Sets the RcvFrom phone number. Can be set in the user interface (UI).

Troubleshooting

1. "Cannot initialize the FaxRcv Routing Extension"
Verify Faxrcv.dll is in the same directory as Faxvrfy.exe.
2. "There are no Fax Ports installed"
Verify that the modem is installed correctly.
3. "No Dial Tone"
Verify that a working phone line is plugged into the modem.
4. "Busy"
Verify that the Send to and Receive on phone numbers are correct, or verify that the phone numbers are not busy.
5. "No Answer"
Verify that the Send to and Receive on phone numbers are correct, or verify that the correct phone lines are plugged into the correct modems.
6. "Fatal Error"
This error most likely indicates an error in the fax registry keys that are specified in the INF file. Review the Microsoft Windows 98 and Windows NT 5.0 Modem Development Kit (MDK) and Microsoft Windows 98 and Windows NT 5.0 Modem Registry Reference.

Verify that CINF reported no fax errors and no fax warnings.
7. "Unexpected State"
This error most likely indicates an error in the fax registry keys that are specified in the INF file. Review the Microsoft Windows 98 and Windows NT 5.0 Modem Development Kit (MDK) and Microsoft Windows 98 and Windows NT 5.0 Modem Registry Reference.

Verify that CINF reported no fax errors and no fax warnings.
8. "Device Powered Off"
This error most likely indicates an error in the fax registry keys that are specified in the INF file. Review the Microsoft Windows 98 and Windows NT 5.0 Modem Development Kit (MDK) and Microsoft Windows 98 and Windows NT 5.0 Modem Registry Reference.

Verify that CINF reported no fax errors and no fax warnings.
9. "Device Powered On"
This error most likely indicates an error in the fax registry keys that are specified in the INF file. Review the Microsoft Windows 98 and Windows NT 5.0 Modem Development Kit (MDK) and Microsoft Windows 98 and Windows NT 5.0 Modem Registry Reference.

Verify that CINF reported no fax errors and no fax warnings.
10. "There are no Fax Ports available"
This error most likely indicates an error in the fax registry keys that are specified in the INF file. Review the Microsoft Windows 98 and Windows NT 5.0 Modem Development Kit (MDK) and Microsoft Windows 98 and Windows NT 5.0 Modem Registry Reference.

Verify that CINF reported no fax errors and no fax warnings.
11. "Fax Service Stopped"
This error most likely indicates an error in the fax registry keys that are specified in the INF file. Review the Microsoft Windows 98 and Windows NT 5.0 Modem Development Kit (MDK) and Microsoft Windows 98 and Windows NT 5.0 Modem Registry Reference.

Verify that CINF reported no fax errors and no fax warnings.
12. "Invalid Fax"
This error most likely indicates an error in the test setup or the fax registry keys that are specified in the INF file.

Verify that the FaxVrfy test application is setup and running correctly on both the Server and Client computer.

Review the Microsoft Windows 98 and Windows NT 5.0 Modem Development Kit (MDK) and Microsoft Windows 98 and Windows NT 5.0 Modem Registry Reference.

Verify that CINF reported no fax errors and no fax warnings.

Code Tour

File Manifest

File | Location
Faxwhql.tif | //depot/vbl_wcp_um_d2dev/printscan/faxsrv/FaxVerify/faxvrfy
Faxbvt.tif | //depot/vbl_wcp_um_d2dev/printscan/faxsrv/FaxVerify/faxvrfy
Faxvrfy.ini | //depot/vbl_wcp_um_d2dev/printscan/faxsrv/FaxVerify/faxvrfy
Faxvrfy.cnt | //depot/vbl_wcp_um_d2dev/printscan/faxsrv/FaxVerify/faxvrfy
Faxvrfy.exe | //depot/vbl_wcp_um_d2dev/printscan/faxsrv/FaxVerify/faxvrfy
Faxrcv.dll | //depot/vbl_wcp_um_d2dev/printscan/faxsrv/FaxVerify/faxrcv

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Windows Vista Networking Tests

Test name | Target operating system | Test description
LLD2 Responder Verification Tests | Windows Vista | The LLD2 verification tool runs a series of tests against a device implementing the LLD2 responder protocol.
WCN Logo Test | Windows Vista | The test tool verifies that device implements "Wi-Fi Simple Config" protocol and is interoperable with Vista. Tool verifies WCN-Ethernet types of devices. WCN-Ethernet devices uses UPnP as the underlying transport for the protocol. Test tool consists of two parts. One part uses Vista registrar to discover and configure the devices using the COM APIs. The other part implements a separate control point and uses that control point to carry out the tests. The first part makes sure device is interoperable under normal conditions (no errors), and the second part focuses on the error handling capabilities of the device
IPv6 Tester | Windows Vista | The IPv6Test tool runs a series of tests against an intermediate router device to ensure IPv6 compliance
UPnP IGD Byte Counter Tests | Windows Vista | These tests determine whether a UPnP IGD is correctly implementing the byte counters -- TotalBytesSent and TotalBytesReceived
TCP/IP Offload Engine logo tests | Windows Vista | Verify the TCP behavior of a TOE (TCP/IP Offload Engine) network card. Protocol conformance and offload mechanisms are checked.
IrDA Transport | Windows Vista | IrDA Transport is a socket level test tool that is used to test the IrDA drivers. It tests the IrDA drivers by checking if other IrDA devices in range can be detected and data can be sent and received using the IrDA devices without any errors.
STATS | Windows Vista | STATS is a UDP traffic generator tool that provides both client as well as server funcionality.
TCP traffic generator for Wifi performance tests | Windows Vista | The IOCPCLIENT/IOCPSERVER test suite generates a TCP traffic of a given amount within given time
RouterLogo (LMS) | Windows Vista | The purpose of this tool is to verify the correct behavior of the infrastructure devices (router/AP/etc) regarding QOS (DSCP, 802.1p, WiFi WMM and LLTD QoS/qWave listeners).


LLD2 Responder Verification Tests

Type: Automated Test

Overview

The LLD2 verification tool runs a series of tests against a device implementing the LLD2 responder protocol.

Details

This tool tests several aspects of the responder in accordance with the Router logo program's specification requirements. These tests include state transition, credit management, topology discovery, rouge mapper detection, sequence number management, generation number management, and performance and reliability tests.
Run Time: 1 day +
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running LLD2 Responder Verification Tests

Test Bed Setup:
The test machine must have two network interface cards. One must be connected to the same network as the DTM controller and the other must be connected to a LAN port on the IGD.

Command Syntax

Command option | Description

Cautions

It is possible that having multiple responders connected to the IGD could cause errors in testing. Also, not being directly connected to the IGD will almost certainly cause failures.

Troubleshooting

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

The responder must make proper state transitions according to its current state and or the protocol event.
Test Assertion GUID: 588D5CA9-7650-4b3c-9BBE-7ECD0A7B82D7

Windows Logo Program:

Additional Information: The responder implements a state machine, which consists of five states: Quiescent, Hello Pending, Hello Sent, Command Loop and Emitting State. The responder makes proper transition according to its current state and/or the protocol event.

The responder must properly manage its CTC values.
Test Assertion GUID: 512622DA-0B9E-4269-AC30-54AB9D308670

Windows Logo Program: NETWORK-0071 Router, WLAN AP, or Wireless Router has properly formatted metadata for mandatory TLVs according to LLTD

Additional Information: The responder maintains a record of the maximum packets and bytes of the frame that an Emit frame can request it to send. This record, which is called CTC in bytes and packets, is changed by Charge/Emit frames.

The LLTD responder must behave properly during topology discovery sessions.
Test Assertion GUID: BC49A296-98F9-46bc-9493-7CA744F7E7DD

Windows Logo Program:

Additional Information: The responder transmits Probe/Train frame upon receiving Emit frame, and reports observed ARP response, ICMPv6 Neighbor Advertisement frames upon receiving Query frame.

The responder must properly detect rogue mapping sessions.
Test Assertion GUID: 1F011CDB-33F2-4d4c-B4FA-0FE8DB44E9CD

Windows Logo Program:

Additional Information: The responder can only attend one mapper’s discovery session. During its current session, it should transmit Hello frame to the rogue mapper if it detects.

The responder must properly keep track of sequence numbers.
Test Assertion GUID: 50DD834C-13E1-4394-943D-1BE5A6D26950

Windows Logo Program:

Additional Information: Some of the frames from the mapper, such as Charge, Emit and Query frame, carries sequence number. In order to provide acknowledging response and also allow simple error recovery, the responder keeps track of the sequence number.

The responder must properly keep track of its generation number.
Test Assertion GUID: A70690A8-535A-4338-BFEE-F4FDA91D9430

Windows Logo Program:

Additional Information: The responder should keep the previous session’s generation number and update its current generation number upon receiving updates in the Discover frame from the mapper.

The responder must be reliable and have adiquate performance to participate in mapping sessions.
Test Assertion GUID: D17D1A95-2897-41cf-93CF-D5D4B7678428

Windows Logo Program:

Additional Information: These tests seek to ensure that the responder not only meets the requirements of the protocol, but also the expectations of the user. Responders must be able to handle requests in a prompt manner even under load for extended periods of time. .


WCN Logo Test

Type: Automated Test

Overview

The test tool verifies that device implements "Wi-Fi Simple Config" protocol and is interoperable with Vista. Tool verifies WCN-Ethernet types of devices. WCN-Ethernet devices uses UPnP as the underlying transport for the protocol.
Test tool consists of two parts. One part uses Vista registrar to discover and configure the devices using the COM APIs. The other part implements a separate control point and uses that control point to carry out the tests. The first part makes sure device is interoperable under normal conditions (no errors), and the second part focuses on the error handling capabilities of the device

Details

The test tool checks both end-to-end registration process between the device and Vista machine and error handling capability of the device. For end-to-end case, the test tool checks if the device can be properly discovered, configured and passing performance tests while working with Vista machine (Windows Connect Now wizard). For error handling cases, the test tool makes specific aspects listed out in "Simple Config" protocol to see if the device is doing proper time-out or error message response in case of common error scenarios.
The tests that use Vista Registrar are contained in fvt.exe, whereas all the remaining tests are contained in wcnlogocontroller.exe.

Run Time: 1.5 hours
Log File: wcnlogocontroller.wtl,fvt.wtl,wcnlogologfile.txt
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running WCN Logo Test

For WCN-Ethernet devices, if the UPnP traffic is blocked by firewall, the devices won't be able to be discovered by Vista registrars. Because of that, test tools require the firewall to be disabled all time during tests.
The device tested should be connected to the same network as the Vista machine that user is running tests.
Since some tests use native APIs to create a wireless profile, the Vista test machine need to have a wireless card, with its drivers installed. Since "Wi-Fi Simple Config" requires WPA2, please ensure that the wireless card has support for WPA2 as well as WEP and WPA.
Upon configuration, the device changes it state to 'configured', and Vista registrars will not configure an already configured device. Because of that reason, between tests devices should be reset to 'unconfigured' state and this will require the user to intervene the test execution.
Each DTM job has three phases. During setup, the test binaries are copied and if necessary wireless profiles are created. During main phase, the tests are executed and during cleanup phase binaries are removed

Command Syntax

Command option | Description

Cautions

The firewall will block the UPnP traffic, in turn all the tests will fail. Besides Windows Firewall, we advise to turn of any existing firewalls.

Troubleshooting

In case of a failure, please make sure that all test binaries are correctly downloaded. The test binaries are copied to [SystemDrive]\WCNLogo folder. Please make sure all the files specified in Installation section of this document is placed.
All tests requires a discovery for the device and the device UUID is used for discovery. In case of the discovery failure, make sure the firewall is disabled, the Ethernet cable is plugged to both the Vista machine and the device, Vista machine can ping the device, the device is a visible UPnP device (User can verify that using a UPnP spy tool that is used to discover UPnP devices on the network), and the UUID specified in the test parameter is correct.
After the listed conditions are verified, if the device still fails discovery, this is an actual failure.
Wi-Fi Simple Config Proposal

Reference Documentation

Code Tour

File Manifest

File | Location
fvt.exe | [SystemDrive]\WCNLogo
UPnP.dll | [SystemDrive]\WCNLogo
wscutilswrapper.dll | [SystemDrive]\WCNLogo
wcnlogoremoteobject.dll | [SystemDrive]\WCNLogo
wcnlogotestcontroller.exe | [SystemDrive]\WCNLogo
microsoft.wcn.config.dll | [SystemDrive]\WCNLogo
Wireless Profiles | [SystemDrive]\WCNLogo

Click to show or hide information. Test Assertions

Test Assertions

Device should be discovered by WCN discovery API before timeout
Test Assertion GUID: CFCEBC36-CEB2-4482-AE72-DC62748BD903

Windows Logo Program: NETWORK-0086 Router or WLAN AP that implements WCN-Ethernet or WCN-Wi-Fi supports the Windows Connect Now Simple Config protocol

Additional Information: Description: The device should be discovered by Vista registrar in the given period of time. In order for the Vista registrar to discover the device, the WCN-Ethernet device needs to be discoverable by SSDP and the device should implement the specified service. Job parameters: The job only has a single parameter. User should enter the device UUID in the value of "device_uuid" parameter. The parameter must be in entered like "CFCEBC36-CEB2-4482-AE72-DC62748BD903" Procedure: The test calls WCNC discovery API with the given device UUID to see if the device can be discovered. The timeout of the discovery is 30 seconds. Expected Result: The device is discovered before timeout expires.

Vista registrar should be able to configure the device
Test Assertion GUID: 8A91B280-C2FB-485f-9101-33C1A88CE4A4

Windows Logo Program: NETWORK-0086 Router or WLAN AP that implements WCN-Ethernet or WCN-Wi-Fi supports the Windows Connect Now Simple Config protocol

Additional Information: Description: For WCN-Eth, this test verifies that the Vista registrar is able to transfer the profile after carrying out registration protocol. This is the core test that verifies that the device implements registration protocol messaging sequence correctly. Job parameters: The job requires 2 parameter values to be set. User should enter the device UUID in the value of "device_uuid" parameter. The parameter must be in entered like "CFCEBC36-CEB2-4482-AE72-DC62748BD903". User should enter device PIN in the value field of "device_password" parameter. Procedure: The test calls Vista registrar's transfer profile API to transfer profile to the device. Expected Result: The profile should be transferred correctly and the device should be able to access the network with the profile

Metadata should be displayed correctly in message and in Vista WCN wizards
Test Assertion GUID: 0BB59706-596C-4824-BD58-1357DC352451

Windows Logo Program: NETWORK-0086 Router or WLAN AP that implements WCN-Ethernet or WCN-Wi-Fi supports the Windows Connect Now Simple Config protocol

Additional Information: Description: Metadata should be represented correctly in messages and that for best experience with Vista WCN wizards, the displayed device info are correctly set. And that the device can be correctly configured by Vista WCN wizard. The data displayed in wizard is manufacturer, model number and primary device type. Job parameters: The job requires 4 parameter values to be set. User should enter the device UUID in the value of "device_uuid" parameter. The parameter must be in entered like "CFCEBC36-CEB2-4482-AE72-DC62748BD903". User should enter manufacturer name, model number and device type as the values of "manufacturer_name","model_number" and "device_type" parameters. The device type field vaue is case sensitive and should have one of the following values: "Computer", "Server", "Media Center", "Printer", "Scanner", "Digital Still Camera", "NAS", "Router", "Access Point", "Switch", "Television", "Electronic Picture Frame", "Projector", "Audio Receiver", "Media Center Extender", "XBox", "XBox 360", "Play Station", "Windows Mobile" Procedure: This test calls discovery API and waits till the specified device is discovered. Then queries for the manufacturer name, serial number and primary device type. Expected Result: The device should send the manufacturer name, serial number and primary device type with M1 message, and the Vista registrar should be able to decode it correctly.

During configuration if device receives multiple M2 messages from multiple Vista registrars, device should only associate with single one
Test Assertion GUID: 8A5FB11C-1D3A-4c87-9B26-F3DC5776B47B

Windows Logo Program: NETWORK-0086 Router or WLAN AP that implements WCN-Ethernet or WCN-Wi-Fi supports the Windows Connect Now Simple Config protocol

Additional Information: Description: The device can be discovered by multiple registrars. However, after M2 reception, the device should and must only associate with single registrar during one configuration and registration session. If in any case, the registration fails to be completed in 30 seconds time out, the device should be available again for registration of other registrars. Job parameters: The job requires 2 parameter values to be set. User should enter the device UUID in the value of "DeviceUUID" parameter. The parameter must be in entered like "CFCEBC36-CEB2-4482-AE72-DC62748BD903". User should enter device PIN in the value field of "DevicePIN" parameter. Procedure: The device will be discovered by more than one Registrar, and both Registrars will send M2. After that, the enrollee must associate itself to only one vista registrar during configuration. Messages sent by other Registrars during configuration must be discarded. The transfer either succeeds in 30 seconds, or when it fails, after 30 seconds expires, the device can pick any other active registrar for configuration. Expected Result: During multi-registrar response scenario, only one registrar is associated at a time.

In case of multiple registrars, if a registrar sends M2D, the enrollee shouldn’t pick that registrar for the rest of configuration
Test Assertion GUID: 159A99C8-F829-4c66-A477-14E6F7971DE8

Windows Logo Program: NETWORK-0086 Router or WLAN AP that implements WCN-Ethernet or WCN-Wi-Fi supports the Windows Connect Now Simple Config protocol

Additional Information: Description: The device can be discovered by multiple registrars. Normally, when a registrar sends M2, it means the configuration is started and the enrollee should discard all the other messages sent by other registrars. For M2D, the association must not be done. Job parameters: The job requires 2 parameter values to be set. User should enter the device UUID in the value of "DeviceUUID" parameter. The parameter must be in entered like "CFCEBC36-CEB2-4482-AE72-DC62748BD903". User should enter device PIN in the value field of "DevicePIN" parameter. Procedure: The device will be discovered by more than one Registrar, and both Registrars will send M2. After that, the enrollee must associate itself to only one vista registrar during configuration. Messages sent by other Registrars during configuration must be discarded. The transfer either succeeds in 30 seconds, or when it fails, after 30 seconds expires, the device can pick any other active registrar for configuration. It will also make one registrar to send M2D and checks no M3 is received from the device. Expected Result: The device should respond to M2D with an ACK and M2 with M3.

If enrollee detects a message failure (bad message, out of sync message, bad authenticator…) device should not respond and should wait for the valid message
Test Assertion GUID: 67B77C5F-7A82-482c-897B-4B8AF1D7619C

Windows Logo Program: NETWORK-0086 Router or WLAN AP that implements WCN-Ethernet or WCN-Wi-Fi supports the Windows Connect Now Simple Config protocol

Additional Information: Description: During configuration, with the only exception of authentication errors – errors caused by PIN knowledge— device should ignore messages containing errors. Possible errors that can happen are, out of sequence messages, missing TLV values, ill-formatted message, authenticator error… in that case the device should discard the message without replying anything and wait for a valid message without dropping the association. Job parameters: The job requires 2 parameter values to be set. User should enter the device UUID in the value of "DeviceUUID" parameter. The parameter must be in entered like "CFCEBC36-CEB2-4482-AE72-DC62748BD903". User should enter device PIN in the value field of "DevicePIN" parameter. Procedure: This test case tempers frame at each round trip to see if the association or the state information is dropped or not. The scenario for this is Send valid M2 and create an authentication, Send an out of sync message Send a correct message to verify that the session is resumed Send a message with an authenticator error Send the correct message to verify that the session is resumed Send a message with a missing required TLV Send a correct message and finish configuration Expected Result: In case of an error the device should wait for the correct message without dropping the association information.

If device detects an authentication failure (caused by a password mismatch), it should send a NACK immediately and drop the association and reset the state
Test Assertion GUID: 76E0EE6A-A40B-4b04-8BFF-AD28F1858051

Windows Logo Program: NETWORK-0086 Router or WLAN AP that implements WCN-Ethernet or WCN-Wi-Fi supports the Windows Connect Now Simple Config protocol

Additional Information: Description: The device should drop the association and reset the state if it receives a message with authentication error. This is necessary for preventing users from DoS attacks in case of rogue registrars which send messages using random passwords. Job parameters: The job requires 2 parameter values to be set. User should enter the device UUID in the value of "DeviceUUID" parameter. The parameter must be in entered like "CFCEBC36-CEB2-4482-AE72-DC62748BD903". User should enter device PIN in the value field of "DevicePIN" parameter. Procedure: The Registrar will send a message with an authentication failure using an incorrect PIN and try to continue configuration with correct PIN. Expected Result: The device should drop the association upon receipt of the message with authentication error. The next message that the device sends should be ignored.

Transfer of a supported profile to the device should be completed within 30 seconds
Test Assertion GUID: BCF9F868-0A8D-410f-AFC6-D455C2948378

Windows Logo Program: NETWORK-0086 Router or WLAN AP that implements WCN-Ethernet or WCN-Wi-Fi supports the Windows Connect Now Simple Config protocol

Additional Information: Description: The configuration should be completed in 30 seconds. Job parameters: The job requires 2 parameter values to be set. User should enter the device UUID in the value of "DeviceUUID" parameter. The parameter must be in entered like "CFCEBC36-CEB2-4482-AE72-DC62748BD903". User should enter device PIN in the value field of "DevicePIN" parameter. Procedure: The test initiates a profile transfer and the tests if the transfer profile is completed in 30 seconds. Expected Result: The registration protocol should be completed successfully in time. Comments: This test applies to WCN-Ethernet.

All supported types of profiles should successfully be used to configure the AP
Test Assertion GUID: 55BB29BC-7D9F-4234-AD7C-18A643326407

Windows Logo Program: NETWORK-0086 Router or WLAN AP that implements WCN-Ethernet or WCN-Wi-Fi supports the Windows Connect Now Simple Config protocol

Additional Information: Description: The device should be able to be configured by all profile types that it advertises as supported. Job parameters: The job requires 3 parameter values to be set. User should enter the device UUID in the value of "device_uuid" parameter. The parameter must be in entered like "CFCEBC36-CEB2-4482-AE72-DC62748BD903". User should enter device PIN in the value field of "device_password" parameter. User should enter the profile types that device supports in the "accepted_profile_bitmap" parameter. This parameter is a bitmap. The value entered is the decimal value of bitmap. The values are: Open Authentication and WEP Encryption = 1Shared Authentication and WEP Encryption = 2WPAPSK Authentication and TKIP Encryption = 4WPAPSK Authentication and AES Encryption = 8WPAPSK2 Authentication and TKIP Encryption = 16WPAPSK2 Authentication and AES Encryption = 32 The value that needs to be entered is the sum of the values that correspond to the profile types that are supported. i.e. If a device supports all the profile types mentioned, user should set the value of the mentioned parameter to: 63 ( 1 + 2 + 4 + 8 + 16 + 32) If device supports only "Open Authentication and WEP Encryption" and "Shared Authentication and WEP Encryption", the parameter value should be set to: 3 ( 1 + 2) Procedure: This test checks to see if the AP can be configured by all types of profiles that it supported. The test will prepare a profile pool and will try to transfer those profiles. During the test, after each configuration, the application will stop and prompt the user to go on. During this time, user should reset the device to 'unconfigured' state since Vista registrar will not configure and already configured device. Expected Result: All configuration attempts should be successful

Device should tear down association and send a NACK if the registrar and the enrollee is not compatible in terms of authentication/encryption capabilities
Test Assertion GUID: F1A6BEFF-9B90-46fa-A1E8-0E945CFEE9EE

Windows Logo Program: NETWORK-0086 Router or WLAN AP that implements WCN-Ethernet or WCN-Wi-Fi supports the Windows Connect Now Simple Config protocol

Additional Information: Description: During configuration, the Vista registrar and the device exchanges information for encryption/authentication types they support. If the device doesn't support any of authentication/encryption types that Vista registrar supports, the configuration must be terminated with a NACK message and the association must be dropped. Job parameters: The job requires 2 parameter values to be set. User should enter the device UUID in the value of "DeviceUUID" parameter. The parameter must be in entered like "CFCEBC36-CEB2-4482-AE72-DC62748BD903". User should enter device PIN in the value field of "DevicePIN" parameter. Procedure: Upon receipt of M1 message, the Registrar will create an M2 such as the supported encryption/authentication types doesn’t match the device capabilities. When device receives M2, it is expected to send a NACK and drop the association. If device declares that it supports all kinds of authentication/encryption, then this test is stopped at that stage Expected Result: After device receives M2, it should send a NACK and drop the association

Device should tear down association if it doesn’t receive a valid message within the timeout duration (60 seconds)
Test Assertion GUID: 6F3B5064-4523-4466-97A7-C65DB34596E3

Windows Logo Program: NETWORK-0086 Router or WLAN AP that implements WCN-Ethernet or WCN-Wi-Fi supports the Windows Connect Now Simple Config protocol

Additional Information: Description: During configuration, the Registrar and the device creates an association and all the message sent by other registrars will be ignored during association. To prevent DoS in case the registrar goes offline during configuration, the device should drop the association after 60 seconds passed over a valid message. Job parameters: The job requires 2 parameter values to be set. User should enter the device UUID in the value of "DeviceUUID" parameter. The parameter must be in entered like "CFCEBC36-CEB2-4482-AE72-DC62748BD903". User should enter device PIN in the value field of "DevicePIN" parameter. Procedure: The registrar will create an association and in the middle of configuration, it will remain silent longer than the timeout that is defined. After timeout has passed another registrar will try to configure the device. Expected Result: After the timeout occurred, device should drop the association, discard all state information and when new registrar sends a message, it must be able to start the protocol with this new registrar.

WCN Ethernet devices should have physical label or display of the PIN on itself
Test Assertion GUID: F90A0A01-7A50-4849-BC3E-3494689764DA

Windows Logo Program: NETWORK-0083 WLAN AP that supports Ethernet or wireless WCN uses an 8 character PIN

Additional Information: Description: The device should have a physical display of the device PIN. For security purpose, the length of the PIN should be 8 digits if the PIN is static and can be 4 digits if a new PIN is generated each time. Procedure: This test is manual, and user should verify the following - If the device has a fixed PIN, it should be 8 digits and there must be a label displaying that PIN - If the device has a display screen, then it should have a 4 digit device PIN that is renewed whenever the device is reset. (Device resetting instructions can change from device to device and will not be specified here) Expected Result: PIN length is either 8 digits (for static PIN values) or 4 digits (for auto generated PIN) and that the device can be properly configured using WCN wizard. Comments: This test applies to WCN Ethernet.


IPv6 Tester

Type: Automated Test

Overview

The IPv6Test tool runs a series of tests against an intermediate router device to ensure IPv6 compliance

Details

This tool tests several aspects of the router in accordance with the Router logo program's specification requirements. These tests include 6to4 compatibility, teredo compatibility, ECN stability, native IPv6, and hair pinning tests. In each case the "client" performs an address exchange with the "server" to determine the eternal address and port mapping of the IGD. Various tests are then performed using that address mapping to ensure IPv6 compatibility.
The client test will disable all network adapters not connected to the IGD and will re-enable them upon completion of each test

Run Time: 1 hr
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86

Running IPv6 Tester

Test Bed Setup:
These test require two machines. One "Server" which must be multihomed and physically attached to the "WAN" network, and one "client" which must have an interface attached to the "LAN" network.

Both machines must have connectivity to the DTM controller.

Command Syntax

Command option | Description

Cautions

No known issues with interference. If the test is being executed via a wireless connection, the connection must be of good signal, and without electronic interferance.

Click to show or hide information. Test Assertions

Test Assertions

IGD Type Probe test
Test Assertion GUID: 55DE7C9D-49E9-4559-936B-D4E1AC88F43B

Windows Logo Program:

Additional Information: The server and the client attempt to communicate from differing addresses and ports to determine whether the IGD is of a supported type (Conal or Restricted) or unsupported (Symmetric)

IGD Loopback/Hairpin Test
Test Assertion GUID: FC881F83-1F4E-4FAC-A31C-49BCF555A373

Windows Logo Program:

Additional Information: Client attempts to communicate with virtual clients via externally mapped addresses, simulating a hairpin scenario.

IGD supports UPnP IGD 1.0
Test Assertion GUID: 020CDF79-80EA-4757-94FD-34EE31DC0B43

Windows Logo Program:

Additional Information: Client attempts to interrogate IGD using UPnP protocol.

IGD ECN Stability test
Test Assertion GUID: FC881F83-1F4E-4FAC-A31C-49BCF555A337

Windows Logo Program:

Additional Information: Client and server establish a TCP sessions with ECN enabled and send and receive traffic, allowing for explicit congestion notification to negotiate. Test verifies IGD stability during this process.

IGD supports 6to4
Test Assertion GUID: 3279BFCA-EC7B-4541-A6B3-A0E9504E7117

Windows Logo Program:

Additional Information: Client interrogates local machine to determine if IGD has propagated a 6to4 address to the end host

IGD supports native IPv6
Test Assertion GUID: 6A6A487D-7FEE-41A9-AAC0-410527CC7615

Windows Logo Program:

Additional Information: Client interrogates the local machine to determine if the IGD is advertising native ipv6 connectivity


UPnP IGD Byte Counter Tests

Type: Automated Test

Overview

These tests determine whether a UPnP IGD is correctly implementing the byte counters -- TotalBytesSent and TotalBytesReceived

Details

These tests check the byte counter implementation against the following requirements:
  1. Counters are implemented
  2. Counters are updated consistently
  3. Counters are rolled over properly
  4. Counter values are returned within a reasonable period of time when the device is queried
  5. IGD is able to handle simultaneous queries for counter values both from the same computer and from different computers
The tests use the UPnP API to detect the IGD and invoke the GetTotalBytesSent() and GetTotalBytesReceived() actions to determine the counter values. To test whether the counters are updated and rolled over properly the tests exchange random data of fixed sizes with a WAN side computer over a TCP socket connection.

Run Time: 2 hours
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium
  • Internet Gateway Device

Running UPnP IGD Byte Counter Tests

  1. Some tests require that only one computer is connected to the LAN side of the device, some tests require that 2 or more computers are connected to the LAN side of the device and the remaining tests have no such specific constraints. Refer to the test assertions for more details.
  2. Make sure that only one IGD is connected to each LAN side computer.
  3. Make sure that the test computers connected to the LAN side of the device have two network interfaces -- one connected to the LAN side of the IGD and the other connected to the same subnet as that of the WAN interface of the IGD
  4. Make sure the IGD has UPnP turned on
  5. Make sure that UPnP is enabled in the firewall or the firewall is turned off on the test computer
  6. Make sure that the DTM dimension IGD\MachineRole is set to "LAN" on the LAN side computers of the IGD
  7. Make sure that the DTM dimension IGD\MachineRole is set to "WAN" on the WAN side computer of the IGD
  8. Make sure that the IGD hands out private class C IP addresses to the LAN side computers (192.168.*.*)

Command Syntax

Command option | Description

Cautions

For the tests that have specific requirements of having only one test computer connected to the LAN side of the device, make sure that this requirement is met. Otherwise, traffic from other computers may affect the counters and hence may skew the test results.

Troubleshooting

The following troubleshooting steps may be useful if the tests are failing:
  1. Each test prints the information about the IGD it is testing. Check the log file for this information. If this information is not found in the log it means that the test is not able to detect the IGD using UPnP APIs. Verify that the firewall is allowing UPnP traffic or it is turned off. Restart the SSDPSRV service and rerun the test
  2. Check if the device has hung when the test was running. If so, restart or reboot the device and rerun the test
  3. Make sure that the port (default is 4000) used to exchange socket traffic with the WAN-side computer is not used by any other application. If any other application is using it, rerun the test by passing a different port number.

Reference Documentation

Code Tour

File Manifest

File | Location
IGDTestTool.exe | [WTT\TestBinRoot]\nttest\admintest\drizzle\bin

Click to show or hide information. Test Assertions

Test Assertions

GetTotalBytesSent_Returns_Valid_Value GetTotalBytesSent action returns an unsigned non-zero integer value
Test Assertion GUID: 4e1e5d0b-e3ef-420e-940c-34ac532ae82e

Windows Logo Program: NETWORK-0065 Router correctly implements GetTotalBytesSent and GetTotalBytesReceived as defined in the UPnP IGD 1.0 specification

Additional Information: Procedure: Use the UPnP Control Point API to detect the device and invoke the GetTotalBytesSent action Expected Result: The returned value is an unsigned integer > 0 Comments:

GetTotalBytesReceived_Returns_Valid_Value GetTotalBytesReceived action returns an unsigned non-zero integer value
Test Assertion GUID: 16a16a0a-0354-41a3-8713-525c2828571a

Windows Logo Program: NETWORK-0065 Router correctly implements GetTotalBytesSent and GetTotalBytesReceived as defined in the UPnP IGD 1.0 specification

Additional Information: Procedure: Use the UPnP Control Point API to detect the device and invoke the GetTotalBytesReceived action Expected Result: The returned value is an unsigned integer > 0 Comments:

TotalBytesSent_Counter_Updated TotalBytesSent variable is updated whenever data is sent across the WAN interface
Test Assertion GUID: 1153f8b1-1f87-4b72-a9ae-500bcd41acd8

Windows Logo Program: NETWORK-0065 Router correctly implements GetTotalBytesSent and GetTotalBytesReceived as defined in the UPnP IGD 1.0 specification

Additional Information: Procedure: Use the UPnP Control Point API to detect the device and invoke the GetTotalBytesSent action Assign the returned value to a variable called initial Generate a random number and call it DataSize. Send DataSize bytes of data to a computer on the WAN side of the device Invoke the GetTotalBytesSent action again and assign the returned value to a variable called current Verify that current - initial >= DataSize Repeat steps 3-6 for another 4 times Expected Result: current - initial >= DataSize Comments: Make sure that there is only one computer connected to the device and only one device is connected to the computer for this test

TotalBytesReceived_Counter_Updated TotalBytesReceived variable is updated whenever data is sent across the WAN interface
Test Assertion GUID: 9804dc89-9cb1-4a2d-9010-da7e67b43e30

Windows Logo Program: NETWORK-0065 Router correctly implements GetTotalBytesSent and GetTotalBytesReceived as defined in the UPnP IGD 1.0 specification

Additional Information: Procedure: Use the UPnP Control Point API to detect the device and invoke the GetTotalBytesSent action Assign the returned value to a variable called initial Generate a random number and call it DataSize. Download DataSize bytes of data from a computer on the WAN side of the device Invoke the GetTotalBytesSent action again and assign the returned value to a variable called current Verify that current - initial >= DataSize Repeat steps 3-6 for another 4 times Expected Result: current - initial >= DataSize Comments: Make sure that there is only one computer connected to the device and only one device is connected to the computer for this test

TotalBytesSent_Counter_Rollover TotalBytesSent variable rolls over to 0 when the value reaches 4294967295
Test Assertion GUID: 736cecc2-68bd-446d-b859-6ec3f319b7a5

Windows Logo Program: NETWORK-0065 Router correctly implements GetTotalBytesSent and GetTotalBytesReceived as defined in the UPnP IGD 1.0 specification

Additional Information: Procedure: Use the UPnP Control Point API to detect the device and invoke the GetTotalBytesSent action Assign the returned value to a variable called initial Calculate DataSize = 4294967295 - initial Send DataSize bytes of data to a computer on the WAN side of the device After the transfer is complete invoke the GetTotalBytesSent action again and assign the returned value to a variable called current Verify that current <= initial Expected Result: current <= initial Comments: Make sure that there is only one computer connected to the device and only one device is connected to the computer for this test

TotalBytesReceived_Counter_Rollover TotalBytesReceived variable rolls over to 0 when the value reaches 4294967295
Test Assertion GUID: 571990e5-b59c-4529-81b3-c0c9909a79b2

Windows Logo Program: NETWORK-0065 Router correctly implements GetTotalBytesSent and GetTotalBytesReceived as defined in the UPnP IGD 1.0 specification

Additional Information: Procedure: Use the UPnP Control Point API to detect the device and invoke the GetTotalBytesSent action Assign the returned value to a variable called initial Calculate DataSize = 4294967295 - initial Download DataSize bytes of data from a computer on the WAN side of the device After the transfer is complete invoke the GetTotalBytesSent action again and assign the returned value to a variable called current Verify that current <= initial Expected Result: current <= initial Comments: Make sure that there is only one computer connected to the device and only one device is connected to the computer for this test

GetTotalBytesSent_Returns_ASAP GetTotalBytesSent action returns within 1000 milliseconds
Test Assertion GUID: 34a039bc-bbb7-4973-a534-2cffd21e3b25

Windows Logo Program: NETWORK-0050 Router responds to the GetTotalBytesSent and GetTotalBytesReceived actions within 25ms

Additional Information: Procedure: Use the UPnP Control Point API to detect the device Create a thread and transfer 100 MB data to a computer on the WAN side of the device Create another thread and perform steps 4 to 7 below until the transfer is complete Note the current timestamp as previous Invoke the GetTotalBytesSent action Note the current timestamp as current Verify that current – previous <= 1000 ms Expected Result: The GetTotalBytesSent action always returns within 1000 ms Comments:

GetTotalBytesReceived_Returns_ASAP GetTotalBytesReceived action returns within 1000 milliseconds
Test Assertion GUID: c51bf39e-5d12-4516-bfe4-a52d833246ef

Windows Logo Program: NETWORK-0050 Router responds to the GetTotalBytesSent and GetTotalBytesReceived actions within 25ms

Additional Information: Procedure: Use the UPnP Control Point API to detect the device Create a thread and download 100 MB data from a computer on the WAN side of the device Create another thread and perform steps 4 to 7 below until the transfer is complete Note the current timestamp as previous Invoke the GetTotalBytesReceived action Note the current timestamp as current Verify that current – previous <= 1000 ms Expected Result: The GetTotalBytesReceived action always returns within 1000 ms Comments:

SameMachine_Simultaneous_GetTotalBytesSent_Requests IGD is able to handle five simultaneous calls of GetTotalBytesSent action from the same computer
Test Assertion GUID: 391a96b2-8647-4222-9c54-478852429617

Windows Logo Program: NETWORK-0050 Router responds to the GetTotalBytesSent and GetTotalBytesReceived actions within 25ms

Additional Information: Procedure: Use the UPnP Control Point API to detect the device Create a thread and transfer 100 MB data to a computer on the WAN side of the device Create 5 threads and in each thread perform steps 4 to 8 below until the transfer is complete Note the current timestamp as previous Invoke the GetTotalBytesSent action Note the current timestamp as current Verify that current – previous <= 1000 ms Verify that the counter value is valid Expected Result: The GetTotalBytesSent action always returns within 1000 ms Comments:

SameMachine_Simultaneous_GetTotalBytesReceived_Requests IGD is able to handle five simultaneous calls of GetTotalBytesReceived action from the same computer
Test Assertion GUID: c8459d83-0a3f-4546-a5fa-f26390bd9a67

Windows Logo Program: NETWORK-0050 Router responds to the GetTotalBytesSent and GetTotalBytesReceived actions within 25ms

Additional Information: Procedure: Use the UPnP Control Point API to detect the device Create a thread and transfer 100 MB data to a computer on the WAN side of the device Create 5 threads and in each thread perform steps 4 to 8 below until the transfer is complete Note the current timestamp as previous Invoke the GetTotalBytesReceived action Note the current timestamp as current Verify that current – previous <= 1000 ms Verify that the counter value is valid Expected Result: The GetTotalBytesReceived action always returns within 1000 ms Comments:

MultiMachine_Simultaneous_GetTotalBytesSent_Requests IGD is able to handle simultaneous calls of GetTotalBytesSent action from different computers
Test Assertion GUID: bf6fd704-b9e0-43a5-9356-5c5b4cb9e270

Windows Logo Program: NETWORK-0050 Router responds to the GetTotalBytesSent and GetTotalBytesReceived actions within 25ms

Additional Information: Procedure: Connect 2 or more computers to the device and perform steps 2 to 9 on each of them Use the UPnP Control Point API to detect the device Create a thread and transfer 10 MB data to a computer on the WAN side of the device Create another thread and perform steps 4 to 9 below until the transfer is complete Note the current timestamp as previous Invoke the GetTotalBytesSent action Note the current timestamp as current Verify that current – previous <= 1000 ms Verify that the counter value is valid Expected Result: The GetTotalBytesSent action always returns within 1000 ms Comments:

MultiMachine_Simultaneous_GetTotalBytesReceived_Requests IGD is able to handle simultaneous calls of GetTotalBytesReceived action from different computers
Test Assertion GUID: 56c11792-5cee-49cf-9dbe-84764555ac5d

Windows Logo Program: NETWORK-0050 Router responds to the GetTotalBytesSent and GetTotalBytesReceived actions within 25ms

Additional Information: Procedure: Connect 2 or more computers to the device and perform steps 2 to 9 on each of them Use the UPnP Control Point API to detect the device Create a thread and transfer 10 MB data to a computer on the WAN side of the device Create another thread and perform steps 4 to 9 below until the transfer is complete Note the current timestamp as previous Invoke the GetTotalBytesReceived action Note the current timestamp as current Verify that current – previous <= 1000 ms Verify that the counter value is valid Expected Result: The GetTotalBytesReceived action always returns within 1000 ms Comments:


TCP/IP Offload Engine logo tests

Type: Automated Test

Overview

Verify the TCP behavior of a TOE (TCP/IP Offload Engine) network card. Protocol conformance and offload mechanisms are checked.

Details

The necessary tools are copied to the machine with the DTM, but installation occurs as part of the DTM job. Manual installation can be performed with the same command line as is found in the DTM job.
Two machines are required for the tests. One machine, the host, runs a series of tests against the second machine, the test machine. The host machine uses a special protocol driver to craft different packet sequences. These are sent to the test machine. The responses from the test machine are analyzed for conformance with the TCP. An administrative service is installed on the test machine to control its higher level actions, such as opening sockets, and to query information for additional checks.
The Windows TCP/IP stack and the TOE stack determine all responses on the test machine. In contrast, the protocol driver on the host machine allows its actions to bypass the Windows TCP/IP stack or any TOE stack. The tests have complete control over "remote" packets arriving at the test machine.

Run Time: 2 hours
Log File: ? One log per test group.
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Windows 2003
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running TCP/IP Offload Engine logo tests

Command Syntax

Command option | Description

Cautions

Reboots are required when testing hardware on Windows Server 2003. Changes to the default configuration are made, but will not persist unless an unforeseen error occurs.

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


STATS

Type: Automated Test

Overview

STATS is a UDP traffic generator tool that provides both client as well as server funcionality.

Details

Stats.exe is a stream(UDP) generating tool. Stats require input command line parameters.
This section describes Stats input parameters required for the logo test.
Stats can be run in two modes, SERVER and CLIENT modes.
Parameter | Description
-d | IP address of the server and is applicable only in CLIENT mode.
-z | Value of this will be set to DISCARD and is applicable only in SERVER mode
-r | Generated data rate in bits/sec
-c | Time to live in seconds(Duration of tool run)
-l | If this option is specified the send thread will try to be rescheduled as frequently as possible
-u | If this is specified the send thread tries to generate the UDP traffic in uniform way
-h | Runs the tool with high priority class
-i | Sampling interval in seconds
-x | Time in seconds for the first frame/packet
-y | Waiting time in seconds for stable traffic. This is time after which sampling measurement starts.
-q | Allowed packet loss in %

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running STATS

Command Syntax

Command option | Description

Cautions

The firewall will block the UDP traffic, in turn all the tests will fail. Besides Windows Firewall, we advise to turn of any existing firewalls.

Troubleshooting

This tip will help you in testing the ability of your machines to send/receive higher bit rates using Ethernet connection. We recommend to use this test to validate the actual configuration is able to deal with requested bit rates generally. If the following simple configuration fails it's very likely it will fail for Wireless link as well.
Ethernet Test:
  1. Setup the hardware as shown below with only Ethernet connection as shown above
  2. Assign the IP address to Machine S.
For Example: 10.0.0.2
  3. Assign the IP address to Machine C.
For Example: 10.0.0.3
  4. Open the MS command prompt and run Stats tool at the Machine C with following parameters:
Stats.exe –z DISCARD –i 20 –x 50 –y 30 –r 20000000 –c 3600 –l –h -u
(Please refer the Stats Parameter Description )
  5. Open the MS command prompt and run Stats tool at the Machine S with following parameters:
Stats.exe –d 10.0.0.3 –r 20000000 –c 4200 –l –h -u
(Please refer the Stats Parameter Description )
  6. Observe the output of Step 4 and Step5.
Conclusion:
If output of either Step4 or Step5 shows any failures then your machines cannot make bit rates using wireless adapters.
\\nistest\scratch\milosp\WifiPerf\Router_RG_WLAN-060223_1151_Nytec.doc;\\nistest\scratch\milosp\WifiPerf\Router Logo Test Suite.doc

Code Tour

File Manifest

File | Location
STATS.EXE | [SystemDrive]\WifiPerf
Wireless Profiles | [SystemDrive]\WifiPerf\Profiles\*
Various scripts | [SystemDrive]\WifiPerf\Scripts\*

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


TCP traffic generator for Wifi performance tests

Type: Automated Test

Overview

The IOCPCLIENT/IOCPSERVER test suite generates a TCP traffic of a given amount within given time

Details

IOCP tools are TCP traffic generating/consuming tools. IOCP client tool is iocpclient.exe and IOCP server tool is iocpserver.exe. In Wifi Performace jobs is this TCP generator used to emulate internet traffic. In the picture below machines IU#1 and IU#2 runs IOCPCLIENT program and machine S runs two instances IOCPSERVER (please note that machine S is connected to LAN port in our tests)
Parameters description for IOCPCLIENT and IOCPSERVER
SERVER: IOCPserver.exe
Parameter | Description
-s: | Expected amount of data in bytes
-e: | TCP port number
-c: | Time to live in second after successful connect
-v | Verbose
-x: | Waiting for connect in seconds (default INFINITE)
CLIENT: IOCPclient.exe
Parameter | Description
-s: | Amount of data to be sent (in bytes)
-e: | TCP port number (default port=5001)
-c: | Time to live in second (counted from first successful connect)
-n: | IP address of the machine on which iocpserver.exe running
-b: | Size of send/receive buffer; default 4096 is used in our tests
-n: | Specifies the hostname of the server (i.e. IOCPSERVER)
-t: | Number of threads to be used (1 thread used in our test cases)
-v | Verbose output
-x: | How long this program waits for a successful connect (in seconds)

Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running TCP traffic generator for Wifi performance tests

Command Syntax

Command option | Description

Cautions

The firewall will block the UDP traffic, in turn all the tests will fail. Besides Windows Firewall, we advise to turn of any existing firewalls.

Troubleshooting
\\nistest\scratch\milosp\WifiPerf\Router_RG_WLAN-060223_1151_Nytec.doc;\\nistest\scratch\milosp\WifiPerf\Router Logo Test Suite.doc

Code Tour

File Manifest

File | Location
IOCPCLIENT.EXE | [SystemDrive]\WifiPerf
IOCPSERVER.EXE | [SystemDrive]\WifiPerf

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


RouterLogo (LMS)

Type: Automated Test

Overview

The purpose of this tool is to verify the correct behavior of the infrastructure devices (router/AP/etc) regarding QOS (DSCP, 802.1p, WiFi WMM and LLTD QoS/qWave listeners).

Details

In order to perform the test, the following hardware is required:
  1. Client PC with the following hardware:
    1. NIC1: NIC with 802.1p support enabled. (Example: Intel Pro/100 Family with “802.1p QoS Packet Tagging” set to Enabled on the Advanced Tab). This interface should have DHCP enabled to obtain an address from the router.
    2. NIC2: NIC with 802.1p support disabled. (Example: Intel Pro/100 Family with “802.1p QoS Packet Tagging” set to Disabled on the Advanced Tab). This interface should have DHCP enabled to obtain an address from the router.
    3. WNIC: WMM capable Wireless NIC (Native WIFI preferred). This interface should have DHCP enabled to obtain an address from the router.
    4. NIC3: Any NIC for backchannel purposes. This interface should be in the same network as the WDK controller.
  2. Remote PC with the following hardware:
    1. NIC1: NIC with 802.1p support disabled. (Example: Intel Pro/100 Family with “802.1p QoS Packet Tagging” set to Disabled on the Advanced Tab). This interface should have assigned a static IP address.
    2. WNIC: WMM capable Wireless NIC (Native WIFI preferred).
    3. NIC2: Any NIC for backchannel purposes. This interface should be in the same network as the WDK controller.
  3. Wireless Router that supports WMM and has integrated LLTD responder. The WAN port of the Router should have a static IP address to be able to talk with NIC1 of the Remote PC
Note:
We recommend the Intel Pro100 NICs due that they correctly implement the 802.1p behavior.
This tool is divided in four different categories:
1. 802.1p and DSCP Tag Tests
Description: Test 802.1p & DSCP tags. Sends 1000 packets (marked with either 802.1p tag, DSCP or no tag) and verify that all the packets were received at the remote side with the correct 802.1p/DSCP tag.
1.1. DSCP test
Description: Will send 1000 packets (TCP or UDP) for each of these DSCP values: 0x8, 0x0, 0x28 and 0x38 in the following topologies. The test will use the 802.1p enabled NIC in the Client PC for LAN and the WLAN NIC in the Remote PC. The test will pass if all the packets get to the other side with the correct tag. Otherwise will fail.
1.1.1. From LAN to WLAN using TCP
Description: From LAN to WLAN using TCP
1.1.2. From LAN to WLAN using UDP
Description: From LAN to WLAN using UDP
1.1.3. From WLAN to LAN using TCP
Description: From WLAN to LAN using TCP
1.1.4. From WLAN to LAN using UDP
Description: From WLAN to LAN using UDP
1.2. L2(802.1p) test
Description: Will send 1000 packets (TCP or UDP) for each of these 802.1p values: 1, 0, 5 and 7 in the following topologies. The test will use the 802.1p enabled NIC in the Client PC for LAN and the WLAN NIC in the Remote PC. The test will pass if all the packets get to the other side with the correct tag. Otherwise will fail.
1.2.1. From LAN to WLAN using TCP
Description: From LAN to WLAN using TCP
1.2.2. From LAN to WLAN using UDP
Description: From LAN to WLAN using UDP
1.2.3. From WLAN to LAN using TCP
Description: From WLAN to LAN using TCP
1.2.4. From WLAN to LAN using UDP
Description: From WLAN to LAN using UDP
1.3. No tag test
Description: Will send 1000 packets (TCP or UDP) with no DSCP nor 802.1p tag in the following topologies and verify that no tagging is added. The test will use the 802.1p enabled NIC in the Client PC for LAN and the WLAN NIC in the Remote PC. The test will pass if all the packets at the receive side do not contain a tag. Otherwise will fail.
1.3.1. From LAN to WLAN using TCP
Description: From LAN to WLAN using TCP
1.3.2. From LAN to WLAN using UDP
Description: From LAN to WLAN using UDP
1.3.3. From WLAN to LAN using TCP
Description: From WLAN to LAN using TCP
1.3.4. From WLAN to LAN using UDP
Description: From WLAN to LAN using UDP
2. LLTD Implementation Tests
Description: Test LLTD implementation of the IGD querying 50 times for Bottleneck bandwidth, Available bandwidth (instantaneous) and RTT time every 500 ms. If the samples at the end vary more than 20% for bottleneck bandwidth and available bandwidth and 40% for RTT the test fails, as well if any of the samples contains no data. We test these scenarios with and without crosstraffic (TCP traffic initiated in the PC driving the test to the other PC)
2.1. Test LLTD Packet Pair
2.1.1. Test LLTD from LAN
Description: Test LLTP from LAN
2.1.2. Test LLTD from LAN with cross traffic
Description: Test LLTP from LAN with crosstraffic
2.1.3. Test LLTD from WLAN
Description: Test LLTP from WLAN
2.1.4. Test LLTP from WLAN with cross traffic
Description: Test LLTP from WLAN with crosstraffic
3. RTT Tests
Description: For these tests we cycle trough the same DSCP and 802.1p values (DSCP: 0x8, 0x0, 0x28, 0x38; 802.1p: 1, 0, 5, 7) and send 1000 UDP packets, from those packets a random number gets marked, at the receiver side we verify that all the packets were received, strip the tag and reply back. We calculate that the RTT time shouldn’t be more than 10 ms (for both marked and non-marked packets). We also verify that all the packets are accounted for and the correct tag was expected. If the RTT is not met or the number of packets is different then we’ll fail the test.
3.1. RTT Test from LAN to WAN
Description: Test RTT Time from LAN to WAN using UDP packets
3.2. RTT Test from LAN to WLAN
Description: Test RTT Time from LAN to WLAN using UDP packets
3.3. RTT Test from WLAN to LAN
Description: Test RTT Time from WLAN to LAN using UDP packets
3.4. RTT Test from WLAN to WAN
Description: Test RTT Time from WLAN to WAN using UDP packets
4. Two Stream Priority Tests
Description: In these tests we create two streams, each one marked with a different tag (i.e. Stream1: DSCP 0x38 , Stream2: DSCP 0x28), we send those packets using 70% of the available bandwidth, and we expect that the higher priority stream conserve its bandwidth and the lower priority uses only the available bandwidth, hence honoring the priority. This test is performed for each combination of WMM_AC.
4.1. DSCP priority
Description: Send 2 flows, each one with a different DSCP value to verify priority. Here we send these DSCP pairs: 0x38 vs 0x28, 0x38 vs 0x0, 0x38 vs 0x8, 0x28 vs 0x0, 0x28 vs 0x8 and 0x0 vs 0x8
4.1.1. TCP flows from LAN to WLAN
Description: 2 TCP Flows from Lan to WLan
4.1.2. TCP flows from LAN to WLAN and WLAN to LAN
Description: Higher priority TCP flow from Lan to Wlan, lower priority TCP flows WLan to Lan
4.1.3. TCP flows from WLAN to LAN
Description: 2 TCP Flows from WLan to Lan
4.1.4. TCP flows from WLAN to LAN and LAN to WLAN
Description: Higher priority TCP flow from WLan to Lan, lower priority TCP flows Lan to WLan
4.1.5. UDP flows from LAN to WLAN
Description: 2 UDP Flows from Lan to WLan
4.1.6. UDP flows from LAN to WLAN and WLAN to LAN
Description: Higher priority UDP flow from Lan to Wlan, lower priority UDP flows WLan to Lan
4.1.7. UDP flows from WLAN to LAN
Description: 2 UDP Flows from WLan to Lan
4.1.8. UDP flows from WLAN to LAN and LAN to WLAN
Description: Higher priority UDP flow from WLan to Lan, lower priority UDP flows Lan to WLan
4.2. L2 + DSCP priority
Description: Send 2 flows, each one with a different 8021p + DSCP value to verify priority. Here we send these DSCP+L2 pairs: (0x38,7) vs (0x28,5), (0x38,7) vs (0x0, 0), (0x38,7) vs (0x8, 1), (0x28,5) vs (0x0, 0), (0x28,5) vs (0x8, 1) and (0x0,0) vs (0x8,1)
4.2.1. TCP flows from LAN to WLAN
Description: 2 TCP Flows from Lan to WLan
4.2.2. TCP flows from LAN to WLAN and WLAN to LAN
Description: Higher priority TCP flow from Lan to Wlan, lower priority TCP flows WLan to Lan
4.2.3. TCP flows from WLAN to LAN
Description: 2 TCP Flows from WLan to Lan
4.2.4. TCP flows from WLAN to LAN and LAN to WLAN
Description: Higher priority TCP flow from WLan to Lan, lower priority TCP flows Lan to WLan
4.2.5. UDP flows from LAN to WLAN
Description: 2 UDP Flows from Lan to WLan
4.2.6. UDP flows from LAN to WLAN and WLAN to LAN
Description: Higher priority UDP flow from Lan to Wlan, lower priority UDP flows WLan to Lan
4.2.7. UDP flows from WLAN to LAN
Description: 2 UDP Flows from WLan to Lan
4.2.8. UDP flows from WLAN to LAN and LAN to WLAN
Description: Higher priority UDP flow from WLan to Lan, lower priority UDP flows Lan to WLan
4.3. L2(802.1p) priority
Description: Send 2 flows, each one with a different 802.1p value to verify priority. Here we send these L2(802.1p) pairs: 7 vs 5, 7 vs 0, 7 vs 1, 5 vs 0, 5 vs 1 and 0 vs 1
4.3.1. TCP flows from LAN to WLAN
Description: 2 TCP Flows from Lan to WLan
4.3.2. TCP flows from LAN to WLAN and WLAN to LAN
Description: Higher priority TCP flow from Lan to Wlan, lower priority TCP flows WLan to Lan
4.3.3. TCP flows from WLAN to LAN
Description: 2 TCP Flows from WLan to Lan
4.3.4. TCP flows from WLAN to LAN and LAN to WLAN
Description: Higher priority TCP flow from WLan to Lan, lower priority TCP flows Lan to WLan
4.3.5. UDP flows from LAN to WLAN
Description: 2 UDP Flows from Lan to WLan
4.3.6. UDP flows from LAN to WLAN and WLAN to LAN
Description: Higher priority UDP flow from Lan to Wlan, lower priority UDP flows WLan to Lan
4.3.7. UDP flows from WLAN to LAN
Description: 2 UDP Flows from WLan to Lan
4.3.8. UDP flows from WLAN to LAN and LAN to WLAN
Description: Higher priority UDP flow from WLan to Lan, lower priority UDP flows Lan to WLan

Run Time: 60 min
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running RouterLogo (LMS)

Command Syntax

Command option | Description

Cautions

For wireless tests we recommend that are performed in a clean wireless environment to avoid possible interference from other wireless routers.

Troubleshooting

Verify that the WDK process install the NDIS_LWF, you can use the following command to verify that the filter driver is running:

Sc query ndislwf
Verify that you have QOS enabled in the network interfaces.

Reference Documentation

Code Tour

File Manifest

File | Location

Click to show or hide information. Test Assertions

Test Assertions

Do not drop tagged packets
Test Assertion GUID:

Windows Logo Program: NETWORK-0077 Router, WLAN AP, or Wireless Router does not drop packets tagged with the 802.1Q priority value

Additional Information: This assertion maps to 802.1p and DSCP Tag Tests (Section 1 of the test description document)

WMM Certified
Test Assertion GUID:

Windows Logo Program: NETWORK-0052 WLAN AP is WMM certified by WFA (Wi-Fi Alliance) in order to support QoS

Additional Information: This assertion maps to the Two Stream Tests and RTT Tests (Section 4 and 3 of the test description document)

Router support QOS
Test Assertion GUID:

Windows Logo Program: NETWORK-0053 WLAN AP supports both 802.1q and DSCP packet tagging to support QoS

Additional Information: This assertion maps to the 802.1p and DSCP Tag Test (Section 1 of the test description document)

Router not adding priority when tag is zero
Test Assertion GUID:

Windows Logo Program: NETWORK-0078 Router, WLAN AP, or Wireless Router does not add an 802.1Q tag with priority value of zero (0)

Additional Information: This assertion maps to the 802.1p and DSCP Tag Test (Section 1 of the test description document)

Router not modifing tag
Test Assertion GUID:

Windows Logo Program: NETWORK-0079 Router, WLAN AP, or Wireless Router does not modify the layer-2 802.1Q or layer-3 DSCP priority value

Additional Information: This assertion maps to the 802.1p and DSCP Tag Test (Section 1 of the test description document)

Router Implements LLTD(QoS/qWave)
Test Assertion GUID:

Windows Logo Program: NETWORK-0054 Router, WLAN AP, or Wireless Router implements Link Layer Topology Discovery (LLTD) QoS/qWAVE extensions for time probes

Additional Information: This assertion maps to the LLTD implementation tests (Section 3 of the test description document)


Supplemental Tests

Test name | Target operating system | Test description
Syscache Test Windows Vista
         This test reads, writes, and verifies data with and without the Windows XP Professional buffer feature. Testing halts when the SysCache test detects data corruption.
WGF Resource Access | Verifies D3D graphics driver/hardware conformance for resource copying functions and the integrity of the data manipulated.
XBOX 360 Controller State and Audio Test Windows Vista
         Manual test that allows tester to get instant feedback as to what functions of the common controller are working, as well as view the capabilities of the controller.
Usedisk2 Windows Vista
         A tool used for creating files and directories with varying attributes.
PC99TA 6.8.6 720x576 resolution | Verifies that a 720x576 overlay can be created and displayed via DirectDraw.
WGF Filtering | Verifies D3D graphics driver/hardware conformance for texture filtering features which are not specifically tested elsewhere.
SQLIO Test Windows Vista
         This test simulates the behavior of a SQL server by stressing the disk with file system IO requests.
PC99TA 6.8.3 YUV Support | Verifies that required DDRAW overlay formats are supported: yuy2 and yv12
PC99 #10 Supported Pixel Orderings | Tests for PC99 #10 Supported Pixel orderings
Miscellaneous DirectDraw Tests | Regression tests for various driver bugs that have been reported over the years.
WGF Resource Formats | Verifies D3D graphics driver/hardware conformance for shader resource views and the texture formats outlined in the D3D10 functional spec.
PC99TA 6.8.5 Qual Scaling Cons. | Verifies that DDRAW overlays can be stretched and shrunk by a factor of 8:1.
WGF Render Targets | Verifies D3D graphics driver/hardware conformance for render target features and RenderTargetViews.
Multihead Support

Multihead Conformance Test Assertions

This test validates the functional and operational specifications for the multihead support added in Microsoft® DirectX® 9.0.
The following test assertions are tested in the TD-5.92 Multihead Conformance test.
5.92.1 [New] The driver must successfully handle the CreateDevice method when the D3DCREATE_ADAPTERGROUP_DEVICE flag is used.
Reference document: DirectX 9.0 DDK; DirectX 9.0 SDK

Test description: TD-5.92 Multihead Conformance test
5.92.2 [New] The driver must successfully handle the CreateDevice method when an array of D3DPRESENT_PARAMETERS is passed in a manner where each head is assigned the D3DPRESENT_PARAMETER properties in numerical order.
The presentation parameters (an array of D3DPRESENT_PARAMETERS) should contain NumberOfAdaptersInGroup elements. The runtime will assign each element to each head in AdapterOrdinalInGroup numerical order.
Reference document: DirectX 9.0 DDK; DirectX 9.0 SDK

Test description: TD-5.92 Multihead Conformance test
5.92.3 [New] The driver must set the NumberOfAdaptersInGroup, MasterAdapterOrdinal, and AdapterOrdinalInGroup caps members for each head.
Reference document: DirectX 9.0 DDK; DirectX 9.0 SDK

Test description: TD-5.92 Multihead Conformance test
5.92.4 [New] The driver must successfully handle the Reset method when the D3DCREATE_ADAPTERGROUP_DEVICE flag is used.
Reference document: DirectX 9.0 DDK; DirectX 9.0 SDK

Memory-Texture Management | D3D Video Memory Management Tests
GetRenderTargetData - Mip Texture and Cube Texture | Verifies that D3D9's GetRenderTargetData can be used to extract the contents of Render Target Mipmaps and Cubemaps.
PC99TA 6.8.1 Overlay Support | Test for PC9914.10. DDRAW test for overlay cap, and basic support.
WGF Async | Verifies D3D graphics driver/hardware conformance for query and other asynchronous features which are not specifically tested elsewhere.
Minimum Screen Resolution | Verifies that a 1024x768x32 display mode is supported with sufficient memory for a double buffered primary with a 32-bit z-buffer.
WGF Geometry Shader | Verifies D3D graphics driver/hardware conformance for geometry shader features which are not specifically tested elsewhere.
DDraw Blt - ColorFill - System Memory | DirectDraw test for color fill operations on System memory surfaces.
BangFS Test Windows Vista
This test simulates numerous users as well as files being accessed by users from a single machine. Its main purpose is to test Windows multiprocessing capabilities to handle multiple requests at a given time.
WGF Clipping Windows Vista
         Verifies D3D graphics driver/hardware conformance for geometry clipping features which are not specifically tested elsewhere.
WGF Alpha Blend | Verifies D3D graphics driver/hardware conformance for color and alpha blending features which are not specifically tested elsewhere.
Certificate installer Windows Vista
Windows XP
         This tool will populate one or more certificates into the Trusted Root CA certificate store and the Trusted Publisher certificate store on the local computer.
D3DQuery Conformance Test | Tests driver support for Microsoft® DirectX® 9.0 asynchronous notifications
RapidFile Test Windows Vista
         This test create file with any arbitrary size using asynchronous IO. It also has the options to log statistics and to verify the created file for data corruption.
CDS_VIDEOPARAMETERS | Tests driver's ability to handle ChangeDisplaySettingsEx with CDS_VIDEOPARAMTERS.
Blt - Stretch - System Memory to Primary Memory | Part of the Fnddraw suite of tests for evaluating DirectDraw features of Display Driver.
Ipv6Test Windows Vista
         Test verifies that IGD device meets logo requirements
PC99TA 6.8.2 Color Key Support | Verifies that the display driver supports destination color keying of overlays.
VBIB - Vertex and Index Buffer Validation | D3D8/9 Vertex and Index Buffer Tests
txfs2 | txf stress test suit
Depth Stencil Readback Windows Vista
Test for WLP 3.0 - GRAPHICS-0014. Verifies D3D9 Depth Stencil Read/Write capability.
GetRenderTargetData - Backbuffer and Render Target | Verifies that D3D9's GetRenderTargetData can be used to extract the contents of Back buffers and basic render targets
Desktop Window Manager Glass Verification Test Windows Vista
         Test Verifies the Desktop Window Manager's Glass effect. Glass effect can be applied in both the client area and in the non client area. This test verifies both types of glass.
WGF Depth Stencil | Verifies D3D graphics driver/hardware conformance for depth stencil functionality and DepthStencilViews.
Pixel Shaders Ver 3.0 | Verifies D3D graphics driver/hardware conformance for Pixel Shader 3.0 instructions and functionality.


Syscache Test

Type: Automated Test

Overview

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

Details

This test reads, writes, and verifies data with and without the Windows XP Professional buffer feature. Testing halts when the SysCache test detects data corruption.
SysCache tries to write files using every known combination of write attributes, truncation strategy, file pointer move strategy, and read attributes. Syscache opens a series of temporary files and does IO on them. For each type of write file (sequential, non-buffered, mapped IO, async IO, etc … in random order) then for each truncation strategy / file offset move strategy Syscache does IO. Syscache will write a series of regions to the file with a particular pattern that can be verified on read. Syscache then verifies the file by reading it in concurrently executing Read threads which have opened the file for read using different attributes. If data corruption is encountered, the test logs a failure.
Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running Syscache Test

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WGF Resource Access

Overview

Verifies D3D graphics driver/hardware conformance for resource copying functions and the integrity of the data manipulated.

Details

TextureAccess (CopyResource and related functions)
  • Test behavior when specifying 1-pixel sized regions and other special cases.
  • Insure consistent data when copying from mip and array slices.
  • Make sure that only specified data is changed and other subresources or regions remain untouched.
  • Test behavior with special and compressed formats.
  • Watch for CopyResource() and related functions affecting pipeline statistics. IHV's may choose to use the rendering pipeline to "emulate" copy functionality but the spec states that copy functions cannot affect pipeline statistics.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running WGF Resource Access

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


XBOX 360 Controller State and Audio Test

Overview

Manual test that allows tester to get instant feedback as to what functions of the common controller are working, as well as view the capabilities of the controller.

Details

XNAState is the test app that can be used to view the capabilities of all the devices connect to the PC, and their real time data. This test is a manual test, that is used to check if the XInput APIs function correctly when the controllers ‘ objects are maneuvered. This test displays data from the controller in a GUI. You will be asked to hit a button on the controller, then the GUI will pop. Test that each button you touch gives you a response in the right spot, that the left and right motors work (rumble), that both motors work together, and that you can control the strength of the motors. Use the audio portion of this test to listen and communicate with other controllers audio by running multiple instances of this test and selecting different ports for each device. By selecting the view capabilities button, you can view what buttons the device is capable of using. There is no xml output for this as it is all visual testing by direct interaction with the controller.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running XBOX 360 Controller State and Audio Test

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Usedisk2

Overview

A tool used for creating files and directories with varying attributes.

Details

Usedisk2 creates files and directories with parameters specified by the user. These parameters specify how many directories to create, how deep the directory tree should go, how many files to create in each directory, the number of data streams to create per file, file size, maximum disk usage, and types of files (normal, sparse, etc.).

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running Usedisk2

Usedisk2 is a command line utility in the form of usedisk2.exe. For usage information, run "usedisk2.exe /?". This will detail the available options.

Command Syntax

Command option | Description
Drive:\Directory | The path to create directories and files in.
NumDirectories:NumPropagatedDirs | The number of directories to create at each level and the number of directories to propagate into at each level.
NumFiles:NumFilesInRoot | The number of files to create at each level and the number of files to create in the initial root path.
FileSize:MinSize | Size of each file. Append K for kilobytes and M for megabytes. Also, you may specify the minimum size for a file.
Depth | How many directories deep to create.
DiskUse% | The maximum disk usage after which creation will stop.
/stm:# | Number of data streams per file.
/!sec | Disable security on the files/directories
/afn | ASCII only file names (alphanumerics and underscore)
/adn | ASCII only directory names (alphanumerics and underscore)
/!eas | Disables using of extended attributes
/minp:# | Minimum path length
/maxp:# | Maximum path length
/rel | Allows relative disk usage
/!atr | Disables setting of attributes (read-only, hidden, etc)
/gro | Generate files in reverse order (longest files first)
/p:[n|d|r|o|s|h] | Pattern for created files. n = Normal file, d = DOC file, r = reparse point, o = Object ID, s = sparse file (only if size > 4KB), h = hard link
/doc:#:#:#:# | Creates OLE documents. Specify /doc:(Storages):(Streams):(Max stream size):(DOC depth)

Code Tour

File Manifest

File | Location
usedisk2.exe | usedisk2.exe

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


PC99TA 6.8.6 720x576 resolution

Overview

Verifies that a 720x576 overlay can be created and displayed via DirectDraw.

Details

Verifies that a 720x576 overlay can be created and displayed via DirectDraw. Test cannot validate that the overlay is actually visible on screen. It simply verifies that the function calls succeed.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running PC99TA 6.8.6 720x576 resolution

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WGF Filtering

Overview

Verifies D3D graphics driver/hardware conformance for texture filtering features which are not specifically tested elsewhere.

Details

Filtering Conformance Test Plan:
  • Quad rendered to render target
  • Each RT pixel tested programmatically against expected value
  • Texture created with non-symmetric colored pattern
  • Texture coordinates cycled for all vertices in tandem, to achieve specific LOD values
  • Texture filter type cycled through all valid types
  • Texture formats cycled, to find issues with precision, clamping, etc
  • Texture addressing cycled, independently per dimension and then in tandem
  • Basic group tests independent features, only “sample” (point/linear, mipmap LOD)
  • Separate groups for different sample instructions (biased, fixed LOD, fixed deriv, PCF), with corresponding attributes cycled
  • All texture types tested independently (1D, 2D, 3D, Cube)
  • One texture unit active, with texture arrays occupying a single unit
  • Texture Views cycled for mip-level and array constraints
  • Verify that sample_d works in normalized space.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running WGF Filtering

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


SQLIO Test

Type: Automated Test

Overview

This test simulates the behavior of a SQL server by stressing the disk with file system IO requests.

Details

The goal of this test is to test the reliability of SQL Server running over a period of time.
This test will simulate the environment of a SQL Server by continually issue read/write requests to the system and occasionally it will issues thousands of I/O request simultaneously to stress the system. This allows us to measure the responsiveness and impact of such scenario.

Run Time:
Log File: sqlio.log
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running SQLIO Test

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


PC99TA 6.8.3 YUV Support

Overview

Verifies that required DDRAW overlay formats are supported: yuy2 and yv12

Details

Verifies that required YUY2 and YV12 overlay formats can be created and displayed through DirectDRaw. It also tests the recommended UYVY format.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running PC99TA 6.8.3 YUV Support

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


PC99 #10 Supported Pixel Orderings

Overview

Tests for PC99 #10 Supported Pixel orderings

Details

PC99 #10 Supported Pixel Orderings.
Drivers must support these pixel orderings for their various display modes.
15-Bit RGB 555
16-Bit RGB 565
24-Bit RGB 888
32-Bit ARGB 8888

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running PC99 #10 Supported Pixel Orderings

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Miscellaneous DirectDraw Tests

Overview

Regression tests for various driver bugs that have been reported over the years.

Details

This is a set of miscellaneous DirectDraw tests that target problems that have been reported in display drivers in the past.
Contains tests for:
  • Page flipping between a large number of back buffers.
  • Color Fill Blt calls where a bogus (unneeded) source surface is provided.
  • Color Converting Blts - Which drivers are not required to support, but must at least fail gracefully.
  • 1x1 pixel overlays.
All tests are housed in Fnddraw.exe, and selected by the dd_misc.pro profile.
To load and run this selection of tests manually, use the following command line:
fnddraw dd_misc.pro -r

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running Miscellaneous DirectDraw Tests

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WGF Resource Formats

Overview

Verifies D3D graphics driver/hardware conformance for shader resource views and the texture formats outlined in the D3D10 functional spec.

Details

ResourceFormats (tests mainly ShaderResourceViews)
  • Render target is a four-component, 32-bit float format. The formats tested are converted to this format, results must be within 1-ULP (per component) of expected result.
  • Compressed and other special formats are decoded as spec’d in the test and compared against the hardware’s (or REF’s) results (again, 1-ULP tolerance).
  • Three types of source data are used (tiles, gradients, stripes). Each data type is parameterized, such as gradient colors, tile and stripe size, etc.
  • Depending on the resource type (all 5 types are tested) the test cycles through different values for height, width, and depth. This includes non-square and non-pow-2 values.
  • Hit all shader resource slots through out the test run.
  • Verify multiple use input resources.
    • Example: Use a texture as vertex input and shader resource input in the same Draw() call.
  • Test input/output resources (ie: D3D10_BIND_SHADER_RESOURCE | D3D10_BIND_RENDERTARGET)
    • Try using first pass to initialize resource data.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running WGF Resource Formats

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


PC99TA 6.8.5 Qual Scaling Cons.

Overview

Verifies that DDRAW overlays can be stretched and shrunk by a factor of 8:1.

Details

This test contains two separate cases.
In the first case, a 34x25 overlay is displayed at a range of sizes up to a stretch factor of 8:1
In the second case, a 720x576 overlay is displayed at increasingly smaller sizes down to 1:8.
The test cannot validate the displayed image, but it does verify that the function calls fail gracefully.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running PC99TA 6.8.5 Qual Scaling Cons.

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WGF Render Targets

Overview

Verifies D3D graphics driver/hardware conformance for render target features and RenderTargetViews.

Details

RenderTargets (tests mainly RenderTargetViews)
  • Test cycles through all formats capable of being used as a render target. No conversion takes place however results must be within 1-ULP of expected result (per component).
  • Three types of source data are used (tiles, gradients, stripes). Each data type is parameterized, such as gradient colors, tile and stripe size, etc.
  • Depending on the resource type (all 5 types are tested) the test cycles through different values for height, width, and depth. This includes non-square and non-pow-2 values.
  • MRT is tested, multiple mip-levels and array slices are targeted.
  • Hit all render target slots through out the test run.
  • Render to VB, IB and shader resource (verify in subsequent Draw() call).
  • Render to texture cube (and sub mips) by creating a Texture2DArray render target view.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running WGF Render Targets

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Multihead Support

Overview

Multihead Conformance Test Assertions

This test validates the functional and operational specifications for the multihead support added in Microsoft® DirectX® 9.0.
The following test assertions are tested in the TD-5.92 Multihead Conformance test.
5.92.1 [New] The driver must successfully handle the CreateDevice method when the D3DCREATE_ADAPTERGROUP_DEVICE flag is used.
Reference document: DirectX 9.0 DDK; DirectX 9.0 SDK

Test description: TD-5.92 Multihead Conformance test
5.92.2 [New] The driver must successfully handle the CreateDevice method when an array of D3DPRESENT_PARAMETERS is passed in a manner where each head is assigned the D3DPRESENT_PARAMETER properties in numerical order.
The presentation parameters (an array of D3DPRESENT_PARAMETERS) should contain NumberOfAdaptersInGroup elements. The runtime will assign each element to each head in AdapterOrdinalInGroup numerical order.
Reference document: DirectX 9.0 DDK; DirectX 9.0 SDK

Test description: TD-5.92 Multihead Conformance test
5.92.3 [New] The driver must set the NumberOfAdaptersInGroup, MasterAdapterOrdinal, and AdapterOrdinalInGroup caps members for each head.
Reference document: DirectX 9.0 DDK; DirectX 9.0 SDK

Test description: TD-5.92 Multihead Conformance test
5.92.4 [New] The driver must successfully handle the Reset method when the D3DCREATE_ADAPTERGROUP_DEVICE flag is used.
Reference document: DirectX 9.0 DDK; DirectX 9.0 SDK

Details

Overview

This test validates the functional and operational specifications for the multihead support added in Microsoft® DirectX® 9.0. Multihead support allows a single Microsoft Direct3D® device to drive multiple heads; this provides for a more efficient utilization of resources (surfaces, textures, and so on.) when compared to a multi-monitor configuration where a Direct3D device is required to drive each head and each device consumes its own copy the of resources. Several restrictions must be observed when creating and resetting a multihead device.
  1. Each head must have the Windowed mode set to FALSE.
  2. Each head must have the same value set for the EnableAutoDepthStencil property.
  3. If EnableAutoDepthStencil is TRUE, then each head must have the same value for AutoDepthStencilFormat, back buffer dimension, and format.
  4. You cannot create additional swap chains on a multihead device.
Test Coverage
The test covers the core usage scenarios and a set of Direct3D interfaces (IDirect3D9 and IDirect3DDevice9). The interface methods include GetDeviceCaps, CreateDevice, Reset, CreateAdditionalSwapChain, GetSwapChain, and GetNumberOfSwapchains.
Core usage scenarios include rendering to each head and cursor manipulation.
Test Methodology
For each of the covered interface methods, a set of test cases are run to verify the basic functional properties. Most of these tests simply involve verifying state changes or verifying that the actual results match the expected results. There are several tests that vary the surface properties of each head, render a scene on the heads, and compare the images against the rendering of the reference device.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.
No special setup or configuration is required to run this test.
Software requirements
  • Microsoft DirectX 9.0.
Command syntax
multihead.exe

Results Interpretation

The test writes the test results to a log file called Multihead.xml and displays on-screen pass or fail compliance. The test log is written to the %windir%\dxlogs directory.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running Multihead Support

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Memory-Texture Management

Overview

D3D Video Memory Management Tests

Details

Contains tests for the following features of D3D8 and D3D9.
DiscardBytes - Verifies that the resource manager is able to free up managed video memory via the D3D8 DiscardBytes function. Tests depend heavily on GetAvailableTextureMemory for verification.
Preload - Verifies that preloading works by measuring the time it takes to render a scene with preloaded and non-preloaded resources. It's expected that preloaded resources will result in a scene that renders more quickly.
TexMan - Verifies that a managed texture can be recycled multiple times per frame. The test reuses a managed texture 9 times with-in a frame, verifying the image contents between uses. Test validates final rendered scene.
Memman - Contains a small set of tests for verifying some basic aspects of video memory management. Tests try to consume all available video memory with textures and vertex buffers, verifying that memory is used efficiently and that reported memory is reasonably accurate. Under D3D8 interfaces, the tests to verify that resources are not allocated on top of one another. They do this by writing a byte pattern to surfaces that can be monitored to ensure surface integrity.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running Memory-Texture Management

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


GetRenderTargetData - Mip Texture and Cube Texture

Overview

Verifies that D3D9's GetRenderTargetData can be used to extract the contents of Render Target Mipmaps and Cubemaps.

Details

Overview

This test validates the functional and operational specifications for the IDirect3DDevice9::GetRenderTargetData method. The GetRenderTargetData method provides a means to copy the contents of a render-target surface to a system-memory surface. There are several restrictions on the source and destination surfaces that must be met for this copy to succeed.
  • The source surface must be a regular render-target surface or a specific level of a render-target texture (MIP map or cube texture).
  • The source must be POOL_DEFAULT and D3DMULTISAMPLE_NONE.
  • The destination surface must be either an off-screen plain surface or a texture (MIP map or cube) created with POOL_SYSTEMMEM.
  • The source and destination surfaces must be the same dimension and format.
Test Coverage
The following table shows the matrix of surface combinations covered by the test and the command options that are used to select the type of surface.
 | Offscreen Plain | MIP-map Texture | Cube Texture
Back Buffer | -grtdbb | -grtdbbt | -grtdbbct
Render Target | -grtdrt | -grtdrtt | -grtdrtct
MIP-map Texture | -grtdts | -grtdtt | -grtdtct
Cube Texture | -grtdcts | -grtdctt | -grtdctct
Test Methodology
The test first creates the source and destination surfaces. The test cycles through various surface formats and usage specifications. If either surface cannot be created, that configuration is skipped. After the surfaces are created, the render-target surface is filled with a textured quad. Next, the source is copied to the destination with the GetRenderTargetData method and a surface comparison is performed to verify that the two surface contents are the same.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.
No special setup or configuration is required to run this test.
Software requirements
  • Microsoft® DirectX® 9.0.
Command options
getrendertargetdata.exe [ option ]
Option | Surfaces
-grtdbb | Back Buffer, Offscreen Plain
-grtdbbt | Back Buffer, MIP-map Texture
-grtdbbct | Back Buffer, Cube Texture
-grtdrt | Render Target, Offscreen Plain,
-grtdrtt | Render Target, MIP-map Texture
-grtdrtct | Render Target, Cube Texture
-grtdts | MIP-map Texture, Offscreen Plain
-grtdtt | MIP-map Texture, MIP-map Texture
-grtdtct | MIP-map Texture, Cube Texture
-grtdcts | Cube Texture, Offscreen Plain
-grtdctt | Cube Texture, MIP-map Texture
-grtdctct | Cube Texture, Cube Texture

Results Interpretation

The test writes the test results to a log file called GetRenderTargetData.xml and displays on-screen pass or fail compliance. The test log is written to the %windir%\dxlogs directory.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running GetRenderTargetData - Mip Texture and Cube Texture

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


PC99TA 6.8.1 Overlay Support

Overview

Test for PC9914.10. DDRAW test for overlay cap, and basic support.

Details

Verifies that DDCAPS_OVERLAY is set and that a simple overlay surface can be created and displayed through DDRAW APIs.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running PC99TA 6.8.1 Overlay Support

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WGF Async

Overview

Verifies D3D graphics driver/hardware conformance for query and other asynchronous features which are not specifically tested elsewhere.

Details

Async Conformance Test Plan:
  • Separate group for each query type
  • Queries tested for asynchronous (non-blocking) execution and correct values
  • Occlusion tested by rendering quads repeatedly with different depth functions
  • Predicates tested with all known predication functions, to ensure they are predicated
  • Counters tested with random amounts of geometry being rendered
  • Possibly consider issues with clipping in regards to pipeline statistics.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running WGF Async

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Minimum Screen Resolution

Overview

Verifies that a 1024x768x32 display mode is supported with sufficient memory for a double buffered primary with a 32-bit z-buffer.

Details

Uses DirectDraw APIs to set a 1024x768x32 display mode. Then creates a double buffered primary and 32-bit depth/stencil buffer.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running Minimum Screen Resolution

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WGF Geometry Shader

Overview

Verifies D3D graphics driver/hardware conformance for geometry shader features which are not specifically tested elsewhere.

Details

Geometry Shader Conformance Test Plan Outline
Geometry Shader Input
  • Verify support for all input primitive types.
    • Line
    • Point
    • Triangle
    • LineAdj
    • TriangleAdj
  • PrimitiveID
    • Verify that primitive ordering is respected.
    • PS test should test this as well for cases where there is no GS in the pipeline.
    • Cycle on Draw() and DrawInstanced().
      • Make sure that the id resets to zero for each instance drawn.
  • InstanceID
    • Is this getting tested already in the instancing tests?
Geometry Shader Output
  • RenderTargetArrayIndex
    • Is this getting tested in RenderTarget conformance tests? If so we may not need this here.
  • Position
    • Again, this is getting tested all over the place. Do we need it here?
  • Limits
    • Maximum GS invocation output data size (components * vertices) up to 1024.
  • Ordering
    • Verify that primitive ordering is respected.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running WGF Geometry Shader

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


DDraw Blt - ColorFill - System Memory

Overview

DirectDraw test for color fill operations on System memory surfaces.

Details

The purpose of these tests are to verify that color fill blt operations can be successfully performed on system memory surfaces.
The test performs a series of color fill directly onto on offscreen system memory surface. Fill regions (RECTs) are chosen such that a variety of sizes and memory alignments are tested. The results of the color fills are compared against a reference image generated using GDI.
Display Drivers are required to support hardware accelerated color fills. Support is indicated by setting the DDCAPS_BLTCOLORFILL flag.
Test Executable: Fnddraw.exe
Fnddraw Test Case: BLT Color Fill System Memory
To run this test manually:
fnddraw dd_scf.pro -r

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running DDraw Blt - ColorFill - System Memory

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


BangFS Test

Type: Automated Test

Overview

This test simulates numerous users as well as files being accessed by users from a single machine. Its main purpose is to test Windows multiprocessing capabilities to handle multiple requests at a given time.

Details

This test simulates numerous users as well as files being accessed by users from a single machine. Its main purpose is to test Windows multiprocessing capabilities to handle multiple requests at a given time.
This test will randomly run the following file system functionality scenarios:
Compression/Decompression, Encryption/Decryption, Hardlinks, Mapped I/O, Streams, Usn, Reparse point, Object ids, extended attributes, Locks, etc...
Note:
  • It is not worth the time investment to run this test with only one file.
  • Each command window will only handle 64 threads at a time, but the test will run better if you use no more than 50 threads.
  • Use multiple processing computers for more than 50 threads. For 50 threads or less, it is OK to run on a dual processor as a server.

Run Time:
Log File: BangFS.log
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running BangFS Test

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WGF Clipping

Overview

Verifies D3D graphics driver/hardware conformance for geometry clipping features which are not specifically tested elsewhere.

Details

Clipping Conformance Plan:
  • Quad rendered to render target
  • Each RT pixel tested programmatically against expected value
  • Clipdist, Culldist values cycled independently for each vertex, to test shaded clipping
  • W values manipulated independently for each vertex, to test fixed clipping
  • Tests multisample with fixed sample pattern and potential deviation
  • Might need some uncertainty epsilon for floating-point precision issues
  • Consider non perspective correct attribute interpolation (though this may be better tested in rasterization tests).
  • Be particularly aware of guardband and z-clip.
    • Guardband may hide some clipping problems.
    • Z-clipping has no guardband protection.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running WGF Clipping

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WGF Alpha Blend

Overview

Verifies D3D graphics driver/hardware conformance for color and alpha blending features which are not specifically tested elsewhere.

Details

Alpha Blending Conformance Test Plan:
  • Quad rendered to render target
  • Each RT pixel tested programmatically against expected value
  • Different gradients rendered to RT for each blend element (dest, source, 2nd source)
  • Blend modes cycled independently and in tandem for color & alpha
  • RT formats cycled, to find issues with clamping & precision
  • Cycle number of RTs used and with blending enabled
  • Different RT formats used in RT indices, to test independent clamping & precision

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running WGF Alpha Blend

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Certificate installer

Overview

This tool will populate one or more certificates into the Trusted Root CA certificate store and the Trusted Publisher certificate store on the local computer.

Details

This tool uses certmgr.exe to populate one or more certificates into the Trusted Root CA certificate store and the Trusted Publisher certificate store on the local computer.
Each certificate must be in a unique .cer file and all of the .cer files must reside in the same directory as the tool.
Use of the tool requires administrator privileges on the machine and in Vista, you must run elevated.
This tool can be run using a Library job in DTM called "Add Certificates to Certificate Store".

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running Certificate installer

To use the tool in DTM:
Copy one or more .cer files to the machine your DTM controller is installed on, into the directory:
\Program FIles\Microsoft Driver Test Manager\Tests\x86fre\nttest\certs
For use client machine that you need the certificates installed on, run the Library job called "Add Certificates to Certificate Store".

Command Syntax

Command option | Description
addcerts.cmd |

Code Tour

File Manifest

File | Location
addcerts.cmd | \Program FIles\Microsoft Driver Test Manager\Tests\x86fre\nttest\certs

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


D3DQuery Conformance Test

Overview

Tests driver support for Microsoft® DirectX® 9.0 asynchronous notifications

Details

Overview

This test validates the functional and operational specifications for the Microsoft® DirectX® 9.0 asynchronous notification application programming interface (API). This API provides an efficient and flexible mechanism to query the driver for state or statistical information. The query is executed either synchronously (application waits) or asynchronously (application does not wait). The asynchronous notification API consists of the IDirect3DDevice9::CreateQuery, IDirect3DDevice9::Issue, and IDirect3DDevice9::GetData methods.
Test Coverage
A fixed set of query types are defined by the Microsoft Direct3D® API and the driver supports the query types it chooses during setup. This test only validates the query types supported by the driver. All other query types are not validated.
Test Methodology
There are general properties that are common to all or to a subset of query types. These properties are validated for each appropriate query type. For example, checking the correct combination of issue flags and data size with the IDirect3DDevice9::GetData method. Another example is checking that asynchronous queries are performed in parallel with the CPU execution. This is done by counting the number of iterations required to fetch the data with the GetData method. There are also specific properties that are unique to a query type. These properties are validated for that query type and usually involve verifying that the data returned by a query conforms to the expected value. For example, in the occlusion query, the test verifies that the number of processed pixels corresponds to the exposed area of the rendered primitive.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.
No special setup or configuration is required to run this test.
Hardware requirements
The driver returns D3DERR_NOTAVAILABLE if the query type is not supported.
Software requirements
  • Microsoft DirectX 9.0.
Command
D3DQuery.exe

Results Interpretation

The test writes the test results to a log file called D3DQuery.xml and displays on-screen pass or fail compliance. The test log is written to the %windir%\dxlogs directory.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running D3DQuery Conformance Test

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


RapidFile Test

Type: Automated Test

Overview

This test create file with any arbitrary size using asynchronous IO. It also has the options to log statistics and to verify the created file for data corruption.

Details

This test create file with any arbitrary size using asynchronous IO. It also has the options to log statistics and to verify the created file for data corruption.
This test also allows the ability to schedule multiple threads simultaneously to read/write to different regions of the file. Regions selection are done automatically by the program. It also has the options of specifying the way the creation are done (ie. FILE_FLAG_SEQUENTIAL_SCAN, FILE_FLAG_WRITE_THROUGH or FILE_FLAG_NO_BUFFERING).

Run Time:
Log File: RapidFile.log
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Windows 2003
  • Windows XP
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running RapidFile Test

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


CDS_VIDEOPARAMETERS

Overview

Tests driver's ability to handle ChangeDisplaySettingsEx with CDS_VIDEOPARAMTERS.

Details

Tests the display driver’s ability to handle a call to ChangeDisplaySettingsEx() with the CDS_VIDEOPARAMETERS parameter. It also checks for MacroVision support if available.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running CDS_VIDEOPARAMETERS

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Blt - Stretch - System Memory to Primary Memory

Overview

Part of the Fnddraw suite of tests for evaluating DirectDraw features of Display Driver.

Details

Test ensures that the DirectDraw graphics adapter is able to process a variety of DirectDraw stretch (and shrink) blts from system memory to the primary surface.
The follow Fnddraw cases make up this test
BLT, Stretch (Wx2, Hx.75), SysMem to Pri
BLT, Shrink, (3/4), SysMem To Primary
BLT Shrink (1/2), SysMem to Primary
BLT Stretch x 1.5, SysMem to Primary
BLT Stretch x 2, SysMem to Primary
Test Executable: Fnddraw.exe

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running Blt - Stretch - System Memory to Primary Memory

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Ipv6Test

Type: Automated Test

Overview

Test verifies that IGD device meets logo requirements

Details

Test uses a message server on the"WAN" side of the IGD and a Test box on the "friendly" side of the IGD. Test sends various packets and probes through the IDG and monitors expected responses
Run Time:
Log File:
System Restart Required: No
Test Category:
Supported operating systems for "DFW" logo testing:
Windows Vista
Program:

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • Itanium

Running Ipv6Test

server needs to have 2 IPv4 addresses in the public range. IDG must have a public range IPv4 address, a 6to4 tunnel available and a cisco router that is propagating address prefixes to the IGD.

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


PC99TA 6.8.2 Color Key Support

Overview

Verifies that the display driver supports destination color keying of overlays.

Details

Simple test that verifies DDCAPS_OVERLAY and DDCKEYCAPS_DESTOVERLAY flags are set, and that an overlay surface can be created and displayed with a destination color key.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running PC99TA 6.8.2 Color Key Support

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


VBIB - Vertex and Index Buffer Validation

Overview

D3D8/9 Vertex and Index Buffer Tests

Details

Overview

The Vertex and Index Buffer test attempts to validate the use of a variety of vertex and index buffers. This test is broken into a number of test groups that test vertex and index buffers in different ways. The test groups are as follows:
NormalBuffer

Ensures that simple objects can be rendered correctly.
LockActive

Ensures that a selected vertex or index buffer can be rendered from and locked across multiple scenes and in one scene.
Priority

Ensures that a selected vertex or index buffer can have its priority manipulated while rendering a scene.
SwitchRenderState

Ensures proper operation when switching between hardware and software vertex processing during a scene.
LostOnReset

Ensures that all buffers are required to be released before a Reset() will succeed.
HugeBuffer

Ensures that a large object can be rendered correctly.
RelockDynamic

Ensures that dynamic vertex and index buffers can be reused in a single scene correctly.
LockPointerAlias

Ensures that, upon a device lost condition, pointers to vertex and index buffers obtained through Lock() do not cause exceptions.
InternalPointerAlias

Ensures that, upon a device lost condition, internal buffer pointers do not cause exceptions (such as during calls to DrawPrimitive() or DrawIndexedPrimitive() .

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running VBIB - Vertex and Index Buffer Validation

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


txfs2

Overview

txf stress test suit

Details

txf stress test suit

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running txfs2

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID: C07DC21B-15E3-17FA-7AB3-47D9C4


Depth Stencil Readback

Overview

Test for WLP 3.0 - GRAPHICS-0014. Verifies D3D9 Depth Stencil Read/Write capability.

Details

Test for GRAPHICS-0014. Verifies D3D9 Depth Stencil Read/Write capability. Verifies that video memory depth buffer contents can be copied to/from lockable system memory formats.
Support for the following system memory lockable formats is required.
D3DFMT_D16_LOCKABLE

D3DFMT_D32F_LOCKABLE

D3DFMT_D32_LOCKABLE

D3DFMT_S8_LOCKABLE

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64

Running Depth Stencil Readback

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


GetRenderTargetData - Backbuffer and Render Target

Overview

Verifies that D3D9's GetRenderTargetData can be used to extract the contents of Back buffers and basic render targets

Details

Overview

This test validates the functional and operational specifications for the IDirect3DDevice9::GetRenderTargetData method. The GetRenderTargetData method provides a means to copy the contents of a render-target surface to a system-memory surface. There are several restrictions on the source and destination surfaces that must be met for this copy to succeed.
  • The source surface must be a regular render-target surface or a specific level of a render-target texture (MIP map or cube texture).
  • The source must be POOL_DEFAULT and D3DMULTISAMPLE_NONE.
  • The destination surface must be either an off-screen plain surface or a texture (MIP map or cube) created with POOL_SYSTEMMEM.
  • The source and destination surfaces must be the same dimension and format.
Test Coverage
The following table shows the matrix of surface combinations covered by the test and the command options that are used to select the type of surface.
 | Offscreen Plain | MIP-map Texture | Cube Texture
Back Buffer | -grtdbb | -grtdbbt | -grtdbbct
Render Target | -grtdrt | -grtdrtt | -grtdrtct
MIP-map Texture | -grtdts | -grtdtt | -grtdtct
Cube Texture | -grtdcts | -grtdctt | -grtdctct
Test Methodology
The test first creates the source and destination surfaces. The test cycles through various surface formats and usage specifications. If either surface cannot be created, that configuration is skipped. After the surfaces are created, the render-target surface is filled with a textured quad. Next, the source is copied to the destination with the GetRenderTargetData method and a surface comparison is performed to verify that the two surface contents are the same.

Setup

This information is preliminary. For complete procedures for this test in the current HCT, see the HCT Documentation.
No special setup or configuration is required to run this test.
Software requirements
  • Microsoft® DirectX® 9.0.
Command options
getrendertargetdata.exe [ option ]
Option | Surfaces
-grtdbb | Back Buffer, Offscreen Plain
-grtdbbt | Back Buffer, MIP-map Texture
-grtdbbct | Back Buffer, Cube Texture
-grtdrt | Render Target, Offscreen Plain,
-grtdrtt | Render Target, MIP-map Texture
-grtdrtct | Render Target, Cube Texture
-grtdts | MIP-map Texture, Offscreen Plain
-grtdtt | MIP-map Texture, MIP-map Texture
-grtdtct | MIP-map Texture, Cube Texture
-grtdcts | Cube Texture, Offscreen Plain
-grtdctt | Cube Texture, MIP-map Texture
-grtdctct | Cube Texture, Cube Texture

Results Interpretation

The test writes the test results to a log file called GetRenderTargetData.xml and displays on-screen pass or fail compliance. The test log is written to the %windir%\dxlogs directory.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running GetRenderTargetData - Backbuffer and Render Target

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Desktop Window Manager Glass Verification Test

Overview

Test Verifies the Desktop Window Manager's Glass effect. Glass effect can be applied in both the client area and in the non client area. This test verifies both types of glass.

Details

Test renders a window with client glass and non-client glass. The test then takes a snapshot of the window and compares against a known good master snapshot. A pixel by pixel comparison is done. If every pixel is within tolerance, the test passes. If it fails a difference file is saved.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Windows Vista

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

  • x86
  • x64
  • A system which is capable of running the desktop window manager. This means that the graphics adapter has WDDM drivers and can support pixel shader 2.0 and greater.

Running Desktop Window Manager Glass Verification Test

  1. Copy the binaries of the test into a directory. See "File Source Locations" in the "Installation Section"
  2. Execute the command line mentioned in the installation section. See "Command Line Arguments" in the "Installation Section"

Command Syntax

Command option | Description
loader.exe -logtype:GdiDxBlurIntegrationTest.log -ini:GdiDxBlurIntegrationTest.ini |

Code Tour

File Manifest

File | Location
GdiDxBlurIntegrationTest-Master.bmp | ??
GdiDxBlurIntegrationTest.ini | ??
Loader.exe | ??
Loader.pdb | ??
NonClientAreaTests.Master.info | ??
ntlog.dll | ??
OutputRedirectionHelper.dll | ??
OutputRedirectionHelper.pdb | ??

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


WGF Depth Stencil

Overview

Verifies D3D graphics driver/hardware conformance for depth stencil functionality and DepthStencilViews.

Details

DepthStencil (tests mainly DepthStencilViews)
  • Test cycles through all formats capable of being used as a depth stencil surface. No conversion takes place however results must be within 1-ULP of expected result (per component).
  • Depending on the resource type (all 5 types are tested) the test cycles through different values for height, width, and depth. This includes non-square and non-pow-2 values.
  • Hit all render target/depth stencil slots through out the test run.
  • Be sure to consider RT arrays.
  • Consider rendering to Depth/Stencil without a "color" render target.
  • Discuss with RobRod where MSAA using Depth/Stencil should be tested in combination.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running WGF Depth Stencil

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Pixel Shaders Ver 3.0

Overview

Verifies D3D graphics driver/hardware conformance for Pixel Shader 3.0 instructions and functionality.

Details

Pixel Shader Ver 3.0
  • Tests every ps3_0 instruction (also previous versions) including cases for:
    • Different swizzles
    • Instruction modifiers
    • Destination register and modifiers
  • Texturing instructions tested with different texture types (2D, Cube, Volume).
  • Special registers such as aL, vFace, and vPos are tested for proper behavior.
  • Landscape usage scenario test is parameterized on water caustics, lighting, shadows, and other effects driven by a pixel shader.

Requirements

Software Requirements

The test tool runs on the following Windows operating systems:
  • Software components included with the device that is being tested.

Hardware Requirements

  • Device to be tested
  • Computer that meets the minimum software requirements
  • Hard drive with a minimum of 20 GB available on partition C:
  • Windows keyboard
  • Two-button pointing device
  • Color display monitor capable of at least 1024 by 768 resolution, 32-bits per pixel, 60 Hz
  • Hard drive with a minimum of 20 GB available on partition C:

    • Processor

Running Pixel Shaders Ver 3.0

Command Syntax

Command option | Description

Click to show or hide information. Test Assertions

Test Assertions

Test Assertion GUID:


Glossary

© 2006 Microsoft Corporation
Send feedback on this topic
DTM Releases
Built on April 19, 2006
Build machine: CAPEBUILD


C

child machine pool
A machine pool that is contained within another ("parent") machine pool. Several child machine pools can be created as part of a parent machine pool in the machine pool hierarchy.
client computer
A computer that the Driver Test Manager (DTM) client has been installed on. You use DTM to run tests on client computers.
configuration job
A job that sets the value of a dimension. Configuration jobs can be executed automatically to satisfy the constraints of another job that is executing.
constraint
A triplet that consists of a dimension, an operator, and a value. A constraint is part of the job definition. A job can only execute on client computers that match the job’s constraints.
For example, a job that had the following constraint could only be executed on client computers that have an x86 processor.WTT\Processor equals x86

See also dimension.

context
A set of constraints that are specified in a job. For example, if a job included the constraints “WTT\OS equals Windows XP” and “WTT\RAM-MB greater than 512”, then these two constraints would form the job’s context.
See also dimension, mix.
controller
A computer that the DTM controller has been installed on. The controller stores data about jobs, client computers, and DTM users, and it manages job scheduling.
Copy File task
A task that copies files from a remote location to the client computer.
Copy Result task
A task that copies files from the client computer to a remote location.
custom dependencies
User-defined relationships between tasks in a job that specify the order in which the tasks execute.


D

daemon task
A task that begins running either before all other tasks in a phase, or after all other tasks in a phase. A daemon task can run in parallel with other tasks.
Default Pool
The machine pool that computers are initially placed in when the Driver Test Manager (DTM) client is installed.
Device Selection explorer
A component of DTM Studio that you use to select the jobs to run and the computers on which to run them. The Device Selection explorer displays only the jobs that are appropriate for a specific device or computer.
dimension
A key/value pair that identifies a characteristic of a client computer. For example, a dimension with the key “ProcessorCount” might have the value “1” on one client computer and the value “4” on another client computer.

A job can include constraints, which indicate that the job can run only on client computers that have a specific value for a dimension.

Driver Test Manager (DTM)
A test harness that you must use to run the “Designed for Microsoft Windows” logo tests. You can also run your own tests using DTM.
DTM
See Driver Test Manager.
DTM administrator
A DTM user account that has administrator privileges. A DTM administrator can create machine pools, create DTM user accounts, and grant privileges to the DTM user accounts.

A DTM administrator often has an account with administrative privileges on the computer that is running the DTM controller, but this type of account is not required.

When you install the DTM controller, a DTM user account is automatically created for you, and your account is automatically given administrator privileges.

DTM Studio
The user interface for DTM. By using DTM Studio, you can run tests, monitor the progress of jobs, and review test logs.


E

EA
Execution agent. A component of the DTM client that executes the tasks of a job.
Execute task
A task that executes a command line.


F

Feature
An attribute of a job that organizes jobs within a hierarchy.

Within Job Explorer , you expand nodes of the feature hierarchy to locate jobs.


G

gatherer
A program that collects information about a client computer.
global parameter
A parameter that can be used by all jobs on the DTM controller. You can define global parameters by using the Management Console.


J

job
A collection of tasks that can be run on a client computer. A job describes the order in which to execute the tasks. A job can identify conditions that a client computer must meet to run the job.
Job Explorer
A component of Driver Test Manager (DTM) that you can use to view jobs, create jobs, and perform actions on jobs. You can open Job Explorer by clicking Explorers, and then clicking Job Explorer.
Job Monitor
A component of Driver Test Manager (DTM) that you can use to view job and task execution status and to add and change machine pools. You can open Job Monitor by clicking Explorers, and then clicking Job Monitor.


L

library job
A job that has been stored and can be used by another job.
LLU
See Local Logical User.
Local Logical User (LLU)
A mapping from a variable to a user account on each client computer.

For example, the Local Logical User (LLU) with the name AdminUser might map to the user account MyDomain\User6 with a password of My^Password%23 on one client computer, and to the user account MyDomain\User32 with a password of My#Password@97 on another client computer.

Logical Machine Set (LMS)
A set of computers that play the same role in a job that requires multiple computers. For example, a job that required more than one computer might have a client Logical Machine Set and a server Logical Machine Set.

LMS
See Logical Machine Set.


M

machine
A client computer that is a member of a machine pool. Client computers that are not in the System machine pool are test clients that you can execute jobs on.
machine pool
A virtual collection of computers, devices, or both that is created by a user to help manage the testing process.
Management Console
A window within DTM Studio that you can use to manage dimensions, global parameters, services, and users within a DTM Controller or a package.
Manual Prompt task
A task that displays a prompt and options to the user and waits for the user to make a selection.
mix
A set of contexts that is specified in a job. The job can be executed on a computer that matches any of the contexts. For example, a job could specify a mix that consisted of two contexts. Context 1 could consist of the constraints “WTT\OS equals Windows XP” and “WTT\RAM-MB greater than 512”. Context 2 could consist of the constraints “WTT\OS equals Windows Server 2003” and “WTT\RAM-MB greater than 1000”. In this case, the job’s mix would specify that the job could run on client computers with Windows XP and more than 512 MB of RAM, or client computers with Windows Server 2003 and more than 1GB of RAM.
See also constraint.


P

package
A container that can include jobs and the other data that is required to run the jobs. Packages are used for grouping, storing, and sharing jobs.
Parameter
A variable that provides information to a task. Global parameters are defined by using the Management Console. Local variables are defined within a job. Default values for parameters can be overridden when a job is scheduled.
PD
Push Daemon. A component of the DTM controller that sends a job to the client computer to execute.


R

result
The information that is created when you execute a job. Each instance of a job creates a result that contains the start time, end time, and completion status of the job’s tasks; any error messages; a link to the job’s log files; and more detailed information.
result collection
A group of results. When you execute a job, a result collection is created to contain the job’s results. If more than one instance of a job is created when a job is executed, the results of all of the job instances are stored in one result collection. You can specify your own result collection to hold results, and you can add, modify, delete, or move results within result collections.
Result Explorer
A component of DTM Studio that you use to review the results and log files that are created when a job executes.
Run Job task
A task that runs a library job.


S

schedule
Adds a job to the list of jobs that are ready to run. A job that has been scheduled will run when a client computer that meets the job’s constraints is available.
scheduler
A component of the DTM controller that assigns a job to execute on a specific client computer.


T

task
A unit of work to be done on a client computer. The most common tasks execute a command line, copy files, or prompt the user to perform a manual action.
test harness
A software application that is used to automate testing.


Legal Information

Windows Driver Kit

Information in this document, including URL and other Internet Web site references, is subject to change without notice. Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

© 1985 − 2006 Microsoft Corporation. All rights reserved.

Microsoft, Microsoft Press, MS-DOS, Windows, Windows NT, and Windows Server are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Send feedback on this topic.


Topic Not Found

No matching topic was found. Some possible reasons and remedies are as follows:

  • The file (.chm) that contains the destination topic is not in the expected location.

    • Remedy: Rerun the Windows Driver Kit Setup and install all documentation components.

  • The destination topic is not part of the currently-selected subset.

    • Remedy: Choose a different subset from the Active Subset list.

Send feedback on this broken link.